[PATCH 2/3] hwmon: (adt7475) fan stall prevention
By default adt7475 will stop the fans (pwm duty cycle 0%) when the
temperature drops past Tmin - hysteresis. Some systems want to keep the
fans moving even when the temperature drops so add new sysfs attributes
that configure the enhanced acoustics min 1-3 which allows the fans to
run at the minimum configure pwm duty cycle.
Signed-off-by: Chris Packham
---
pwmN_min is a horrible name but I really can't think of anything better.
I'm biased a little because that is essentially the name of the bits in
the datasheet. I'm open to suggestions.
Documentation/hwmon/adt7475 | 5 +
drivers/hwmon/adt7475.c | 50 +
2 files changed, 55 insertions(+)
diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
index 0502f2b464e1..85dc9e17bdee 100644
--- a/Documentation/hwmon/adt7475
+++ b/Documentation/hwmon/adt7475
@@ -109,6 +109,11 @@ fan speed) is applied. PWM values range from 0 (off) to
255 (full speed).
Fan speed may be set to maximum when the temperature sensor associated with
the PWM control exceeds temp#_max.
+At Tmin - hysteresis the PWM output can either be off (0% duty cycle) or
+at the minimum (i.e. auto_point1_pwm). This can be configured using the
+pwm[1-*]_min sysfs attribute. A value of 0 means the fans will shut off. A
+value of 1 means the fans will run at auto_point1_pwm.
+
Notes
-
diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index ec0c43fbcdce..53f25bda0919 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -79,6 +79,9 @@
#define REG_TEMP_TRANGE_BASE 0x5F
+#define REG_ENHANCE_ACOUSTICS1 0x62
+#define REG_ENHANCE_ACOUSTICS2 0x63
+
#define REG_PWM_MIN_BASE 0x64
#define REG_TEMP_TMIN_BASE 0x67
@@ -209,6 +212,7 @@ struct adt7475_data {
u8 range[3];
u8 pwmctl[3];
u8 pwmchan[3];
+ u8 enh_acou[2];
u8 vid;
u8 vrm;
@@ -700,6 +704,43 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
data->pwm[sattr->nr][sattr->index] = clamp_val(val, 0, 0xFF);
i2c_smbus_write_byte_data(client, reg,
data->pwm[sattr->nr][sattr->index]);
+ mutex_unlock(&data->lock);
+
+ return count;
+}
+
+
+static ssize_t show_pwm_min(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct adt7475_data *data = i2c_get_clientdata(client);
+ u8 mask = BIT(5 + sattr->index);
+
+ return sprintf(buf, "%d\n", !!(data->enh_acou[0] & mask));
+}
+
+static ssize_t set_pwm_min(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct adt7475_data *data = i2c_get_clientdata(client);
+ long val;
+ u8 mask = BIT(5 + sattr->index);
+
+ if (kstrtol(buf, 10, &val))
+ return -EINVAL;
+
+ mutex_lock(&data->lock);
+
+ data->enh_acou[0] &= ~mask;
+ if (val)
+ data->enh_acou[0] |= mask;
+
+ i2c_smbus_write_byte_data(client, REG_ENHANCE_ACOUSTICS1,
+ data->enh_acou[0]);
mutex_unlock(&data->lock);
@@ -1028,6 +1069,8 @@ static SENSOR_DEVICE_ATTR_2(pwm1_auto_point1_pwm, S_IRUGO
| S_IWUSR, show_pwm,
set_pwm, MIN, 0);
static SENSOR_DEVICE_ATTR_2(pwm1_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 0);
+static SENSOR_DEVICE_ATTR_2(pwm1_min, S_IRUGO | S_IWUSR, show_pwm_min,
+ set_pwm_min, 0, 0);
static SENSOR_DEVICE_ATTR_2(pwm2, S_IRUGO | S_IWUSR, show_pwm, set_pwm, INPUT,
1);
static SENSOR_DEVICE_ATTR_2(pwm2_freq, S_IRUGO | S_IWUSR, show_pwmfreq,
@@ -1040,6 +1083,8 @@ static SENSOR_DEVICE_ATTR_2(pwm2_auto_point1_pwm, S_IRUGO
| S_IWUSR, show_pwm,
set_pwm, MIN, 1);
static SENSOR_DEVICE_ATTR_2(pwm2_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 1);
+static SENSOR_DEVICE_ATTR_2(pwm2_min, S_IRUGO | S_IWUSR, show_pwm_min,
+ set_pwm_min, 0, 1);
static SENSOR_DEVICE_ATTR_2(pwm3, S_IRUGO | S_IWUSR, show_pwm, set_pwm, INPUT,
2);
static SENSOR_DEVICE_ATTR_2(pwm3_freq, S_IRUGO | S_IWUSR, show_pwmfreq,
@@ -1052,6 +1097,8 @@ static SENSOR_DEVICE_ATTR_2(pwm3_auto_point1_pwm, S_IRUGO
| S_IWUSR, show_pwm,
set_pwm, MIN, 2);
static SENSOR_DEVICE_ATTR_2(pwm3_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 2);
+static SENSOR_DEVICE_ATTR_2(pwm3_min, S_IRUGO | S_IWUSR, show_pwm_min,
+
[RFC PATCH 3/3] hwmon: (adt7475) temperature smoothing
When enabled temperature smoothing allows ramping the fan speed over a
configurable period of time instead of jumping to the new speed
instantaneously.
Signed-off-by: Chris Packham
---
Documentation/hwmon/adt7475 | 5 ++
drivers/hwmon/adt7475.c | 121
2 files changed, 126 insertions(+)
diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
index 85dc9e17bdee..31b15cb910ea 100644
--- a/Documentation/hwmon/adt7475
+++ b/Documentation/hwmon/adt7475
@@ -114,6 +114,11 @@ at the minimum (i.e. auto_point1_pwm). This can be
configured using the
pwm[1-*]_min sysfs attribute. A value of 0 means the fans will shut off. A
value of 1 means the fans will run at auto_point1_pwm.
+The responsiveness of the ADT747x to temperature changes can be configured.
+This allows smoothing of the fan speed transition. To enable temperature
+smoothing used the temp[1-*]_smoothing_enable sysfs attribute. To set the
+transition time set the value in ms in the temp[1-*]_smoothing sysfs attribute.
+
Notes
-
diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index 53f25bda0919..e1299eef7c51 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -526,6 +526,109 @@ static ssize_t set_temp(struct device *dev, struct
device_attribute *attr,
return count;
}
+/* Assuming CONFIG6[SLOW] is 0 */
+static const int ad7475_st_map[] = {
+ 37500, 18800, 12500, 7500, 4700, 3100, 1600, 800,
+};
+
+static ssize_t show_temp_st(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct adt7475_data *data = i2c_get_clientdata(client);
+ int shift, idx;
+ long val;
+
+ switch (sattr->index) {
+ case 0:
+ shift = 0;
+ idx = 0;
+ break;
+ case 1:
+ shift = 4;
+ idx = 1;
+ break;
+ case 2:
+ shift = 0;
+ idx = 1;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ switch (sattr->nr) {
+ case CONTROL:
+ val = (data->enh_acou[idx] >> shift) & 0x8;
+ return sprintf(buf, "%d\n", !!val);
+ case MIN:
+ val = (data->enh_acou[idx] >> shift) & 0x7;
+ return sprintf(buf, "%d\n", ad7475_st_map[val]);
+ default:
+ return -EINVAL;
+ }
+}
+
+static ssize_t set_temp_st(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct adt7475_data *data = i2c_get_clientdata(client);
+ unsigned char reg;
+ int shift, idx;
+ int mask;
+ long val;
+
+ if (kstrtol(buf, 10, &val))
+ return -EINVAL;
+
+ switch (sattr->index) {
+ case 0:
+ reg = REG_ENHANCE_ACOUSTICS1;
+ shift = 0;
+ idx = 0;
+ break;
+ case 1:
+ reg = REG_ENHANCE_ACOUSTICS2;
+ shift = 4;
+ idx = 1;
+ break;
+ case 2:
+ reg = REG_ENHANCE_ACOUSTICS2;
+ shift = 0;
+ idx = 1;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ switch (sattr->nr) {
+ case CONTROL:
+ val = !!val << 3;
+ mask = 0x8;
+ break;
+ case MIN:
+ val = find_closest_descending(val, ad7475_st_map,
+ ARRAY_SIZE(ad7475_st_map));
+ mask = 0x7;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ mutex_lock(&data->lock);
+
+ data->enh_acou[idx] &= ~(mask << shift);
+ data->enh_acou[idx] |= (val << shift);
+
+ i2c_smbus_write_byte_data(client, reg, data->enh_acou[idx]);
+
+ mutex_unlock(&data->lock);
+
+ return count;
+}
+
/*
* Table of autorange values - the user will write the value in millidegrees,
* and we'll convert it
@@ -1008,6 +,10 @@ static SENSOR_DEVICE_ATTR_2(temp1_crit, S_IRUGO |
S_IWUSR, show_temp, set_temp,
THERM, 0);
static SENSOR_DEVICE_ATTR_2(temp1_crit_hyst, S_IRUGO | S_IWUSR, show_temp,
set_temp, HYSTERSIS, 0);
+static SENSOR_DEVICE_ATTR_2(temp1_smoothing, S_IRUGO | S_IWUSR, show_temp_st,
+ set_temp_st, MIN, 0);
+static SENSOR_DEVICE_ATTR_2(temp1_smoothing_enable, S_IRUGO | S_IWUSR,
+ show_temp_st, set_temp_st, CONTROL, 0);
static SENSOR_DEVICE_ATTR_2(temp2_input, S_IRUGO, show_temp, NU
Re: ReST style guide?
Em Mon, 1 May 2017 21:48:50 -0300 Mauro Carvalho Chehab escreveu: > Hi Kees, > > Em Mon, 1 May 2017 14:24:24 -0700 > Kees Cook escreveu: > > > Hi, > > > > While doing some .txt conversions to .rst, I ended up with several > > questions about markup style, and in looking at existing .rst files, > > there didn't seem to be a common methodology. > > Well, some maintainers prefer to keep the conversion as simple as > possible. So, there's no "enforcement" about the style. > > My personal preference on the documents I maintain is: > > > I'd love to have > > definitive guide to how to do these things in the kernel > > documentation: > > > > - how to mark and link to CONFIG items? (e.g. CONFIG_HARDENED_USERCOPY) > > ``CONFIG_foo`` > > > - how to mark and link to kernel command line arguments? (e.g. > > loadpin.enabled=1) > > Idem: ``loadpin.enabled=1`` > > > - how to mark and link to functions? (e.g. put_seccomp()) > > If you want to generate cross-references, you can do: > :c:func:`put_seccomp` > > > - how to mark and link to fields? (e.g. siginfo->si_arch) > > Right now, kernel-doc is not generating cross-references to fields, > but you can do cross-references to struct and enums. What I do is: > > :c:type:`device_driver`.\ ``resume()``. There are some examples for the way we're doing this document on media, under kapi directory, like: Documentation/media/kapi/dtv-core.rst > > (That's a cross reference to struct device_driver) > > > - how to mark and link to defines/literals? (e.g PR_SET_NO_NEW_PRIVS) > > ``literal`` > > > - how to mark and link to sysctls? (e.g. net.syn_cookies) > > That is a good question. The problem with syscalls is that each > subsystem may override standard ioctls (open, close, write, ioctl, ...). > > Specifically in the case of ioctl, even inside a subsystem there > will be multiple definitions. > > What I'm doing on media is that I'm creating a reference for > each ioctl definition with a normal reference: > > .. _VIDIOC_G_CTRL: > > > And then I'm referencing them via :ref:`VIDIOC_G_CTL`. > > On the specific cases where the syscall is subsystem-specific and > there's just one meaning for it, then it is probably easier to use > the C domain (e. g. :c:func: for reference, and use kernel-doc to > generate its definition, as if it were a c function). Forgot to mention: if you want also to document it inside a ReST file, you could use: .. c:function:: int ioctl( int fd, VIDIOC_G_CTRL, struct v4l2_control *argp ) :name: VIDIOC_G_CTRL .. c:function:: int ioctl( int fd, VIDIOC_S_CTRL, struct v4l2_control *argp ) :name: VIDIOC_S_CTRL The :name: here is used in order to distinguish it from other sysctls with the same name. If not used, it will use the "function" name, e. g. "ioctl", and will complain because you would have two duplicated definitions for the same function. With :name: each ioctl can be referenced using the value after name, e. g. :c:func:`VIDIOC_G_CTRL`. The cross-reference index will also use the value inside the name. That's particularly useful for filesystem syscalls (like read, write, open, close, ioctl), as each subsystem may have their own particularity and description for those. > > > - how to mark and link to manpage-look-up-able things? (e.g. setuid(2)) > > I guess that there is a ReST markup for man pages, but if you're > documenting it with a man look and feel, the best is to use something > like what we do on media. Something like: > > Documentation/media/uapi/dvb/frontend_f_close.rst > > Markus is working on a way to convert something like that to > man pages. > > > - how to mark internal filepaths? (e.g. samples/seccomp/) > > - how to mark external filepaths? (e.g. /etc/passwd) > > - how to mark environment variables (e.g. LD_*) > > For all the above: ``literal`` > > > > > It seems most aren't explicitly marked up in existing docs. Sometimes > > functions are wrapped in `` marks, same for pathnames. Any opinions > > would be appreciated. :) > > > > > > Thanks, > Mauro Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ReST style guide?
Hi Kees, Em Mon, 1 May 2017 14:24:24 -0700 Kees Cook escreveu: > Hi, > > While doing some .txt conversions to .rst, I ended up with several > questions about markup style, and in looking at existing .rst files, > there didn't seem to be a common methodology. Well, some maintainers prefer to keep the conversion as simple as possible. So, there's no "enforcement" about the style. My personal preference on the documents I maintain is: > I'd love to have > definitive guide to how to do these things in the kernel > documentation: > > - how to mark and link to CONFIG items? (e.g. CONFIG_HARDENED_USERCOPY) ``CONFIG_foo`` > - how to mark and link to kernel command line arguments? (e.g. > loadpin.enabled=1) Idem: ``loadpin.enabled=1`` > - how to mark and link to functions? (e.g. put_seccomp()) If you want to generate cross-references, you can do: :c:func:`put_seccomp` > - how to mark and link to fields? (e.g. siginfo->si_arch) Right now, kernel-doc is not generating cross-references to fields, but you can do cross-references to struct and enums. What I do is: :c:type:`device_driver`.\ ``resume()``. (That's a cross reference to struct device_driver) > - how to mark and link to defines/literals? (e.g PR_SET_NO_NEW_PRIVS) ``literal`` > - how to mark and link to sysctls? (e.g. net.syn_cookies) That is a good question. The problem with syscalls is that each subsystem may override standard ioctls (open, close, write, ioctl, ...). Specifically in the case of ioctl, even inside a subsystem there will be multiple definitions. What I'm doing on media is that I'm creating a reference for each ioctl definition with a normal reference: .. _VIDIOC_G_CTRL: And then I'm referencing them via :ref:`VIDIOC_G_CTL`. On the specific cases where the syscall is subsystem-specific and there's just one meaning for it, then it is probably easier to use the C domain (e. g. :c:func: for reference, and use kernel-doc to generate its definition, as if it were a c function). > - how to mark and link to manpage-look-up-able things? (e.g. setuid(2)) I guess that there is a ReST markup for man pages, but if you're documenting it with a man look and feel, the best is to use something like what we do on media. Something like: Documentation/media/uapi/dvb/frontend_f_close.rst Markus is working on a way to convert something like that to man pages. > - how to mark internal filepaths? (e.g. samples/seccomp/) > - how to mark external filepaths? (e.g. /etc/passwd) > - how to mark environment variables (e.g. LD_*) For all the above: ``literal`` > > It seems most aren't explicitly marked up in existing docs. Sometimes > functions are wrapped in `` marks, same for pathnames. Any opinions > would be appreciated. :) > Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ReST style guide?
Hi, While doing some .txt conversions to .rst, I ended up with several questions about markup style, and in looking at existing .rst files, there didn't seem to be a common methodology. I'd love to have definitive guide to how to do these things in the kernel documentation: - how to mark and link to CONFIG items? (e.g. CONFIG_HARDENED_USERCOPY) - how to mark and link to kernel command line arguments? (e.g. loadpin.enabled=1) - how to mark and link to functions? (e.g. put_seccomp()) - how to mark and link to fields? (e.g. siginfo->si_arch) - how to mark and link to defines/literals? (e.g PR_SET_NO_NEW_PRIVS) - how to mark and link to sysctls? (e.g. net.syn_cookies) - how to mark and link to manpage-look-up-able things? (e.g. setuid(2)) - how to mark internal filepaths? (e.g. samples/seccomp/) - how to mark external filepaths? (e.g. /etc/passwd) - how to mark environment variables (e.g. LD_*) It seems most aren't explicitly marked up in existing docs. Sometimes functions are wrapped in `` marks, same for pathnames. Any opinions would be appreciated. :) -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] em28xx: allow setting the eeprom bus at cards struct
Hi Frank, Em Mon, 1 May 2017 16:11:51 +0200 Frank Schäfer escreveu: > Am 01.05.2017 um 13:38 schrieb Mauro Carvalho Chehab: > > Right now, all devices use bus 0 for eeprom. However, newer > > versions of Terratec H6 use a different buffer for eeprom. > > > > So, add support to use a different I2C address for eeprom. > > Has this been tested ? > Did you read my reply to the previous patch version ?: > See http://www.spinics.net/lists/linux-media/msg114860.html > > I doubt it will work. At least not for the device from the thread in the > Kodi-forum. Yes. Someone at IRC were complaining about this device (his nick is buxy81). According with the tests he did, with both patches his device is now working. That's said, it would be great if he could provide us more details about the tests he did, with the logs enabled, in order for us to see if the eeprom contents is properly read. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: converting Documentation/security/* to .rst
On Mon, May 1, 2017 at 8:11 AM, Jonathan Corbet wrote:
> On Fri, 28 Apr 2017 13:24:36 -0700
> Kees Cook wrote:
>
>> I was curious if the conversion of security/ (and prctl/ which only
>> has two files that should probably both be moved to security/) was
>> already on someone's TODO list? I'd love to get these done (I refer
>> people regularly to seccomp_filter.txt and self-protection.txt), but I
>> didn't want to duplicate any efforts.
>
> If anybody is working in that area, they've not told me about it.
I might take a shot at this, time permitting.
>> I read about various tools to help with auto-converting files to kind
>> of help speed up the process, but I couldn't find what seemed a
>> canonical answer to what to use as a helper. Is there one? (Perhaps
>> this was only for DocBook?)
>
> The tools, such as they are, are for the conversion of DocBook template
> files. Most of the kernel's .txt files are already in something quite
> close to RST already, so the conversion is trivial.
>
> The real question would be one of organization. Most of the security
> stuff looks like it properly belongs in the admin guide, but that's not
> universally the case.
Are the index area "purposes" documented anywhere? The admin guide
seems to cover things outside of "administration" (like reporting
security bugs, which is a developer/researcher activity usually),
There's already a top-level "security documentation" with some TPM
stuff in it.
Both things in prctl/ are "here's what this feature is and how to use
it", both exposed to userspace. In security/ there is a mix of LSM
highlevel descriptions and basic usage, key API documentation, and the
one sort of design goal document ("self-protection.txt").
I think it'd make sense to keep Security Documentation as a top-level
index for now, and create LSM and keys subsections for those items,
and then move prctl/* under security:
deleted:Documentation/security/00-INDEX
deleted:Documentation/security/conf.py
renamed:Documentation/security/IMA-templates.txt ->
Documentation/security/IMA-templates.rst
renamed:Documentation/security/credentials.txt ->
Documentation/security/credentials.rst
renamed:Documentation/security/keys-ecryptfs.txt ->
Documentation/security/keys/ecryptfs.rst
renamed:Documentation/security/keys.txt ->
Documentation/security/keys/index.rst
renamed:Documentation/security/keys-request-key.txt ->
Documentation/security/keys/request-key.rst
renamed:Documentation/security/keys-trusted-encrypted.txt
-> Documentation/security/keys/trusted-encrypted.rst
renamed:Documentation/security/LoadPin.txt ->
Documentation/security/lsm/LoadPin.rst
renamed:Documentation/security/SELinux.txt ->
Documentation/security/lsm/SELinux.rst
renamed:Documentation/security/Smack.txt ->
Documentation/security/lsm/Smack.rst
renamed:Documentation/security/Yama.txt ->
Documentation/security/lsm/Yama.rst
renamed:Documentation/security/apparmor.txt ->
Documentation/security/lsm/apparmor.rst
renamed:Documentation/security/LSM.txt ->
Documentation/security/lsm/index.rst
renamed:Documentation/security/tomoyo.txt ->
Documentation/security/lsm/tomoyo.rst
renamed:Documentation/prctl/no_new_privs.txt ->
Documentation/security/no_new_privs.rst
renamed:Documentation/prctl/seccomp_filter.txt ->
Documentation/security/seccomp_filter.rst
renamed:Documentation/security/self-protection.txt ->
Documentation/security/self-protection.rst
modified: Documentation/security/index.rst
This is just renames and an update to security/index.rst to include
the two new subdirs. This doesn't have any formatting updates. (What
is preferred, organizational changes first or .rst formatting first?)
Does this looks sensible?
What do LSM authors think of this? (e.g. various questions: should
LSM.txt become lsm/index.rst and keys.txt become keys/index.rst? Maybe
key "LSM" case for the new subdirectory? Should IMA be under LSM?)
Thanks!
-Kees
--
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] Docs for 4.12
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://git.lwn.net/linux.git tags/docs-4.12 for you to fetch changes up to 9bb0e9cb04c82d6bf0e72f3207307d621083b801: docs: Fix a couple typos (2017-04-27 15:54:39 -0600) A reasonably busy cycle for documentation this time around. There is a new guide for user-space API documents, rather sparsely populated at the moment, but it's a start. Markus improved the infrastructure for converting diagrams. Mauro has converted much of the USB documentation over to RST. Plus the usual set of fixes, improvements, and tweaks. There's a bit more than the usual amount of reaching out of Documentation/ to fix comments elsewhere in the tree; I have acks for those where I could get them. There will be minor conflicts with the input and USB trees due to the (probably substandard) way in which documentation changes were split across those trees and docs-next. I'll have another small pull after input is merged to wire up the newly converted input docs. Andrew Clayton (1): docs: process/4.Coding.rst: Fix a couple of document refs Baruch Siach (1): doc: ABI: vdso: update parse_vdso.c reference Cao jin (2): pci-error-recovery: doc cleanup sparse doc: fix reference path Daniel Vetter (1): doc: Explain light-handed markup preference a bit better Hans Holmberg (1): lib/Kconfig.debug: correct documentation paths Herton R. Krzesinski (1): Documentation: allow installing man pages to a user defined directory Jacob Pan (1): Doc/PM: Sync with intel_powerclamp code behavior Johan Hovold (1): Documentation: stable-kernel-rules: fix stable-tag format Jonathan Corbet (4): Merge tag 'v4.11-rc1' into docs-next docs: Create a user-space API guide docs: Convert unshare.txt to RST and add to the user-space API manual Merge branch 'user-space-api' into docs-next Kees Cook (1): docs: Clarify details for reporting security bugs Markus Heiser (1): docs-rst: automatically convert Graphviz and SVG images Martin Kepplinger (4): Documentation: hid: fix path to input bus definitions Documentation: input: fix path to input code defnitions Documentation: admin-guide: fix path to input key definitions Documentation: input: fix path to struct ff_effect's definition Mauro Carvalho Chehab (36): docs-rst: Don't use explicit Makefile rules to build SVG and DOT files scripts/kernel-doc: fix parser for apostrophes scripts/kernel-doc: fix handling of parameters with parenthesis genericirq.tmpl: convert it to ReST genericirq.rst: add cross-reference links and use monospaced fonts kernel-api.tmpl: convert it to ReST kernel-api.rst: make it handle lib/crc32.c docs-rst: core_api: move driver-specific stuff to drivers_api kernel-api.rst: fix output of the vsnprintf() documentation kernel-api.rst: fix some complex tags at lib/bitmap.c kernel-api.rst: fix a series of errors when parsing C files tmplcvt: make the tool more robust driver-api/basics.rst: add device table header docs-rst: convert usb docbooks to ReST usb.rst: Enrich its ReST representation gadget.rst: Enrich its ReST representation and add kernel-doc tag writing_usb_driver.rst: Enrich its ReST representation writing_musb_glue_layer.rst: Enrich its ReST representation usb/anchors.txt: convert to ReST and add to driver-api book usb/bulk-streams.txt: convert to ReST and add to driver-api book usb/callbacks.txt: convert to ReST and add to driver-api book usb/power-management.txt: convert to ReST and add to driver-api book usb/dma.txt: convert to ReST and add to driver-api book error-codes.rst: convert to ReST and add to driver-api book usb/hotplug.txt: convert to ReST and add to driver-api book usb/persist.txt: convert to ReST and add to driver-api book usb/URB.txt: convert to ReST and update it usb.rst: get rid of some Sphinx errors usb: get rid of some ReST doc build errors usb: composite.h: fix two warnings when building docs usb: gadget.h: be consistent at kernel doc macros docs-rst: fix usb cross-references docs-rst: usb: update old usbfs-related documentation convert philips.txt to ReST and add to media docs usb.rst: move documentation from proc_usb_info.txt to USB ReST book zr364xx.rst: usb/devices is now at /sys/kernel/debug/ Perr Zhang (1): arm: Documentation: update a path name Rafael J. Wysocki (1): cpufreq: User/admin documentation update and consolidation Rémy Léone (1): Use sphinx.version_info directly instead of parsing SeongJae Park (1): D
Re: converting Documentation/security/* to .rst
On Fri, 28 Apr 2017 13:24:36 -0700 Kees Cook wrote: > I was curious if the conversion of security/ (and prctl/ which only > has two files that should probably both be moved to security/) was > already on someone's TODO list? I'd love to get these done (I refer > people regularly to seccomp_filter.txt and self-protection.txt), but I > didn't want to duplicate any efforts. If anybody is working in that area, they've not told me about it. > I read about various tools to help with auto-converting files to kind > of help speed up the process, but I couldn't find what seemed a > canonical answer to what to use as a helper. Is there one? (Perhaps > this was only for DocBook?) The tools, such as they are, are for the conversion of DocBook template files. Most of the kernel's .txt files are already in something quite close to RST already, so the conversion is trivial. The real question would be one of organization. Most of the security stuff looks like it properly belongs in the admin guide, but that's not universally the case. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] em28xx: allow setting the eeprom bus at cards struct
On Mon, May 1, 2017 at 10:11 AM, Frank Schäfer wrote: > > Am 01.05.2017 um 13:38 schrieb Mauro Carvalho Chehab: >> Right now, all devices use bus 0 for eeprom. However, newer >> versions of Terratec H6 use a different buffer for eeprom. >> >> So, add support to use a different I2C address for eeprom. > > Has this been tested ? > Did you read my reply to the previous patch version ?: > See http://www.spinics.net/lists/linux-media/msg114860.html > > I doubt it will work. At least not for the device from the thread in the > Kodi-forum. Based on what I know about the Empia 2874/2884 design, I would be absolutely shocked if the eeprom was really on the second I2C bus. The boot code in ROM requires the eeprom to be on bus 0 in order to find the 8051 microcode to be executed. This is a documented hardware design requirement. I have seen designs where the first bus is accessible through an I2C gate on a demodulator on the second bus. This creates a multi-master situation and I have no idea why anyone would ever do this. However it does explain a situation where the EEPROM could be optionally accessed via the second bus (if the I2C gate on the demod was open at the time). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] em28xx: allow setting the eeprom bus at cards struct
Am 01.05.2017 um 13:38 schrieb Mauro Carvalho Chehab:
> Right now, all devices use bus 0 for eeprom. However, newer
> versions of Terratec H6 use a different buffer for eeprom.
>
> So, add support to use a different I2C address for eeprom.
Has this been tested ?
Did you read my reply to the previous patch version ?:
See http://www.spinics.net/lists/linux-media/msg114860.html
I doubt it will work. At least not for the device from the thread in the
Kodi-forum.
Regards,
Frank
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/usb/em28xx/em28xx-cards.c | 1 +
> drivers/media/usb/em28xx/em28xx-i2c.c | 5 +
> drivers/media/usb/em28xx/em28xx.h | 4 +++-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index a12b599a1fa2..c7754303e88e 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -2669,6 +2669,7 @@ static inline void em28xx_set_model(struct em28xx *dev)
>
> /* Should be initialized early, for I2C to work */
> dev->def_i2c_bus = dev->board.def_i2c_bus;
> + dev->eeprom_i2c_bus = dev->board.eeprom_i2c_bus;
> }
>
> /* Wait until AC97_RESET reports the expected value reliably before
> proceeding.
> diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
> b/drivers/media/usb/em28xx/em28xx-i2c.c
> index 8c472d5adb50..df0ab4b6f18f 100644
> --- a/drivers/media/usb/em28xx/em28xx-i2c.c
> +++ b/drivers/media/usb/em28xx/em28xx-i2c.c
> @@ -665,8 +665,6 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
> bus,
> *eedata = NULL;
> *eedata_len = 0;
>
> - /* EEPROM is always on i2c bus 0 on all known devices. */
> -
> dev->i2c_client[bus].addr = 0xa0 >> 1;
>
> /* Check if board has eeprom */
> @@ -975,8 +973,7 @@ int em28xx_i2c_register(struct em28xx *dev, unsigned bus,
> dev->i2c_client[bus] = em28xx_client_template;
> dev->i2c_client[bus].adapter = &dev->i2c_adap[bus];
>
> - /* Up to now, all eeproms are at bus 0 */
> - if (!bus) {
> + if (bus == dev->eeprom_i2c_bus) {
> retval = em28xx_i2c_eeprom(dev, bus, &dev->eedata,
> &dev->eedata_len);
> if ((retval < 0) && (retval != -ENODEV)) {
> dev_err(&dev->intf->dev,
> diff --git a/drivers/media/usb/em28xx/em28xx.h
> b/drivers/media/usb/em28xx/em28xx.h
> index e8d97d5ec161..8117536343ab 100644
> --- a/drivers/media/usb/em28xx/em28xx.h
> +++ b/drivers/media/usb/em28xx/em28xx.h
> @@ -440,7 +440,8 @@ struct em28xx_board {
> int vchannels;
> int tuner_type;
> int tuner_addr;
> - unsigned def_i2c_bus; /* Default I2C bus */
> + unsigned def_i2c_bus; /* Default I2C bus */
> + unsigned eeprom_i2c_bus;/* EEPROM I2C bus */
>
> /* i2c flags */
> unsigned int tda9887_conf;
> @@ -643,6 +644,7 @@ struct em28xx {
>
> unsigned char eeprom_addrwidth_16bit:1;
> unsigned def_i2c_bus; /* Default I2C bus */
> + unsigned eeprom_i2c_bus;/* EEPROM I2C bus */
> unsigned cur_i2c_bus; /* Current I2C bus */
> struct rt_mutex i2c_bus_lock;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] em28xx: allow setting the eeprom bus at cards struct
Right now, all devices use bus 0 for eeprom. However, newer
versions of Terratec H6 use a different buffer for eeprom.
So, add support to use a different I2C address for eeprom.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/em28xx/em28xx-cards.c | 1 +
drivers/media/usb/em28xx/em28xx-i2c.c | 5 +
drivers/media/usb/em28xx/em28xx.h | 4 +++-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index a12b599a1fa2..c7754303e88e 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2669,6 +2669,7 @@ static inline void em28xx_set_model(struct em28xx *dev)
/* Should be initialized early, for I2C to work */
dev->def_i2c_bus = dev->board.def_i2c_bus;
+ dev->eeprom_i2c_bus = dev->board.eeprom_i2c_bus;
}
/* Wait until AC97_RESET reports the expected value reliably before proceeding.
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 8c472d5adb50..df0ab4b6f18f 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -665,8 +665,6 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
bus,
*eedata = NULL;
*eedata_len = 0;
- /* EEPROM is always on i2c bus 0 on all known devices. */
-
dev->i2c_client[bus].addr = 0xa0 >> 1;
/* Check if board has eeprom */
@@ -975,8 +973,7 @@ int em28xx_i2c_register(struct em28xx *dev, unsigned bus,
dev->i2c_client[bus] = em28xx_client_template;
dev->i2c_client[bus].adapter = &dev->i2c_adap[bus];
- /* Up to now, all eeproms are at bus 0 */
- if (!bus) {
+ if (bus == dev->eeprom_i2c_bus) {
retval = em28xx_i2c_eeprom(dev, bus, &dev->eedata,
&dev->eedata_len);
if ((retval < 0) && (retval != -ENODEV)) {
dev_err(&dev->intf->dev,
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index e8d97d5ec161..8117536343ab 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -440,7 +440,8 @@ struct em28xx_board {
int vchannels;
int tuner_type;
int tuner_addr;
- unsigned def_i2c_bus; /* Default I2C bus */
+ unsigned def_i2c_bus; /* Default I2C bus */
+ unsigned eeprom_i2c_bus;/* EEPROM I2C bus */
/* i2c flags */
unsigned int tda9887_conf;
@@ -643,6 +644,7 @@ struct em28xx {
unsigned char eeprom_addrwidth_16bit:1;
unsigned def_i2c_bus; /* Default I2C bus */
+ unsigned eeprom_i2c_bus;/* EEPROM I2C bus */
unsigned cur_i2c_bus; /* Current I2C bus */
struct rt_mutex i2c_bus_lock;
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] em28xx: add support for new revisions of Terratec H6
There's a new version of Terratec H6 with uses USB ID
0ccd:10b2. This version is similar to the old one (with is
supported via the HTC entry), except that this one has the
eeprom on the second bus.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/em28xx/em28xx-cards.c | 19 +++
drivers/media/usb/em28xx/em28xx-dvb.c | 1 +
drivers/media/usb/em28xx/em28xx.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index c7754303e88e..b788ae0d5646 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -1193,6 +1193,23 @@ struct em28xx_board em28xx_boards[] = {
.i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
},
+ [EM2884_BOARD_TERRATEC_H6] = {
+ .name = "Terratec Cinergy H6",
+ .has_dvb = 1,
+ .ir_codes = RC_MAP_NEC_TERRATEC_CINERGY_XS,
+#if 0
+ .tuner_type = TUNER_PHILIPS_TDA8290,
+ .tuner_addr = 0x41,
+ .dvb_gpio = terratec_h5_digital, /* FIXME: probably wrong */
+ .tuner_gpio = terratec_h5_gpio,
+#else
+ .tuner_type = TUNER_ABSENT,
+#endif
+ .def_i2c_bus = 1,
+ .eeprom_i2c_bus = 1,
+ .i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
+ EM28XX_I2C_FREQ_400_KHZ,
+ },
[EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C] = {
.name = "Hauppauge WinTV HVR 930C",
.has_dvb = 1,
@@ -2496,6 +2513,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2884_BOARD_TERRATEC_H5 },
{ USB_DEVICE(0x0ccd, 0x10b6), /* H5 Rev. 3 */
.driver_info = EM2884_BOARD_TERRATEC_H5 },
+ { USB_DEVICE(0x0ccd, 0x10b2), /* H6 */
+ .driver_info = EM2884_BOARD_TERRATEC_H6 },
{ USB_DEVICE(0x0ccd, 0x0084),
.driver_info = EM2860_BOARD_TERRATEC_AV350 },
{ USB_DEVICE(0x0ccd, 0x0096),
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 82edd37f0d73..4a7db623fe29 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1522,6 +1522,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
break;
case EM2884_BOARD_ELGATO_EYETV_HYBRID_2008:
case EM2884_BOARD_CINERGY_HTC_STICK:
+ case EM2884_BOARD_TERRATEC_H6:
terratec_htc_stick_init(dev);
/* attach demodulator */
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index 8117536343ab..a333ca954129 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -148,6 +148,7 @@
#define EM28178_BOARD_PLEX_PX_BCUD98
#define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB 99
#define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 100
+#define EM2884_BOARD_TERRATEC_H6 101
/* Limits minimum and default number of buffers */
#define EM28XX_MIN_BUF 4
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
