[GIT PATCH] hwmon updates vs. 2.6.25-rc2
Hi Linus: Please pull from: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release You'll get one new driver, one bugfix (adm1026), a few cleanups and enhancements. This branch also includes the last of the patches which add individual alarm sysfs files to all drivers (thank you Jean!). Hopefully this is the last you'll hear from me before 2.6.25 final. Thanks & regards, Documentation/hwmon/adt7473 | 79 +++ Documentation/hwmon/coretemp |6 +- MAINTAINERS |2 +- drivers/hwmon/Kconfig| 10 + drivers/hwmon/Makefile |1 + drivers/hwmon/ad7418.c |2 +- drivers/hwmon/adm1021.c |6 +- drivers/hwmon/adm1025.c |2 +- drivers/hwmon/adm1026.c |4 +- drivers/hwmon/adm1029.c |6 +- drivers/hwmon/adm1031.c |2 +- drivers/hwmon/adm9240.c |2 +- drivers/hwmon/ads7828.c |2 +- drivers/hwmon/adt7470.c |2 +- drivers/hwmon/adt7473.c | 1157 ++ drivers/hwmon/applesmc.c | 29 +- drivers/hwmon/asb100.c |2 +- drivers/hwmon/atxp1.c|2 +- drivers/hwmon/coretemp.c | 119 +++-- drivers/hwmon/dme1737.c |2 +- drivers/hwmon/ds1621.c |2 +- drivers/hwmon/f75375s.c |2 +- drivers/hwmon/fscher.c |2 +- drivers/hwmon/fschmd.c |2 +- drivers/hwmon/fscpos.c |2 +- drivers/hwmon/gl518sm.c |2 +- drivers/hwmon/gl520sm.c |2 +- drivers/hwmon/lm63.c |2 +- drivers/hwmon/lm75.c |2 +- drivers/hwmon/lm77.c |3 +- drivers/hwmon/lm78.c |4 +- drivers/hwmon/lm80.c |4 +- drivers/hwmon/lm83.c |6 +- drivers/hwmon/lm85.c |2 +- drivers/hwmon/lm87.c |2 +- drivers/hwmon/lm90.c |6 +- drivers/hwmon/lm92.c | 20 +- drivers/hwmon/lm93.c |2 +- drivers/hwmon/max1619.c | 23 +- drivers/hwmon/max6650.c |3 +- drivers/hwmon/smsc47m1.c | 25 +- drivers/hwmon/smsc47m192.c |2 +- drivers/hwmon/thmc50.c |8 +- drivers/hwmon/via686a.c | 28 + drivers/hwmon/vt8231.c | 44 ++- drivers/hwmon/w83781d.c |4 +- drivers/hwmon/w83791d.c |3 +- drivers/hwmon/w83792d.c |3 +- drivers/hwmon/w83793.c |3 +- drivers/hwmon/w83l785ts.c|2 +- drivers/hwmon/w83l786ng.c|2 +- 51 files changed, 1534 insertions(+), 120 deletions(-) create mode 100644 Documentation/hwmon/adt7473 create mode 100644 drivers/hwmon/adt7473.c Darrick J. Wong (1): hwmon: New driver for Analog Devices ADT7473 sensor chip Jean Delvare (6): hwmon: (lm92) Add individual alarm files hwmon: (max1619) Add individual alarm and fault files hwmon: (smsc47m1) Add individual alarm files hwmon: (via686a) Add individual alarm files hwmon: (vt8231) Add individual alarm files hwmon: (adm1026) Properly terminate sysfs groups Mark M. Hoffman (1): hwmon: normal_i2c arrays should be const Riki Oktarianto (1): hwmon: (applesmc) sensors set for MacBook2 Roger Lucas (1): hwmon: (vt8231) Update maintainer email address Rudolf Marek (3): hwmon: (coretemp) Add maximum cooling temperature readout hwmon: (coretemp) Add TjMax detection for mobile CPUs hwmon: (coretemp) Add Penryn CPU to coretemp Sam Ravnborg (1): hwmon: (coretemp) fix section mismatch warning Tobias Klauser (1): hwmon: (thmc50) Storage class should be before const qualifier -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates vs. 2.6.25-rc2
Hi Linus: Please pull from: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release You'll get one new driver, one bugfix (adm1026), a few cleanups and enhancements. This branch also includes the last of the patches which add individual alarm sysfs files to all drivers (thank you Jean!). Hopefully this is the last you'll hear from me before 2.6.25 final. Thanks regards, Documentation/hwmon/adt7473 | 79 +++ Documentation/hwmon/coretemp |6 +- MAINTAINERS |2 +- drivers/hwmon/Kconfig| 10 + drivers/hwmon/Makefile |1 + drivers/hwmon/ad7418.c |2 +- drivers/hwmon/adm1021.c |6 +- drivers/hwmon/adm1025.c |2 +- drivers/hwmon/adm1026.c |4 +- drivers/hwmon/adm1029.c |6 +- drivers/hwmon/adm1031.c |2 +- drivers/hwmon/adm9240.c |2 +- drivers/hwmon/ads7828.c |2 +- drivers/hwmon/adt7470.c |2 +- drivers/hwmon/adt7473.c | 1157 ++ drivers/hwmon/applesmc.c | 29 +- drivers/hwmon/asb100.c |2 +- drivers/hwmon/atxp1.c|2 +- drivers/hwmon/coretemp.c | 119 +++-- drivers/hwmon/dme1737.c |2 +- drivers/hwmon/ds1621.c |2 +- drivers/hwmon/f75375s.c |2 +- drivers/hwmon/fscher.c |2 +- drivers/hwmon/fschmd.c |2 +- drivers/hwmon/fscpos.c |2 +- drivers/hwmon/gl518sm.c |2 +- drivers/hwmon/gl520sm.c |2 +- drivers/hwmon/lm63.c |2 +- drivers/hwmon/lm75.c |2 +- drivers/hwmon/lm77.c |3 +- drivers/hwmon/lm78.c |4 +- drivers/hwmon/lm80.c |4 +- drivers/hwmon/lm83.c |6 +- drivers/hwmon/lm85.c |2 +- drivers/hwmon/lm87.c |2 +- drivers/hwmon/lm90.c |6 +- drivers/hwmon/lm92.c | 20 +- drivers/hwmon/lm93.c |2 +- drivers/hwmon/max1619.c | 23 +- drivers/hwmon/max6650.c |3 +- drivers/hwmon/smsc47m1.c | 25 +- drivers/hwmon/smsc47m192.c |2 +- drivers/hwmon/thmc50.c |8 +- drivers/hwmon/via686a.c | 28 + drivers/hwmon/vt8231.c | 44 ++- drivers/hwmon/w83781d.c |4 +- drivers/hwmon/w83791d.c |3 +- drivers/hwmon/w83792d.c |3 +- drivers/hwmon/w83793.c |3 +- drivers/hwmon/w83l785ts.c|2 +- drivers/hwmon/w83l786ng.c|2 +- 51 files changed, 1534 insertions(+), 120 deletions(-) create mode 100644 Documentation/hwmon/adt7473 create mode 100644 drivers/hwmon/adt7473.c Darrick J. Wong (1): hwmon: New driver for Analog Devices ADT7473 sensor chip Jean Delvare (6): hwmon: (lm92) Add individual alarm files hwmon: (max1619) Add individual alarm and fault files hwmon: (smsc47m1) Add individual alarm files hwmon: (via686a) Add individual alarm files hwmon: (vt8231) Add individual alarm files hwmon: (adm1026) Properly terminate sysfs groups Mark M. Hoffman (1): hwmon: normal_i2c arrays should be const Riki Oktarianto (1): hwmon: (applesmc) sensors set for MacBook2 Roger Lucas (1): hwmon: (vt8231) Update maintainer email address Rudolf Marek (3): hwmon: (coretemp) Add maximum cooling temperature readout hwmon: (coretemp) Add TjMax detection for mobile CPUs hwmon: (coretemp) Add Penryn CPU to coretemp Sam Ravnborg (1): hwmon: (coretemp) fix section mismatch warning Tobias Klauser (1): hwmon: (thmc50) Storage class should be before const qualifier -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH v2] adt7473: New driver for Analog Devices ADT7473 sensor chip
Hi Darrick: * Darrick J. Wong <[EMAIL PROTECTED]> [2008-02-18 13:33:23 -0800]: > adt7473: New driver for Analog Devices ADT7473 sensor chip > > This driver reports voltage, temperature and fan sensor readings > on an ADT7473 chip. > > Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]> > --- > > Documentation/hwmon/adt7473 | 79 +++ > drivers/hwmon/Kconfig | 10 > drivers/hwmon/Makefile |1 > drivers/hwmon/adt7473.c | 1157 > +++ > 4 files changed, 1247 insertions(+), 0 deletions(-) > Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH v2] adt7473: New driver for Analog Devices ADT7473 sensor chip
Hi Darrick: * Darrick J. Wong [EMAIL PROTECTED] [2008-02-18 13:33:23 -0800]: adt7473: New driver for Analog Devices ADT7473 sensor chip This driver reports voltage, temperature and fan sensor readings on an ADT7473 chip. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] --- Documentation/hwmon/adt7473 | 79 +++ drivers/hwmon/Kconfig | 10 drivers/hwmon/Makefile |1 drivers/hwmon/adt7473.c | 1157 +++ 4 files changed, 1247 insertions(+), 0 deletions(-) Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH] adt7473: New driver for Analog Devices ADT7473 sensor chip
Hi Darrick:
Sorry this took forever for me to review. Just a few little things...
* Darrick J. Wong <[EMAIL PROTECTED]> [2007-12-19 15:14:38 -0800]:
> This driver also had that funny alarm1/alarm2 thing; here's a revision
> of yesterday's patch with that straightened out.
> ---
> This driver reports voltage, temperature and fan sensor readings
> on an ADT7473 chip.
>
> Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]>
> ---
>
> drivers/hwmon/Kconfig | 10
> drivers/hwmon/Makefile |1
> drivers/hwmon/adt7473.c | 1161
> +++
> 3 files changed, 1172 insertions(+), 0 deletions(-)
>
Documentation/hwmon/adt7473 would be nice.
> new file mode 100644
> index 000..5528d5c
> --- /dev/null
> +++ b/drivers/hwmon/adt7473.c
> @@ -0,0 +1,1161 @@
(snip)
> +/*
> + * On this chip, voltages are given as a count of steps between a minimum
> + * and maximum voltage, not a direct voltage.
> + */
> +static int volt_convert_table[][2] = {
> + {2997, 3},
> + {4395, 4},
> +};
That should be const.
(snip)
> +static ssize_t show_pwm_auto_temp(struct device *dev,
> + struct device_attribute *devattr,
> + char *buf)
> +{
> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
> + struct adt7473_data *data = adt7473_update_device(dev);
> + int bhvr = data->pwm_behavior[attr->index] >> ADT7473_PWM_BHVR_SHIFT;
> +
> + switch (bhvr) {
> + case 3:
> + case 4:
> + case 7:
> + return sprintf(buf, "0\n");
> + case 0:
> + case 1:
> + case 5:
> + case 6:
> + return sprintf(buf, "%d\n", bhvr + 1);
> + case 2:
> + return sprintf(buf, "4\n");
> + }
> + BUG();
Given ADT7473_PWM_BHVR_SHIFT is 5, this BUG() is obviously impossible.
But I guess it's not obvious to GCC.
(snip)
> +static int adt7473_attach_adapter(struct i2c_adapter *adapter)
> +{
> + /*
> + * Some NVIDIA cards have an adt7473 attached to the on-board
> + * i2c controller, but the i2c adapter driver in the binary
> + * nvidia superblob driver sets class to 0.
> + */
> + if (!(adapter->class & I2C_CLASS_HWMON) && adapter->class)
> + return 0;
NACK on that comment and associated code: Jean Delvare submitted a
patch to NVIDIA over two years ago to fix their bug. Apparently some
distros even carry his patch. So, I don't want to encourage such a
hack to persist. Please just do the standard check here.
> + return i2c_probe(adapter, _data, adt7473_detect);
> +}
(snip)
Thanks & regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: first tree
Hi Stephen: * Stephen Rothwell <[EMAIL PROTECTED]> [2008-02-15 00:35:37 +1100]: > I have created the first cut of the linux-next tree at > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git. > > Things to know about this tree: > > It has two branches - master and stable. Stable is currently just Linus' > tree and will never rebase. Master will rebase on an almost daily basis > (maybe slower at the start). > > The tree consists of subsystem git and quilt trees. Currently, the quilt > trees are integrated by importing them into appropriately based git > branches and then merging those branches. This has the advantage that > any conflict resolution will onlt have to happen once at the merge point > rather than, possibly, sevveral times during the series. However, I am > considering just applying the quilt trees on top of the current tree > to get a result more like Linus' tree - we will see. The git trees are > obviously just merged. > > Between each merge, the tree was built with both an allmodconfig for both > powerpc and x86_64. > > The tree currently contains: > Greg's driver-core, pci and usb quilt series (in that order) > Alasdair Kergon's device-mapper quilt tree > Jiri Kosina's hid git tree > Jean Delvare's i2c quilt tree > Randy Dunlap's kernel-doc quilt tree > Haavard Skinnemoen's avr32 git tree > > There was only one unresolved conflict which could have been caused > because I was not sure where to base the kernel-doc tree. > > So, comments, please. > > Also, more trees please ... :-) You can add the hwmon testing tree (from MAINTAINERS): > git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git testing This tree gets rebased pretty much whenever Linus adds a new tag. As a rule of thumb, you should merge from Jean Delvare's i2c tree first. The hwmon/testing tree does not usually depend on anything else. Thanks & regards, -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/27] hwmon: fix section mismatch in coretemp
Hi Sam:
* Sam Ravnborg <[EMAIL PROTECTED]> [2008-02-17 13:22:51 +0100]:
> Fix following warning:
> WARNING: vmlinux.o(.text+0xebfd04): Section mismatch in reference from the
> function coretemp_cpu_callback() to the function
> .cpuinit.text:coretemp_device_add()
>
> coretemp_cpu_callback() are only used inside a
> HOTPLUG_CPU block so annotate it __cpuinit.
> The notifier referencing the function are annotated
> __refdata to silence warning from the exit function.
> The unregister function do not use the embedded pointer
> but clears the variable so the annotation is OK.
>
> Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
> Cc: Mark M. Hoffman <[EMAIL PROTECTED]>
> ---
> drivers/hwmon/coretemp.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
> index 3ee60d2..1439432 100644
> --- a/drivers/hwmon/coretemp.c
> +++ b/drivers/hwmon/coretemp.c
> @@ -330,7 +330,7 @@ static void coretemp_device_remove(unsigned int cpu)
> mutex_unlock(_list_mutex);
> }
>
> -static int coretemp_cpu_callback(struct notifier_block *nfb,
> +static int __cpuinit coretemp_cpu_callback(struct notifier_block *nfb,
>unsigned long action, void *hcpu)
> {
> unsigned int cpu = (unsigned long) hcpu;
> @@ -347,7 +347,7 @@ static int coretemp_cpu_callback(struct notifier_block
> *nfb,
> return NOTIFY_OK;
> }
>
> -static struct notifier_block coretemp_cpu_notifier = {
> +static struct notifier_block coretemp_cpu_notifier __refdata = {
> .notifier_call = coretemp_cpu_callback,
> };
> #endif /* !CONFIG_HOTPLUG_CPU */
> --
> 1.5.4.rc3.14.g44397
This rings a bell... hmmm, commit 59a35bafb223bbb0553ba1a3bb9280bda668a8d8.
AFAICT the warning is a false positive, but whatever.
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/27] hwmon: fix section mismatch in coretemp
Hi Sam:
* Sam Ravnborg [EMAIL PROTECTED] [2008-02-17 13:22:51 +0100]:
Fix following warning:
WARNING: vmlinux.o(.text+0xebfd04): Section mismatch in reference from the
function coretemp_cpu_callback() to the function
.cpuinit.text:coretemp_device_add()
coretemp_cpu_callback() are only used inside a
HOTPLUG_CPU block so annotate it __cpuinit.
The notifier referencing the function are annotated
__refdata to silence warning from the exit function.
The unregister function do not use the embedded pointer
but clears the variable so the annotation is OK.
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
Cc: Mark M. Hoffman [EMAIL PROTECTED]
---
drivers/hwmon/coretemp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 3ee60d2..1439432 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -330,7 +330,7 @@ static void coretemp_device_remove(unsigned int cpu)
mutex_unlock(pdev_list_mutex);
}
-static int coretemp_cpu_callback(struct notifier_block *nfb,
+static int __cpuinit coretemp_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
unsigned int cpu = (unsigned long) hcpu;
@@ -347,7 +347,7 @@ static int coretemp_cpu_callback(struct notifier_block
*nfb,
return NOTIFY_OK;
}
-static struct notifier_block coretemp_cpu_notifier = {
+static struct notifier_block coretemp_cpu_notifier __refdata = {
.notifier_call = coretemp_cpu_callback,
};
#endif /* !CONFIG_HOTPLUG_CPU */
--
1.5.4.rc3.14.g44397
This rings a bell... hmmm, commit 59a35bafb223bbb0553ba1a3bb9280bda668a8d8.
AFAICT the warning is a false positive, but whatever.
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: first tree
Hi Stephen: * Stephen Rothwell [EMAIL PROTECTED] [2008-02-15 00:35:37 +1100]: I have created the first cut of the linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git. Things to know about this tree: It has two branches - master and stable. Stable is currently just Linus' tree and will never rebase. Master will rebase on an almost daily basis (maybe slower at the start). The tree consists of subsystem git and quilt trees. Currently, the quilt trees are integrated by importing them into appropriately based git branches and then merging those branches. This has the advantage that any conflict resolution will onlt have to happen once at the merge point rather than, possibly, sevveral times during the series. However, I am considering just applying the quilt trees on top of the current tree to get a result more like Linus' tree - we will see. The git trees are obviously just merged. Between each merge, the tree was built with both an allmodconfig for both powerpc and x86_64. The tree currently contains: Greg's driver-core, pci and usb quilt series (in that order) Alasdair Kergon's device-mapper quilt tree Jiri Kosina's hid git tree Jean Delvare's i2c quilt tree Randy Dunlap's kernel-doc quilt tree Haavard Skinnemoen's avr32 git tree There was only one unresolved conflict which could have been caused because I was not sure where to base the kernel-doc tree. So, comments, please. Also, more trees please ... :-) You can add the hwmon testing tree (from MAINTAINERS): git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git testing This tree gets rebased pretty much whenever Linus adds a new tag. As a rule of thumb, you should merge from Jean Delvare's i2c tree first. The hwmon/testing tree does not usually depend on anything else. Thanks regards, -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH] adt7473: New driver for Analog Devices ADT7473 sensor chip
Hi Darrick:
Sorry this took forever for me to review. Just a few little things...
* Darrick J. Wong [EMAIL PROTECTED] [2007-12-19 15:14:38 -0800]:
This driver also had that funny alarm1/alarm2 thing; here's a revision
of yesterday's patch with that straightened out.
---
This driver reports voltage, temperature and fan sensor readings
on an ADT7473 chip.
Signed-off-by: Darrick J. Wong [EMAIL PROTECTED]
---
drivers/hwmon/Kconfig | 10
drivers/hwmon/Makefile |1
drivers/hwmon/adt7473.c | 1161
+++
3 files changed, 1172 insertions(+), 0 deletions(-)
Documentation/hwmon/adt7473 would be nice.
new file mode 100644
index 000..5528d5c
--- /dev/null
+++ b/drivers/hwmon/adt7473.c
@@ -0,0 +1,1161 @@
(snip)
+/*
+ * On this chip, voltages are given as a count of steps between a minimum
+ * and maximum voltage, not a direct voltage.
+ */
+static int volt_convert_table[][2] = {
+ {2997, 3},
+ {4395, 4},
+};
That should be const.
(snip)
+static ssize_t show_pwm_auto_temp(struct device *dev,
+ struct device_attribute *devattr,
+ char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct adt7473_data *data = adt7473_update_device(dev);
+ int bhvr = data-pwm_behavior[attr-index] ADT7473_PWM_BHVR_SHIFT;
+
+ switch (bhvr) {
+ case 3:
+ case 4:
+ case 7:
+ return sprintf(buf, 0\n);
+ case 0:
+ case 1:
+ case 5:
+ case 6:
+ return sprintf(buf, %d\n, bhvr + 1);
+ case 2:
+ return sprintf(buf, 4\n);
+ }
+ BUG();
Given ADT7473_PWM_BHVR_SHIFT is 5, this BUG() is obviously impossible.
But I guess it's not obvious to GCC.
(snip)
+static int adt7473_attach_adapter(struct i2c_adapter *adapter)
+{
+ /*
+ * Some NVIDIA cards have an adt7473 attached to the on-board
+ * i2c controller, but the i2c adapter driver in the binary
+ * nvidia superblob driver sets class to 0.
+ */
+ if (!(adapter-class I2C_CLASS_HWMON) adapter-class)
+ return 0;
NACK on that comment and associated code: Jean Delvare submitted a
patch to NVIDIA over two years ago to fix their bug. Apparently some
distros even carry his patch. So, I don't want to encourage such a
hack to persist. Please just do the standard check here.
+ return i2c_probe(adapter, addr_data, adt7473_detect);
+}
(snip)
Thanks regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] Provide acpi_check_{mem_}region.
Hi Andrew, Jean: * Jean Delvare <[EMAIL PROTECTED]> [2008-02-11 22:18:29 +0100]: > On Mon, 11 Feb 2008 11:55:46 -0800, Andrew Morton wrote: > > On Sun, 10 Feb 2008 13:25:36 +0100 Jean Delvare wrote: > > > Andrew, both patches are > > > > > > Acked-by: Jean Delvare <[EMAIL PROTECTED]> > > > > We already have Signed-off-by:you, which I figure outranks acked-by: ;) > > Yeah but that wasn't the same me. That was me-developer-at-suse, > who doesn't yet have the same aura as > me-maintainer-of-i2c-and-former-maintainer-of-hwmon ;) > > > > and I am totally fine with you pushing them to Linus now. But of course > > > having Mark's ack would be good too. > > > > That would be nice. But I'll merge them mid-week anyway unless Mark > > actually > > nacks them: > > > > http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch > > > > http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch > > Yeah, sounds like a good plan, thanks for taking care. OK, I pulled the first of those into my hwmon testing tree and merged it, since there are trivial conflicts with some of the other patches already there. I'll send it to Linus before -rc2. Andrew: hopefully that makes your life .001% easier. ;) Regards, -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hwmon: (adm1026) Properly terminate sysfs groups (Was: panic about sysfs with adm1026)
Hi Jean et. al.:
* Jean Delvare <[EMAIL PROTECTED]> [2008-02-10 19:01:15 +0100]:
> The missing NULL at the end of two sysfs file groups causes a kernel
> crash when calling sysfs_create_group().
>
> Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
> ---
> drivers/hwmon/adm1026.c |2 ++
> 1 file changed, 2 insertions(+)
>
> --- linux-2.6.25-rc0.orig/drivers/hwmon/adm1026.c 2008-02-10
> 11:21:54.0 +0100
> +++ linux-2.6.25-rc0/drivers/hwmon/adm1026.c 2008-02-10 18:51:00.0
> +0100
> @@ -1624,6 +1624,7 @@ static struct attribute *adm1026_attribu
> _attr_temp3_crit_enable.attr,
> _attr_temp3_auto_point1_pwm.attr,
> _attr_temp3_auto_point2_pwm.attr,
> + NULL
> };
>
> static const struct attribute_group adm1026_group_temp3 = {
> @@ -1639,6 +1640,7 @@ static struct attribute *adm1026_attribu
> _dev_attr_in9_max.dev_attr.attr,
> _dev_attr_in9_min.dev_attr.attr,
> _dev_attr_in9_alarm.dev_attr.attr,
> + NULL
> };
>
> static const struct attribute_group adm1026_group_in8_9 = {
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hwmon: (adm1026) Properly terminate sysfs groups (Was: panic about sysfs with adm1026)
Hi Jean et. al.:
* Jean Delvare [EMAIL PROTECTED] [2008-02-10 19:01:15 +0100]:
The missing NULL at the end of two sysfs file groups causes a kernel
crash when calling sysfs_create_group().
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/hwmon/adm1026.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.25-rc0.orig/drivers/hwmon/adm1026.c 2008-02-10
11:21:54.0 +0100
+++ linux-2.6.25-rc0/drivers/hwmon/adm1026.c 2008-02-10 18:51:00.0
+0100
@@ -1624,6 +1624,7 @@ static struct attribute *adm1026_attribu
dev_attr_temp3_crit_enable.attr,
dev_attr_temp3_auto_point1_pwm.attr,
dev_attr_temp3_auto_point2_pwm.attr,
+ NULL
};
static const struct attribute_group adm1026_group_temp3 = {
@@ -1639,6 +1640,7 @@ static struct attribute *adm1026_attribu
sensor_dev_attr_in9_max.dev_attr.attr,
sensor_dev_attr_in9_min.dev_attr.attr,
sensor_dev_attr_in9_alarm.dev_attr.attr,
+ NULL
};
static const struct attribute_group adm1026_group_in8_9 = {
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] Provide acpi_check_{mem_}region.
Hi Andrew, Jean: * Jean Delvare [EMAIL PROTECTED] [2008-02-11 22:18:29 +0100]: On Mon, 11 Feb 2008 11:55:46 -0800, Andrew Morton wrote: On Sun, 10 Feb 2008 13:25:36 +0100 Jean Delvare wrote: Andrew, both patches are Acked-by: Jean Delvare [EMAIL PROTECTED] We already have Signed-off-by:you, which I figure outranks acked-by: ;) Yeah but that wasn't the same me. That was me-developer-at-suse, who doesn't yet have the same aura as me-maintainer-of-i2c-and-former-maintainer-of-hwmon ;) and I am totally fine with you pushing them to Linus now. But of course having Mark's ack would be good too. That would be nice. But I'll merge them mid-week anyway unless Mark actually nacks them: http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch Yeah, sounds like a good plan, thanks for taking care. OK, I pulled the first of those into my hwmon testing tree and merged it, since there are trivial conflicts with some of the other patches already there. I'll send it to Linus before -rc2. Andrew: hopefully that makes your life .001% easier. ;) Regards, -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates against v2.6.24 (~git17)
wmon: (adm1026) More cleanups (updated) hwmon: (adm1026) Don't create files for missing inputs hwmon: (w83781d) Drop W83627HF support hwmon: (w83781d) Misc cleanups hwmon: (it87) Delete pwmN_freq files on driver removal hwmon: (adm1031) Fix register overwrite in set_fan_div() hwmon: (adm1031) Various cleanups hwmon: (adm1031) Get rid of macro-generated wrappers hwmon: (adm1031) Add individual alarm and fault files hwmon: (lm85) Return standard values in pwmN_enable hwmon: (lm85) Make the pwmN_enable files writable hwmon: Discard useless I2C driver IDs hwmon: (lm77) Add individual alarm files hwmon: (adm9240) Add individual alarm files hwmon: VRM is not written to registers hwmon: (asb100) Various cleanups hwmon: (asb100) De-macro the sysfs callbacks hwmon: (asb100) Add individual alarm files hwmon: (w83627ehf) The W83627DHG has 8 VID pins hwmon: (w83627hf) Enable VBAT monitoring hwmon: (w83627hf) Add individual alarm and beep files hwmon: (w83627hf) Refactor beep enable handling hwmon: (lm80) Various cleanups hwmon: (lm80) De-macro the sysfs callbacks hwmon: (lm80) Add individual alarm files Joe Perches (1): hwmon: (vt8231) Add missing "space" Juerg Haefliger (2): hwmon: (dme1737) fix divide-by-0 hwmon: (dme1737) fix Super-IO device ID override Kevin Lo (1): hwmon: Add support for Winbond W83L786NG/NR Nicolas Kaiser (1): hwmon: (w83793) remove duplicated defines Robert P. J. Day (1): hwmon: (adt7470) Replace power-of-two test Sergey Vlasov (1): hwmon: (abituguru3) Add AUX4 fan input for Abit IP35 Pro Steve Hardy (1): hwmon: Add support for Texas Instruments/Burr-Brown ADS7828 -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates against v2.6.24 (~git17)
: (adm1026) More cleanups (updated) hwmon: (adm1026) Don't create files for missing inputs hwmon: (w83781d) Drop W83627HF support hwmon: (w83781d) Misc cleanups hwmon: (it87) Delete pwmN_freq files on driver removal hwmon: (adm1031) Fix register overwrite in set_fan_div() hwmon: (adm1031) Various cleanups hwmon: (adm1031) Get rid of macro-generated wrappers hwmon: (adm1031) Add individual alarm and fault files hwmon: (lm85) Return standard values in pwmN_enable hwmon: (lm85) Make the pwmN_enable files writable hwmon: Discard useless I2C driver IDs hwmon: (lm77) Add individual alarm files hwmon: (adm9240) Add individual alarm files hwmon: VRM is not written to registers hwmon: (asb100) Various cleanups hwmon: (asb100) De-macro the sysfs callbacks hwmon: (asb100) Add individual alarm files hwmon: (w83627ehf) The W83627DHG has 8 VID pins hwmon: (w83627hf) Enable VBAT monitoring hwmon: (w83627hf) Add individual alarm and beep files hwmon: (w83627hf) Refactor beep enable handling hwmon: (lm80) Various cleanups hwmon: (lm80) De-macro the sysfs callbacks hwmon: (lm80) Add individual alarm files Joe Perches (1): hwmon: (vt8231) Add missing space Juerg Haefliger (2): hwmon: (dme1737) fix divide-by-0 hwmon: (dme1737) fix Super-IO device ID override Kevin Lo (1): hwmon: Add support for Winbond W83L786NG/NR Nicolas Kaiser (1): hwmon: (w83793) remove duplicated defines Robert P. J. Day (1): hwmon: (adt7470) Replace power-of-two test Sergey Vlasov (1): hwmon: (abituguru3) Add AUX4 fan input for Abit IP35 Pro Steve Hardy (1): hwmon: Add support for Texas Instruments/Burr-Brown ADS7828 -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH] adt7470: Support per-sensor alarm files
Hi Darrick: * Darrick J. Wong <[EMAIL PROTECTED]> [2007-12-19 14:11:25 -0800]: > On Wed, Dec 19, 2007 at 03:40:12PM +0100, Jean Delvare wrote: > > In general we keep the all-in-one alarms file for compatibility, but > > given that this driver is fairly new and libsensors never had specific > > support for it anyway, it's probably OK to drop it this time. > > Thanks for the code review. I've made the changes you asked for and > here's a new patch to supersede yesterday's. > --- > Remove the old alarms hack and replace it with per-sensor alarm files. > > Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]> > --- > > drivers/hwmon/adt7470.c | 96 > +-- > 1 files changed, 84 insertions(+), 12 deletions(-) Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH] adt7470: Support per-sensor alarm files
Hi Darrick: * Darrick J. Wong [EMAIL PROTECTED] [2007-12-19 14:11:25 -0800]: On Wed, Dec 19, 2007 at 03:40:12PM +0100, Jean Delvare wrote: In general we keep the all-in-one alarms file for compatibility, but given that this driver is fairly new and libsensors never had specific support for it anyway, it's probably OK to drop it this time. Thanks for the code review. I've made the changes you asked for and here's a new patch to supersede yesterday's. --- Remove the old alarms hack and replace it with per-sensor alarm files. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] --- drivers/hwmon/adt7470.c | 96 +-- 1 files changed, 84 insertions(+), 12 deletions(-) Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon update against v2.6.24-rc8+
Hi Linus:
Please pull from:
git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release
You'll get one patch (attached) which fixes a regression for it87.
See below for details.
Thanks & regards,
commit 87b4b6634ac112ddfe7b92aae50eb4bf7b128d1a
Author: Bjorn Helgaas <[EMAIL PROTECTED]>
Date: Tue Jan 22 07:21:03 2008 -0500
hwmon: (it87) request only Environment Controller ports
The IT8705F and related parts are Super I/O controllers that contain
many separate devices.
Some BIOSes describe IT8705F I/O port usage under a motherboard device
(PNP0C02) with overlapping regions, e.g., 0x290-0x29f and 0x290-0x294.
The it87 driver supports only the Environment Controller, which requires
only two ISA ports, but it used to request an eight-port range. If that
range exceeds a range reported by the BIOS, as 0x290-0x297 would, the
request fails, and the it87 driver cannot claim the device.
This patch makes the it87 driver request only the two ports used for the
Environment Controller device.
Systems where this problem has been reported:
Gigabyte GA-K8N Ultra 9
Gigabyte M56S-S3
Gigabyte GA-965G-DS3
Kernel bug reports:
http://bugzilla.kernel.org/show_bug.cgi?id=9514
http://lkml.org/lkml/2007/12/4/466
Related change:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7839e960675b549f06209d18283d5cee2ce9261
The patch above increases the number of PNP port resources we support.
Prior to this patch, we ignored some port resources, which masked the
it87 problem.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]>
diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
index 6a182e1..ad6c8a3 100644
--- a/drivers/hwmon/it87.c
+++ b/drivers/hwmon/it87.c
@@ -2,6 +2,14 @@
it87.c - Part of lm_sensors, Linux kernel modules for hardware
monitoring.
+The IT8705F is an LPC-based Super I/O part that contains UARTs, a
+parallel port, an IR port, a MIDI port, a floppy controller, etc., in
+addition to an Environment Controller (Enhanced Hardware Monitor and
+Fan Controller)
+
+This driver supports only the Environment Controller in the IT8705F and
+similar parts. The other devices are supported by different drivers.
+
Supports: IT8705F Super I/O chip w/LPC interface
IT8712F Super I/O chip w/LPC interface
IT8716F Super I/O chip w/LPC interface
@@ -118,9 +126,15 @@ static int fix_pwm_polarity;
/* Length of ISA address segment */
#define IT87_EXTENT 8
-/* Where are the ISA address/data registers relative to the base address */
-#define IT87_ADDR_REG_OFFSET 5
-#define IT87_DATA_REG_OFFSET 6
+/* Length of ISA address segment for Environmental Controller */
+#define IT87_EC_EXTENT 2
+
+/* Offset of EC registers from ISA base address */
+#define IT87_EC_OFFSET 5
+
+/* Where are the ISA address/data registers relative to the EC base address */
+#define IT87_ADDR_REG_OFFSET 0
+#define IT87_DATA_REG_OFFSET 1
/*- The IT87 registers -*/
@@ -968,10 +982,10 @@ static int __devinit it87_probe(struct platform_device
*pdev)
};
res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (!request_region(res->start, IT87_EXTENT, DRVNAME)) {
+ if (!request_region(res->start, IT87_EC_EXTENT, DRVNAME)) {
dev_err(dev, "Failed to request region 0x%lx-0x%lx\n",
(unsigned long)res->start,
- (unsigned long)(res->start + IT87_EXTENT - 1));
+ (unsigned long)(res->start + IT87_EC_EXTENT - 1));
err = -EBUSY;
goto ERROR0;
}
@@ -1124,7 +1138,7 @@ ERROR2:
platform_set_drvdata(pdev, NULL);
kfree(data);
ERROR1:
- release_region(res->start, IT87_EXTENT);
+ release_region(res->start, IT87_EC_EXTENT);
ERROR0:
return err;
}
@@ -1137,7 +1151,7 @@ static int __devexit it87_remove(struct platform_device
*pdev)
sysfs_remove_group(>dev.kobj, _group);
sysfs_remove_group(>dev.kobj, _group_opt);
- release_region(data->addr, IT87_EXTENT);
+ release_region(data->addr, IT87_EC_EXTENT);
platform_set_drvdata(pdev, NULL);
kfree(data);
@@ -1402,8 +1416,8 @@ static int __init it87_device_add(unsigned short address,
const struct it87_sio_data *sio_data)
{
struct resource res = {
- .start = address ,
- .end= address + IT87_EXTENT - 1,
+ .start = address + IT87_EC_OFFSET,
+ .end= address + IT87_EC_OFFSET + IT87_EC_EXTENT - 1,
.name = DRVNAME,
.flags = IORESOURCE_IO,
};
--
Ma
[GIT PATCH] hwmon update against v2.6.24-rc8+
Hi Linus:
Please pull from:
git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release
You'll get one patch (attached) which fixes a regression for it87.
See below for details.
Thanks regards,
commit 87b4b6634ac112ddfe7b92aae50eb4bf7b128d1a
Author: Bjorn Helgaas [EMAIL PROTECTED]
Date: Tue Jan 22 07:21:03 2008 -0500
hwmon: (it87) request only Environment Controller ports
The IT8705F and related parts are Super I/O controllers that contain
many separate devices.
Some BIOSes describe IT8705F I/O port usage under a motherboard device
(PNP0C02) with overlapping regions, e.g., 0x290-0x29f and 0x290-0x294.
The it87 driver supports only the Environment Controller, which requires
only two ISA ports, but it used to request an eight-port range. If that
range exceeds a range reported by the BIOS, as 0x290-0x297 would, the
request fails, and the it87 driver cannot claim the device.
This patch makes the it87 driver request only the two ports used for the
Environment Controller device.
Systems where this problem has been reported:
Gigabyte GA-K8N Ultra 9
Gigabyte M56S-S3
Gigabyte GA-965G-DS3
Kernel bug reports:
http://bugzilla.kernel.org/show_bug.cgi?id=9514
http://lkml.org/lkml/2007/12/4/466
Related change:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7839e960675b549f06209d18283d5cee2ce9261
The patch above increases the number of PNP port resources we support.
Prior to this patch, we ignored some port resources, which masked the
it87 problem.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Signed-off-by: Mark M. Hoffman [EMAIL PROTECTED]
diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
index 6a182e1..ad6c8a3 100644
--- a/drivers/hwmon/it87.c
+++ b/drivers/hwmon/it87.c
@@ -2,6 +2,14 @@
it87.c - Part of lm_sensors, Linux kernel modules for hardware
monitoring.
+The IT8705F is an LPC-based Super I/O part that contains UARTs, a
+parallel port, an IR port, a MIDI port, a floppy controller, etc., in
+addition to an Environment Controller (Enhanced Hardware Monitor and
+Fan Controller)
+
+This driver supports only the Environment Controller in the IT8705F and
+similar parts. The other devices are supported by different drivers.
+
Supports: IT8705F Super I/O chip w/LPC interface
IT8712F Super I/O chip w/LPC interface
IT8716F Super I/O chip w/LPC interface
@@ -118,9 +126,15 @@ static int fix_pwm_polarity;
/* Length of ISA address segment */
#define IT87_EXTENT 8
-/* Where are the ISA address/data registers relative to the base address */
-#define IT87_ADDR_REG_OFFSET 5
-#define IT87_DATA_REG_OFFSET 6
+/* Length of ISA address segment for Environmental Controller */
+#define IT87_EC_EXTENT 2
+
+/* Offset of EC registers from ISA base address */
+#define IT87_EC_OFFSET 5
+
+/* Where are the ISA address/data registers relative to the EC base address */
+#define IT87_ADDR_REG_OFFSET 0
+#define IT87_DATA_REG_OFFSET 1
/*- The IT87 registers -*/
@@ -968,10 +982,10 @@ static int __devinit it87_probe(struct platform_device
*pdev)
};
res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (!request_region(res-start, IT87_EXTENT, DRVNAME)) {
+ if (!request_region(res-start, IT87_EC_EXTENT, DRVNAME)) {
dev_err(dev, Failed to request region 0x%lx-0x%lx\n,
(unsigned long)res-start,
- (unsigned long)(res-start + IT87_EXTENT - 1));
+ (unsigned long)(res-start + IT87_EC_EXTENT - 1));
err = -EBUSY;
goto ERROR0;
}
@@ -1124,7 +1138,7 @@ ERROR2:
platform_set_drvdata(pdev, NULL);
kfree(data);
ERROR1:
- release_region(res-start, IT87_EXTENT);
+ release_region(res-start, IT87_EC_EXTENT);
ERROR0:
return err;
}
@@ -1137,7 +1151,7 @@ static int __devexit it87_remove(struct platform_device
*pdev)
sysfs_remove_group(pdev-dev.kobj, it87_group);
sysfs_remove_group(pdev-dev.kobj, it87_group_opt);
- release_region(data-addr, IT87_EXTENT);
+ release_region(data-addr, IT87_EC_EXTENT);
platform_set_drvdata(pdev, NULL);
kfree(data);
@@ -1402,8 +1416,8 @@ static int __init it87_device_add(unsigned short address,
const struct it87_sio_data *sio_data)
{
struct resource res = {
- .start = address ,
- .end= address + IT87_EXTENT - 1,
+ .start = address + IT87_EC_OFFSET,
+ .end= address + IT87_EC_OFFSET + IT87_EC_EXTENT - 1,
.name = DRVNAME,
.flags = IORESOURCE_IO,
};
--
Mark M. Hoffman
[EMAIL PROTECTED]
--
To unsubscribe from this list
Re: [PATCH 15/59] drivers/hwmon: Add missing "space"
* Joe Perches <[EMAIL PROTECTED]> [2007-11-19 17:48:07 -0800]: > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > --- > drivers/hwmon/vt8231.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/hwmon/vt8231.c b/drivers/hwmon/vt8231.c > index 2196a84..f876617 100644 > --- a/drivers/hwmon/vt8231.c > +++ b/drivers/hwmon/vt8231.c > @@ -504,7 +504,7 @@ static ssize_t set_fan_div(struct device *dev, struct > device_attribute *attr, > case 4: data->fan_div[nr] = 2; break; > case 8: data->fan_div[nr] = 3; break; > default: > - dev_err(dev, "fan_div value %ld not supported." > + dev_err(dev, "fan_div value %ld not supported. " > "Choose one of 1, 2, 4 or 8!\n", val); > mutex_unlock(>update_lock); > return -EINVAL; > -- > 1.5.3.5.652.gf192c Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/59] drivers/hwmon: Add missing space
* Joe Perches [EMAIL PROTECTED] [2007-11-19 17:48:07 -0800]: Signed-off-by: Joe Perches [EMAIL PROTECTED] --- drivers/hwmon/vt8231.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/hwmon/vt8231.c b/drivers/hwmon/vt8231.c index 2196a84..f876617 100644 --- a/drivers/hwmon/vt8231.c +++ b/drivers/hwmon/vt8231.c @@ -504,7 +504,7 @@ static ssize_t set_fan_div(struct device *dev, struct device_attribute *attr, case 4: data-fan_div[nr] = 2; break; case 8: data-fan_div[nr] = 3; break; default: - dev_err(dev, fan_div value %ld not supported. + dev_err(dev, fan_div value %ld not supported. Choose one of 1, 2, 4 or 8!\n, val); mutex_unlock(data-update_lock); return -EINVAL; -- 1.5.3.5.652.gf192c Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH 1/1] HWMON: coretemp, suspend fix
Hi:
* Rafael J. Wysocki <[EMAIL PROTECTED]> [2007-12-01 00:51:40 +0100]:
> On Saturday, 1 of December 2007, Rafael J. Wysocki wrote:
> > On Friday, 30 of November 2007, Jiri Slaby wrote:
> > > On 11/30/2007 11:15 PM, Jean Delvare wrote:
> > > > Hi Jiri,
> > >
> [--snip--]
> > > >
> > > > Should this change go to the stable tree(s) as well?
> > >
> > > Sorry, I have no idea. Rafael?
> >
> > Well, actually, having looked once again at the patch, I think that it's
> > slightly wrong. Namely, it looks like we just should drop all of the
> > _FROZEN
> > actions from there.
> >
> > Fixed patch follows and I think it's also a candidate for -stable.
>
> Crap, I forgot to add the sign-off, so here it goes again:
>
> ---
> Subject: HWMON: coretemp, suspend fix
>
> It's not permitted to unregister a device after devices have been suspended.
> It causes deadlocks to appear on systems with coretemp hwmon loaded. To avoid
> this, we can make coretemp_cpu_callback() do nothing if the _FROZEN bit is set
> in action.
>
> Also, in other cases it's generally to late to unregister the coretemp device
> if the CPU is already dead, so it should be unregistered on CPU_DOWN_PREPARE.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> (frozen fix)
> Cc: Mark M. Hoffman <[EMAIL PROTECTED]>
> Cc: Jiri Slaby <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL PROTECTED]>
> ---
>
> drivers/hwmon/coretemp.c |5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/drivers/hwmon/coretemp.c
> ===
> --- linux-2.6.orig/drivers/hwmon/coretemp.c
> +++ linux-2.6/drivers/hwmon/coretemp.c
> @@ -337,11 +337,10 @@ static int coretemp_cpu_callback(struct
>
> switch (action) {
> case CPU_ONLINE:
> - case CPU_ONLINE_FROZEN:
> + case CPU_DOWN_FAILED:
> coretemp_device_add(cpu);
> break;
> - case CPU_DEAD:
> - case CPU_DEAD_FROZEN:
> + case CPU_DOWN_PREPARE:
> coretemp_device_remove(cpu);
> break;
> }
Sorry for the delay, it took me some time to RTF code and convince
myself that nothing can tickle this driver's sysfs files after a
CPU_DOWN_PREPARE_FROZEN. As long as I didn't misread that...
Acked-by: Mark M. Hoffman <[EMAIL PROTECTED]>
PS: while reading kernel/power/disk.c, I saw this...
335 static void power_down(void)
336 {
337 switch (hibernation_mode) {
338 case HIBERNATION_TEST:
339 case HIBERNATION_TESTPROC:
340 break;
341 case HIBERNATION_REBOOT:
342 kernel_restart(NULL);
343 break;
344 case HIBERNATION_PLATFORM:
345 hibernation_platform_enter();
346 case HIBERNATION_SHUTDOWN:
347 kernel_power_off();
348 break;
349 }
350 kernel_halt();
351 /*
352 * Valid image is on the disk, if we continue we risk serious data
353 * corruption after resume.
354 */
355 printk(KERN_CRIT "Please power me down manually\n");
356 while(1);
357 }
Shouldn't that be while(1) cpu_relax(); ?
Regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH 1/1] HWMON: coretemp, suspend fix
Hi:
* Rafael J. Wysocki [EMAIL PROTECTED] [2007-12-01 00:51:40 +0100]:
On Saturday, 1 of December 2007, Rafael J. Wysocki wrote:
On Friday, 30 of November 2007, Jiri Slaby wrote:
On 11/30/2007 11:15 PM, Jean Delvare wrote:
Hi Jiri,
[--snip--]
Should this change go to the stable tree(s) as well?
Sorry, I have no idea. Rafael?
Well, actually, having looked once again at the patch, I think that it's
slightly wrong. Namely, it looks like we just should drop all of the
_FROZEN
actions from there.
Fixed patch follows and I think it's also a candidate for -stable.
Crap, I forgot to add the sign-off, so here it goes again:
---
Subject: HWMON: coretemp, suspend fix
It's not permitted to unregister a device after devices have been suspended.
It causes deadlocks to appear on systems with coretemp hwmon loaded. To avoid
this, we can make coretemp_cpu_callback() do nothing if the _FROZEN bit is set
in action.
Also, in other cases it's generally to late to unregister the coretemp device
if the CPU is already dead, so it should be unregistered on CPU_DOWN_PREPARE.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] (frozen fix)
Cc: Mark M. Hoffman [EMAIL PROTECTED]
Cc: Jiri Slaby [EMAIL PROTECTED]
Cc: Andrew Morton [EMAIL PROTECTED]
---
drivers/hwmon/coretemp.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/hwmon/coretemp.c
===
--- linux-2.6.orig/drivers/hwmon/coretemp.c
+++ linux-2.6/drivers/hwmon/coretemp.c
@@ -337,11 +337,10 @@ static int coretemp_cpu_callback(struct
switch (action) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
+ case CPU_DOWN_FAILED:
coretemp_device_add(cpu);
break;
- case CPU_DEAD:
- case CPU_DEAD_FROZEN:
+ case CPU_DOWN_PREPARE:
coretemp_device_remove(cpu);
break;
}
Sorry for the delay, it took me some time to RTF code and convince
myself that nothing can tickle this driver's sysfs files after a
CPU_DOWN_PREPARE_FROZEN. As long as I didn't misread that...
Acked-by: Mark M. Hoffman [EMAIL PROTECTED]
PS: while reading kernel/power/disk.c, I saw this...
335 static void power_down(void)
336 {
337 switch (hibernation_mode) {
338 case HIBERNATION_TEST:
339 case HIBERNATION_TESTPROC:
340 break;
341 case HIBERNATION_REBOOT:
342 kernel_restart(NULL);
343 break;
344 case HIBERNATION_PLATFORM:
345 hibernation_platform_enter();
346 case HIBERNATION_SHUTDOWN:
347 kernel_power_off();
348 break;
349 }
350 kernel_halt();
351 /*
352 * Valid image is on the disk, if we continue we risk serious data
353 * corruption after resume.
354 */
355 printk(KERN_CRIT Please power me down manually\n);
356 while(1);
357 }
Shouldn't that be while(1) cpu_relax(); ?
Regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]
Hi all:
* Alan Stern <[EMAIL PROTECTED]> [2007-11-19 15:27:14 -0500]:
> On Mon, 19 Nov 2007, Rudolf Marek wrote:
>
> > Hello all,
> > >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> > >>> platform_device_unregister, so coretemp seems to be what I have and you
> > >>> don't.
> > >
> > > Yes.
> > >
> > > For the coretemp developers: coretemp_cpu_callback() needs to be more
> > > careful about what it does. During a system sleep transition (suspend,
> > > hibernate, resume) it isn't possible to register or unregister a
> > > device. Attempts to register will fail and attempts to unregister will
> > > block until the system sleep is over -- and for this callback that
> > > means hanging.
> >
> > Well I wrote the driver. Thanks for the clarification. If I recall
> > correctly I
> > looked how this part should be done from others drivers. Now while checking
> > what happened to the file, seems Rafael added something related.
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d
>
> That does look like it was meant for exactly this sort of situation.
>
> > > It's not clear what the best way is to fix this. Perhaps the CPU
> > > notification should be sent along with a special flag indicating that
> > > the CPU transition is part of a system sleep (although this seems
> > > racy). Perhaps the driver should notice when a system sleep begins,
> > > and defer all CPU-change handling until after the sleep is over.
> >
> > maybe it does exist? CPU_DOWN_PREPARE ?
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD
> >
> > Unfortunately I'm not very familiar with this, calling the
> > coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at
> > microcode
> > driver, seems it just hide sysfs interface from user.
AFAICT from that documentation, it would have been better to unregister
the device on CPU_DOWN_PREPARE anyway. CPU_DEAD seems to be too late -
it's already gone by then.
> I'm not sure exactly what you want to do here. But it seems like a
> waste to unregister the coretemp devices at the start of a system sleep
> and then register them back at the end.
>
> Could you simply leave the devices registered throughout the entire
> sleep? Of course, at the end you would have to check that all the CPUs
> really did come back up, and unregister the devices for the CPUs that
> are still offline.
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN? If
so, then the simplest fix would be the patch below (Jiri: feel free to
try it). Otherwise it would take a bit of refactoring to bring the sysfs
interface down/up for suspend/resume.
commit ce9c7b78c839a6304696d90083eac08baad524ce
Author: Mark M. Hoffman <[EMAIL PROTECTED]>
Date: Tue Nov 20 07:51:50 2007 -0500
hwmon: (coretemp) fix suspend/resume hang
Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]>
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 5c82ec7..afe2d31 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -338,10 +338,12 @@ static int coretemp_cpu_callback(struct notifier_block
*nfb,
switch (action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
+ case CPU_DOWN_FAILED:
+ case CPU_DOWN_FAILED_FROZEN:
coretemp_device_add(cpu);
break;
- case CPU_DEAD:
- case CPU_DEAD_FROZEN:
+ case CPU_DOWN_PREPARE:
+ case CPU_DOWN_PREPARE_FROZEN:
coretemp_device_remove(cpu);
break;
}
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]
Hi all:
* Alan Stern [EMAIL PROTECTED] [2007-11-19 15:27:14 -0500]:
On Mon, 19 Nov 2007, Rudolf Marek wrote:
Hello all,
gives coretemp_cpu_callback - coretemp_device_remove -
platform_device_unregister, so coretemp seems to be what I have and you
don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more
careful about what it does. During a system sleep transition (suspend,
hibernate, resume) it isn't possible to register or unregister a
device. Attempts to register will fail and attempts to unregister will
block until the system sleep is over -- and for this callback that
means hanging.
Well I wrote the driver. Thanks for the clarification. If I recall
correctly I
looked how this part should be done from others drivers. Now while checking
what happened to the file, seems Rafael added something related.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d
That does look like it was meant for exactly this sort of situation.
It's not clear what the best way is to fix this. Perhaps the CPU
notification should be sent along with a special flag indicating that
the CPU transition is part of a system sleep (although this seems
racy). Perhaps the driver should notice when a system sleep begins,
and defer all CPU-change handling until after the sleep is over.
maybe it does exist? CPU_DOWN_PREPARE ?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD
Unfortunately I'm not very familiar with this, calling the
coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at
microcode
driver, seems it just hide sysfs interface from user.
AFAICT from that documentation, it would have been better to unregister
the device on CPU_DOWN_PREPARE anyway. CPU_DEAD seems to be too late -
it's already gone by then.
I'm not sure exactly what you want to do here. But it seems like a
waste to unregister the coretemp devices at the start of a system sleep
and then register them back at the end.
Could you simply leave the devices registered throughout the entire
sleep? Of course, at the end you would have to check that all the CPUs
really did come back up, and unregister the devices for the CPUs that
are still offline.
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN? If
so, then the simplest fix would be the patch below (Jiri: feel free to
try it). Otherwise it would take a bit of refactoring to bring the sysfs
interface down/up for suspend/resume.
commit ce9c7b78c839a6304696d90083eac08baad524ce
Author: Mark M. Hoffman [EMAIL PROTECTED]
Date: Tue Nov 20 07:51:50 2007 -0500
hwmon: (coretemp) fix suspend/resume hang
Signed-off-by: Mark M. Hoffman [EMAIL PROTECTED]
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 5c82ec7..afe2d31 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -338,10 +338,12 @@ static int coretemp_cpu_callback(struct notifier_block
*nfb,
switch (action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
+ case CPU_DOWN_FAILED:
+ case CPU_DOWN_FAILED_FROZEN:
coretemp_device_add(cpu);
break;
- case CPU_DEAD:
- case CPU_DEAD_FROZEN:
+ case CPU_DOWN_PREPARE:
+ case CPU_DOWN_PREPARE_FROZEN:
coretemp_device_remove(cpu);
break;
}
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [GIT PATCH] hwmon updates against v2.6.24-rc2
Jean: > On Tue, 13 Nov 2007 08:12:10 -0500, Mark M. Hoffman wrote: > > Hi Linus: > > > > Please pull from: > > git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release > > > > You'll get one new driver, a few cleanups, and a few bugfixes. This > > takes care of all known regressions; hopefully it's the last you hear > > from me before 2.6.24-final. > > > > Note: the f75375s/n2100 patches especially are critical to avoid > > possible overheating problems on that platform (yay crappy BIOS). > > > > All of these patches have spent considerable time in -mm. * Jean Delvare <[EMAIL PROTECTED]> [2007-11-13 22:00:30 +0100]: > Let me have a doubt, considering that the last public -mm kernel was > released over a month ago (October 12th), which is before your previous > pull request (October 14th). I don't think that any of these patches > has been in even one public -mm tree, so in practice they probably > didn't receive any public testing at all. Well, zero is a "considerable" number. ;) Seriously though, my bad. In my (weak) defense, I will point out that all but a couple of these patches were *available* for -mm on my testing branch for at least two weeks; Oct 28 was the most recent addition. > Now let's hope that nothing breaks. I admit: post-rc2 was later than it should have been for some of this. But there was no rocket science in any of these. I think we'll be OK. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates against v2.6.24-rc2
Hi Linus:
Please pull from:
git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release
You'll get one new driver, a few cleanups, and a few bugfixes. This
takes care of all known regressions; hopefully it's the last you hear
from me before 2.6.24-final.
Note: the f75375s/n2100 patches especially are critical to avoid
possible overheating problems on that platform (yay crappy BIOS).
All of these patches have spent considerable time in -mm.
Thanks & regards,
Documentation/hwmon/sysfs-interface | 31 ++
arch/arm/mach-iop32x/n2100.c| 11
drivers/hwmon/Kconfig | 10
drivers/hwmon/Makefile |1
drivers/hwmon/abituguru3.c | 56 +++
drivers/hwmon/applesmc.c| 107 ++
drivers/hwmon/f75375s.c | 170 ---
drivers/hwmon/i5k_amb.c | 552
drivers/hwmon/ibmpex.c | 48 +--
drivers/hwmon/lm70.c| 11
drivers/hwmon/sis5595.c | 59 ++-
drivers/hwmon/w83627hf.c| 155 +++---
drivers/hwmon/w83781d.c |3
include/linux/f75375s.h | 21 +
include/linux/pci_ids.h |3
15 files changed, 1049 insertions(+), 189 deletions(-)
Adrian Bunk (1):
hwmon: (ibmpex.c) fix NULL dereference
Darrick J. Wong (4):
hwmon: Add power meter spec to Documentation/hwmon/sysfs-interface
hwmon: (i5k_amb) New memory temperature sensor driver
hwmon: (ibmpex) Change printk to dev_{info,err} macros
hwmon: (i5k_amb) Convert macros to C functions
Hans de Goede (2):
hwmon: (abituguru3) Add support for 2 new motherboards
hwmon: (abituguru3) Identify ABit IP35 Pro as such
Ivo Manca (2):
hwmon: (sis5595) Add individual alarm files
hwmon: (sis5595) Split sis5595_attributes_opt
Jean Delvare (1):
hwmon: (w83781d) Add missing curly braces
Jim Cromie (2):
hwmon: (w83627hf) hoist nr-1 offset out of show-store-temp-X
hwmon: (w83627hf) push nr+1 offset into *_REG_FAN macros and simplify
Matthias Kaehlcke (1):
hwmon: (lm70) Convert semaphore to mutex
René Rebe (1):
hwmon: (applesmc) Add support for Mac Pro 2 x Quad-Core
Riku Voipio (5):
hwmon: (f75375s) fix pwm mode setting
hwmon: (f75375s) Add new style bindings
hwmon: (f75375s) Allow setting up fans with platform_data
hwmon: (f75375s) On n2100 systems, set fans to full speed on boot
hwmon: (f75375s) pwmX_mode sysfs files writable for f75375 variant
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates against v2.6.24-rc2
Hi Linus:
Please pull from:
git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release
You'll get one new driver, a few cleanups, and a few bugfixes. This
takes care of all known regressions; hopefully it's the last you hear
from me before 2.6.24-final.
Note: the f75375s/n2100 patches especially are critical to avoid
possible overheating problems on that platform (yay crappy BIOS).
All of these patches have spent considerable time in -mm.
Thanks regards,
Documentation/hwmon/sysfs-interface | 31 ++
arch/arm/mach-iop32x/n2100.c| 11
drivers/hwmon/Kconfig | 10
drivers/hwmon/Makefile |1
drivers/hwmon/abituguru3.c | 56 +++
drivers/hwmon/applesmc.c| 107 ++
drivers/hwmon/f75375s.c | 170 ---
drivers/hwmon/i5k_amb.c | 552
drivers/hwmon/ibmpex.c | 48 +--
drivers/hwmon/lm70.c| 11
drivers/hwmon/sis5595.c | 59 ++-
drivers/hwmon/w83627hf.c| 155 +++---
drivers/hwmon/w83781d.c |3
include/linux/f75375s.h | 21 +
include/linux/pci_ids.h |3
15 files changed, 1049 insertions(+), 189 deletions(-)
Adrian Bunk (1):
hwmon: (ibmpex.c) fix NULL dereference
Darrick J. Wong (4):
hwmon: Add power meter spec to Documentation/hwmon/sysfs-interface
hwmon: (i5k_amb) New memory temperature sensor driver
hwmon: (ibmpex) Change printk to dev_{info,err} macros
hwmon: (i5k_amb) Convert macros to C functions
Hans de Goede (2):
hwmon: (abituguru3) Add support for 2 new motherboards
hwmon: (abituguru3) Identify ABit IP35 Pro as such
Ivo Manca (2):
hwmon: (sis5595) Add individual alarm files
hwmon: (sis5595) Split sis5595_attributes_opt
Jean Delvare (1):
hwmon: (w83781d) Add missing curly braces
Jim Cromie (2):
hwmon: (w83627hf) hoist nr-1 offset out of show-store-temp-X
hwmon: (w83627hf) push nr+1 offset into *_REG_FAN macros and simplify
Matthias Kaehlcke (1):
hwmon: (lm70) Convert semaphore to mutex
René Rebe (1):
hwmon: (applesmc) Add support for Mac Pro 2 x Quad-Core
Riku Voipio (5):
hwmon: (f75375s) fix pwm mode setting
hwmon: (f75375s) Add new style bindings
hwmon: (f75375s) Allow setting up fans with platform_data
hwmon: (f75375s) On n2100 systems, set fans to full speed on boot
hwmon: (f75375s) pwmX_mode sysfs files writable for f75375 variant
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [GIT PATCH] hwmon updates against v2.6.24-rc2
Jean: On Tue, 13 Nov 2007 08:12:10 -0500, Mark M. Hoffman wrote: Hi Linus: Please pull from: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release You'll get one new driver, a few cleanups, and a few bugfixes. This takes care of all known regressions; hopefully it's the last you hear from me before 2.6.24-final. Note: the f75375s/n2100 patches especially are critical to avoid possible overheating problems on that platform (yay crappy BIOS). All of these patches have spent considerable time in -mm. * Jean Delvare [EMAIL PROTECTED] [2007-11-13 22:00:30 +0100]: Let me have a doubt, considering that the last public -mm kernel was released over a month ago (October 12th), which is before your previous pull request (October 14th). I don't think that any of these patches has been in even one public -mm tree, so in practice they probably didn't receive any public testing at all. Well, zero is a considerable number. ;) Seriously though, my bad. In my (weak) defense, I will point out that all but a couple of these patches were *available* for -mm on my testing branch for at least two weeks; Oct 28 was the most recent addition. Now let's hope that nothing breaks. I admit: post-rc2 was later than it should have been for some of this. But there was no rocket science in any of these. I think we'll be OK. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sysfs: add filter function to groups
Hi Kay:
* Kay Sievers <[EMAIL PROTECTED]> [2007-10-31 03:01:56 +0100]:
> On Oct 31, 2007 1:40 AM, Mark M. Hoffman <[EMAIL PROTECTED]> wrote:
> > * James Bottomley <[EMAIL PROTECTED]> [2007-10-30 13:25:43 -0500]:
> > > On Mon, 2007-10-29 at 18:58 +0100, Stefan Richter wrote:
> > > > James Bottomley wrote:
> > > > >> > struct attribute_group {
> > > > >> >const char *name;
> > > > >> > + int (*filter_show)(struct kobject *,
> > > > >> > int);
> > > >
> > > > > Actually, it returns a true/false value indicating whether the given
> > > > > attribute should be displayed.
> > > >
> > > > How about this:
> > > >
> > > > int (*is_visible)(...);
> > >
> > > OK, so is this latest revision acceptable to everyone?
> >
> > I've just been hacking around in this area a bit, for a completely different
> > reason: there are literally 1000's of attributes in drivers/hwmon/*.c that
> > really want to be const, but which cannot be due to the current API. I was
> > about to propose some patches that move in a different direction...
>
> That isn't related to "dynamic attributes", right?
Right, it's not. That phrase was coined by the previous maintainer, Jean, to
describe a specific mechanism which makes for smaller code in drivers/hwmon.
> > IMHO the fundamental problem is struct attribute_group itself. This
> > structure
> > is nothing but a convenience for packaging the arguments to
> > sysfs_create_group
> > and sysfs_remove_group.
>
> That "problem" is actually a good thing. If you look at the change
> rate of the internal kernel API, it saves us so much trouble. Like in
> this case, James can just add a callback without caring about any
> (almost :)) of the current users.
Given my patch, he could also just add sysfs_create_attr_group_filtered(...).
This would affect current users even less than what you suggest because it
wouldn't bloat the struct that they all use.
> > Those functions should take the contents of that
> > struct as direct arguments.
>
> I think we should move in the opposite direction. You are right, it
> isn't neccessarily pretty, but having encapsulations like this saves
> us a lot of trouble while interacting with so many other people and
> extending API's all the time. It's a trade, and it's a good one, if
> you need to maintain code that has so many callers, and so many
> architectures, you can't even check that you don't break them.
Again, I don't see how it is better to bloat a struct with many users instead
of just adding a function for the few that need the extra functionality. My
patch also requires 0 change for everyone else.
> > I haven't finished the patch series to implement
> > this, but since I noticed your patch I thought I'd better speak up now.
> > Here's
> > the first... the idea is to eventually deprecate
> > sysfs_[create|remove]_group()
> > altogether.
>
> Again, I don't think, that we want to get rid of the struct container
> housing all the parameters and beeing open for future extensions
> without changing all the callers.
BTW: I hope you're not resisting based on the prospect of deprecating those
two functions. I don't really have time to push such a huge patch either.
It wouldn't hurt just to keep them.
> > The current declaration of struct attribute_group prevents long lists of
> > attributes from being marked const. Ideally, the second argument to the
> > sysfs_create_group() and sysfs_remove_group() functions would be marked
> > "deep"
> > const, but C has no such construct. This patch provides a parallel set
> > of
> > functions with the desired decoration.
>
> What do we get out of this constification compared to the current code?
Conceptual correctness, for one, but also it allows hwmon drivers to move as
much as 1K each out of the data section and into text. This is useful for the
embedded XIP scenario.
And please don't underestimate conceptual correctness: at least hwmon (and
probably many other users) really *rely* on the core not to modify the contents
of struct attribute_group (specifically, the data to which its members point).
Without the proper const qualifiers, this is not externally guaranteed.
Regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sysfs: add filter function to groups
Hi Kay:
* Kay Sievers [EMAIL PROTECTED] [2007-10-31 03:01:56 +0100]:
On Oct 31, 2007 1:40 AM, Mark M. Hoffman [EMAIL PROTECTED] wrote:
* James Bottomley [EMAIL PROTECTED] [2007-10-30 13:25:43 -0500]:
On Mon, 2007-10-29 at 18:58 +0100, Stefan Richter wrote:
James Bottomley wrote:
struct attribute_group {
const char *name;
+ int (*filter_show)(struct kobject *,
int);
Actually, it returns a true/false value indicating whether the given
attribute should be displayed.
How about this:
int (*is_visible)(...);
OK, so is this latest revision acceptable to everyone?
I've just been hacking around in this area a bit, for a completely different
reason: there are literally 1000's of attributes in drivers/hwmon/*.c that
really want to be const, but which cannot be due to the current API. I was
about to propose some patches that move in a different direction...
That isn't related to dynamic attributes, right?
Right, it's not. That phrase was coined by the previous maintainer, Jean, to
describe a specific mechanism which makes for smaller code in drivers/hwmon.
IMHO the fundamental problem is struct attribute_group itself. This
structure
is nothing but a convenience for packaging the arguments to
sysfs_create_group
and sysfs_remove_group.
That problem is actually a good thing. If you look at the change
rate of the internal kernel API, it saves us so much trouble. Like in
this case, James can just add a callback without caring about any
(almost :)) of the current users.
Given my patch, he could also just add sysfs_create_attr_group_filtered(...).
This would affect current users even less than what you suggest because it
wouldn't bloat the struct that they all use.
Those functions should take the contents of that
struct as direct arguments.
I think we should move in the opposite direction. You are right, it
isn't neccessarily pretty, but having encapsulations like this saves
us a lot of trouble while interacting with so many other people and
extending API's all the time. It's a trade, and it's a good one, if
you need to maintain code that has so many callers, and so many
architectures, you can't even check that you don't break them.
Again, I don't see how it is better to bloat a struct with many users instead
of just adding a function for the few that need the extra functionality. My
patch also requires 0 change for everyone else.
I haven't finished the patch series to implement
this, but since I noticed your patch I thought I'd better speak up now.
Here's
the first... the idea is to eventually deprecate
sysfs_[create|remove]_group()
altogether.
Again, I don't think, that we want to get rid of the struct container
housing all the parameters and beeing open for future extensions
without changing all the callers.
BTW: I hope you're not resisting based on the prospect of deprecating those
two functions. I don't really have time to push such a huge patch either.
It wouldn't hurt just to keep them.
The current declaration of struct attribute_group prevents long lists of
attributes from being marked const. Ideally, the second argument to the
sysfs_create_group() and sysfs_remove_group() functions would be marked
deep
const, but C has no such construct. This patch provides a parallel set
of
functions with the desired decoration.
What do we get out of this constification compared to the current code?
Conceptual correctness, for one, but also it allows hwmon drivers to move as
much as 1K each out of the data section and into text. This is useful for the
embedded XIP scenario.
And please don't underestimate conceptual correctness: at least hwmon (and
probably many other users) really *rely* on the core not to modify the contents
of struct attribute_group (specifically, the data to which its members point).
Without the proper const qualifiers, this is not externally guaranteed.
Regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sysfs: add filter function to groups
Hi James:
* James Bottomley <[EMAIL PROTECTED]> [2007-10-30 13:25:43 -0500]:
> On Mon, 2007-10-29 at 18:58 +0100, Stefan Richter wrote:
> > James Bottomley wrote:
> > >> > struct attribute_group {
> > >> >const char *name;
> > >> > + int (*filter_show)(struct kobject *, int);
> >
> > > Actually, it returns a true/false value indicating whether the given
> > > attribute should be displayed.
> >
> > How about this:
> >
> > int (*is_visible)(...);
>
> OK, so is this latest revision acceptable to everyone?
I've just been hacking around in this area a bit, for a completely different
reason: there are literally 1000's of attributes in drivers/hwmon/*.c that
really want to be const, but which cannot be due to the current API. I was
about to propose some patches that move in a different direction...
> Index: BUILD-2.6/fs/sysfs/group.c
> ===
> --- BUILD-2.6.orig/fs/sysfs/group.c 2007-10-28 17:27:04.0 -0500
> +++ BUILD-2.6/fs/sysfs/group.c2007-10-30 12:35:47.0 -0500
> @@ -16,25 +16,31 @@
> #include "sysfs.h"
>
>
> -static void remove_files(struct sysfs_dirent *dir_sd,
> +static void remove_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
>const struct attribute_group *grp)
> {
> struct attribute *const* attr;
> + int i;
>
> - for (attr = grp->attrs; *attr; attr++)
> - sysfs_hash_and_remove(dir_sd, (*attr)->name);
> + for (i = 0, attr = grp->attrs; *attr; i++, attr++)
> + if (grp->is_visible &&
> + grp->is_visible(kobj, *attr, i))
> + sysfs_hash_and_remove(dir_sd, (*attr)->name);
> }
>
> -static int create_files(struct sysfs_dirent *dir_sd,
> +static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
> const struct attribute_group *grp)
> {
> struct attribute *const* attr;
> - int error = 0;
> + int error = 0, i;
>
> - for (attr = grp->attrs; *attr && !error; attr++)
> - error = sysfs_add_file(dir_sd, *attr, SYSFS_KOBJ_ATTR);
> + for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++)
> + if (grp->is_visible &&
> + grp->is_visible(kobj, *attr, i))
> + error |=
> + sysfs_add_file(dir_sd, *attr, SYSFS_KOBJ_ATTR);
> if (error)
> - remove_files(dir_sd, grp);
> + remove_files(dir_sd, kobj, grp);
> return error;
> }
>
> @@ -54,7 +60,7 @@ int sysfs_create_group(struct kobject *
> } else
> sd = kobj->sd;
> sysfs_get(sd);
> - error = create_files(sd, grp);
> + error = create_files(sd, kobj, grp);
> if (error) {
> if (grp->name)
> sysfs_remove_subdir(sd);
> @@ -75,7 +81,7 @@ void sysfs_remove_group(struct kobject *
> } else
> sd = sysfs_get(dir_sd);
>
> - remove_files(sd, grp);
> + remove_files(sd, kobj, grp);
> if (grp->name)
> sysfs_remove_subdir(sd);
>
> Index: BUILD-2.6/include/linux/sysfs.h
> ===
> --- BUILD-2.6.orig/include/linux/sysfs.h 2007-10-28 17:20:06.0
> -0500
> +++ BUILD-2.6/include/linux/sysfs.h 2007-10-30 13:24:06.0 -0500
> @@ -32,6 +32,8 @@ struct attribute {
>
> struct attribute_group {
> const char *name;
> + int (*is_visible)(struct kobject *,
> + struct attribute *, int);
> struct attribute**attrs;
> };
IMHO the fundamental problem is struct attribute_group itself. This structure
is nothing but a convenience for packaging the arguments to sysfs_create_group
and sysfs_remove_group. Those functions should take the contents of that
struct as direct arguments. I haven't finished the patch series to implement
this, but since I noticed your patch I thought I'd better speak up now. Here's
the first... the idea is to eventually deprecate sysfs_[create|remove]_group()
altogether.
commit 5b5bc08ae31519b7012d7fc23ff73e0c6474de53
Author: Mark M. Hoffman <[EMAIL PROTECTED]>
Date: Sun Oct 21 11:49:57 2007 -0400
sysfs: allow attribute (group) lists to be const
The current declaration of struct attribute_group prevents long lists of
attributes from being marked const. Ideally, the second argument to the
Re: [PATCH] sysfs: add filter function to groups
Hi James:
* James Bottomley [EMAIL PROTECTED] [2007-10-30 13:25:43 -0500]:
On Mon, 2007-10-29 at 18:58 +0100, Stefan Richter wrote:
James Bottomley wrote:
struct attribute_group {
const char *name;
+ int (*filter_show)(struct kobject *, int);
Actually, it returns a true/false value indicating whether the given
attribute should be displayed.
How about this:
int (*is_visible)(...);
OK, so is this latest revision acceptable to everyone?
I've just been hacking around in this area a bit, for a completely different
reason: there are literally 1000's of attributes in drivers/hwmon/*.c that
really want to be const, but which cannot be due to the current API. I was
about to propose some patches that move in a different direction...
Index: BUILD-2.6/fs/sysfs/group.c
===
--- BUILD-2.6.orig/fs/sysfs/group.c 2007-10-28 17:27:04.0 -0500
+++ BUILD-2.6/fs/sysfs/group.c2007-10-30 12:35:47.0 -0500
@@ -16,25 +16,31 @@
#include sysfs.h
-static void remove_files(struct sysfs_dirent *dir_sd,
+static void remove_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
const struct attribute_group *grp)
{
struct attribute *const* attr;
+ int i;
- for (attr = grp-attrs; *attr; attr++)
- sysfs_hash_and_remove(dir_sd, (*attr)-name);
+ for (i = 0, attr = grp-attrs; *attr; i++, attr++)
+ if (grp-is_visible
+ grp-is_visible(kobj, *attr, i))
+ sysfs_hash_and_remove(dir_sd, (*attr)-name);
}
-static int create_files(struct sysfs_dirent *dir_sd,
+static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
const struct attribute_group *grp)
{
struct attribute *const* attr;
- int error = 0;
+ int error = 0, i;
- for (attr = grp-attrs; *attr !error; attr++)
- error = sysfs_add_file(dir_sd, *attr, SYSFS_KOBJ_ATTR);
+ for (i = 0, attr = grp-attrs; *attr !error; i++, attr++)
+ if (grp-is_visible
+ grp-is_visible(kobj, *attr, i))
+ error |=
+ sysfs_add_file(dir_sd, *attr, SYSFS_KOBJ_ATTR);
if (error)
- remove_files(dir_sd, grp);
+ remove_files(dir_sd, kobj, grp);
return error;
}
@@ -54,7 +60,7 @@ int sysfs_create_group(struct kobject *
} else
sd = kobj-sd;
sysfs_get(sd);
- error = create_files(sd, grp);
+ error = create_files(sd, kobj, grp);
if (error) {
if (grp-name)
sysfs_remove_subdir(sd);
@@ -75,7 +81,7 @@ void sysfs_remove_group(struct kobject *
} else
sd = sysfs_get(dir_sd);
- remove_files(sd, grp);
+ remove_files(sd, kobj, grp);
if (grp-name)
sysfs_remove_subdir(sd);
Index: BUILD-2.6/include/linux/sysfs.h
===
--- BUILD-2.6.orig/include/linux/sysfs.h 2007-10-28 17:20:06.0
-0500
+++ BUILD-2.6/include/linux/sysfs.h 2007-10-30 13:24:06.0 -0500
@@ -32,6 +32,8 @@ struct attribute {
struct attribute_group {
const char *name;
+ int (*is_visible)(struct kobject *,
+ struct attribute *, int);
struct attribute**attrs;
};
IMHO the fundamental problem is struct attribute_group itself. This structure
is nothing but a convenience for packaging the arguments to sysfs_create_group
and sysfs_remove_group. Those functions should take the contents of that
struct as direct arguments. I haven't finished the patch series to implement
this, but since I noticed your patch I thought I'd better speak up now. Here's
the first... the idea is to eventually deprecate sysfs_[create|remove]_group()
altogether.
commit 5b5bc08ae31519b7012d7fc23ff73e0c6474de53
Author: Mark M. Hoffman [EMAIL PROTECTED]
Date: Sun Oct 21 11:49:57 2007 -0400
sysfs: allow attribute (group) lists to be const
The current declaration of struct attribute_group prevents long lists of
attributes from being marked const. Ideally, the second argument to the
sysfs_create_group() and sysfs_remove_group() functions would be marked
deep
const, but C has no such construct. This patch provides a parallel set of
functions with the desired decoration.
Signed-off-by: Mark M. Hoffman [EMAIL PROTECTED]
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index d197237..b217a8e 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -17,71 +17,84 @@
static void remove_files(struct sysfs_dirent *dir_sd,
-const struct attribute_group *grp)
+const struct
Re: [PATCH] i5k_amb: Convert macros to C functions
Hi: * Darrick J. Wong <[EMAIL PROTECTED]> [2007-10-26 11:55:11 -0700]: > akpm objected to some of the macros, so convert them into functions. > > Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]> > --- > > drivers/hwmon/i5k_amb.c | 65 > +++ > 1 files changed, 43 insertions(+), 22 deletions(-) Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] hwmon/f75375s.c: buggy if()
Hi: * Riku Voipio <[EMAIL PROTECTED]> [2007-10-26 14:14:23 +0300]: > On Fri, Oct 26, 2007 at 10:36:47AM +0200, Jean Delvare wrote: > > Patch looks correct, however it doesn't apply on top of Mark's tree. I > > was able to get it to apply by reverting "(f75375s) fix pwm mode > > setting" first, but then the build fails. Presumably the other f75375s > > patches interact badly. Can you please respin this patch on top of > > Mark's tree (i.e. on top the the 4 other f75375s patches you sent since > > the -rc1 merge)? Thanks. > > The surrounding code had wandered to another function, so it's suprising > it applied at all. Here's respin. > > -- > "rm -rf" only sounds scary if you don't have backups > >From 4de69e3ab5b5833cddb503f0dcb2a3ccc2d5b328 Mon Sep 17 00:00:00 2001 > From: Riku Voipio <[EMAIL PROTECTED]> > Date: Fri, 26 Oct 2007 13:53:50 +0300 > Subject: [PATCH] hwmon (f75375s) fix buggy if() properly > > Fix value check in set_pwm_mode(). Instead of checking for > chip variant there, make pwmX_mode sysfs nodes only writable > on f75375 variant. > > Signed-off-by: Riku Voipio <[EMAIL PROTECTED]> > --- > drivers/hwmon/f75375s.c | 19 ++++--- > 1 files changed, 16 insertions(+), 3 deletions(-) > Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] hwmon/f75375s.c: buggy if()
Hi: * Riku Voipio [EMAIL PROTECTED] [2007-10-26 14:14:23 +0300]: On Fri, Oct 26, 2007 at 10:36:47AM +0200, Jean Delvare wrote: Patch looks correct, however it doesn't apply on top of Mark's tree. I was able to get it to apply by reverting (f75375s) fix pwm mode setting first, but then the build fails. Presumably the other f75375s patches interact badly. Can you please respin this patch on top of Mark's tree (i.e. on top the the 4 other f75375s patches you sent since the -rc1 merge)? Thanks. The surrounding code had wandered to another function, so it's suprising it applied at all. Here's respin. -- rm -rf only sounds scary if you don't have backups From 4de69e3ab5b5833cddb503f0dcb2a3ccc2d5b328 Mon Sep 17 00:00:00 2001 From: Riku Voipio [EMAIL PROTECTED] Date: Fri, 26 Oct 2007 13:53:50 +0300 Subject: [PATCH] hwmon (f75375s) fix buggy if() properly Fix value check in set_pwm_mode(). Instead of checking for chip variant there, make pwmX_mode sysfs nodes only writable on f75375 variant. Signed-off-by: Riku Voipio [EMAIL PROTECTED] --- drivers/hwmon/f75375s.c | 19 --- 1 files changed, 16 insertions(+), 3 deletions(-) Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i5k_amb: Convert macros to C functions
Hi: * Darrick J. Wong [EMAIL PROTECTED] [2007-10-26 11:55:11 -0700]: akpm objected to some of the macros, so convert them into functions. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] --- drivers/hwmon/i5k_amb.c | 65 +++ 1 files changed, 43 insertions(+), 22 deletions(-) Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Detect hwmon and i2c bus drivers interfering with ACPI Operation Region resources
Hi Thomas: I recently told someone in private that ACPI vs. hwmon conflicts are the biggest open problems for the hwmon subsystem. Thank you (and Jean) for doing this. * Thomas Renninger <[EMAIL PROTECTED]> [2007-10-24 16:31:59 +0200]: > Hi, > > it seems Len's test tree and Linus tree diverged a bit, at least with > this patch set things do not apply cleanly. > > Therefore I post these for discussion whether and in which kernel tree > they should end up before doing work for nothing. > If they are still a candidate for 2.6.24 (rather unintrusive), pls tell > me whether and when I should base them against Len's test/release branch > or whatever other tree. > If not, it would be great if they can be included into the -mm tree and > I can rebase them against this one. Andrew has already picked this series; I vote for extended time in -mm. On the hwmon side, there is almost guaranteed to be fallout from this that may take time to resolve. > (...) > A boot parameter acpi_enforce_resources=strict/lax/no is provided, which > is default set to lax: > - strict: let conflicting drivers fail to load with an error message > - lax:let conflicting driver work normal with a warning message > - no: no functional change at all > Depending on the feedback and the kind of interferences we see, this > should be set to strict at later time. As long as it's in -mm, you may as well default to =strict right away. This will force people to report. Open the floodgates; I hope I don't drown. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Detect hwmon and i2c bus drivers interfering with ACPI Operation Region resources
Hi Thomas: I recently told someone in private that ACPI vs. hwmon conflicts are the biggest open problems for the hwmon subsystem. Thank you (and Jean) for doing this. * Thomas Renninger [EMAIL PROTECTED] [2007-10-24 16:31:59 +0200]: Hi, it seems Len's test tree and Linus tree diverged a bit, at least with this patch set things do not apply cleanly. Therefore I post these for discussion whether and in which kernel tree they should end up before doing work for nothing. If they are still a candidate for 2.6.24 (rather unintrusive), pls tell me whether and when I should base them against Len's test/release branch or whatever other tree. If not, it would be great if they can be included into the -mm tree and I can rebase them against this one. Andrew has already picked this series; I vote for extended time in -mm. On the hwmon side, there is almost guaranteed to be fallout from this that may take time to resolve. (...) A boot parameter acpi_enforce_resources=strict/lax/no is provided, which is default set to lax: - strict: let conflicting drivers fail to load with an error message - lax:let conflicting driver work normal with a warning message - no: no functional change at all Depending on the feedback and the kind of interferences we see, this should be set to strict at later time. As long as it's in -mm, you may as well default to =strict right away. This will force people to report. Open the floodgates; I hope I don't drown. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] hwmon/f75375s.c: buggy if()
Hi Riku: * Riku Voipio <[EMAIL PROTECTED]> [2007-10-24 14:50:34 +0300]: > On Fri, Oct 19, 2007 at 02:37:54PM +0200, Jean Delvare wrote: > > Riku, can you please submit a patch fixing this? The attribute should > > be declared read-only, and then you can use sysfs_chmod_file() to > > change it to read-write where supported. > > Thanks, this was good suggestion. Patch attached. No patch? -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hardware Monitor LM70: Convert semaphore to mutex
Hi: * Matthias Kaehlcke <[EMAIL PROTECTED]> [2007-10-24 14:59:09 +0200]: > Hardware Monitor LM70: Convert the semaphore lm70->sem to the mutex > API > > Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]> Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hardware Monitor LM70: Convert semaphore to mutex
Hi: * Matthias Kaehlcke [EMAIL PROTECTED] [2007-10-24 14:59:09 +0200]: Hardware Monitor LM70: Convert the semaphore lm70-sem to the mutex API Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED] Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] hwmon/f75375s.c: buggy if()
Hi Riku: * Riku Voipio [EMAIL PROTECTED] [2007-10-24 14:50:34 +0300]: On Fri, Oct 19, 2007 at 02:37:54PM +0200, Jean Delvare wrote: Riku, can you please submit a patch fixing this? The attribute should be declared read-only, and then you can use sysfs_chmod_file() to change it to read-write where supported. Thanks, this was good suggestion. Patch attached. No patch? -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ibmpex: Change printk to dev_{info,err} macros
Hi: * Jean Delvare <[EMAIL PROTECTED]> [2007-10-20 23:30:52 +0200]: > On Fri, 19 Oct 2007 16:35:07 -0700, Darrick J. Wong wrote: > > Ok, I'll change the message to be a bit more accurate. > > --- > > Clean up printk use in ibmpex. > > > > Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]> > > --- > > Acked-by: Jean Delvare <[EMAIL PROTECTED]> Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] i5k_amb: New memory temperature sensor driver
Hi Darrick: * Darrick J. Wong <[EMAIL PROTECTED]> [2007-10-18 13:22:43 -0700]: > New driver to read FB-DIMM temperature sensors on systems with the > Intel 5000 series chipsets. > > Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]> > --- > > drivers/hwmon/Kconfig | 10 + > drivers/hwmon/Makefile |1 > drivers/hwmon/i5k_amb.c | 531 > +++ > include/linux/pci_ids.h |3 > 4 files changed, 545 insertions(+), 0 deletions(-) Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] i5k_amb: New memory temperature sensor driver
Hi Darrick: * Darrick J. Wong [EMAIL PROTECTED] [2007-10-18 13:22:43 -0700]: New driver to read FB-DIMM temperature sensors on systems with the Intel 5000 series chipsets. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] --- drivers/hwmon/Kconfig | 10 + drivers/hwmon/Makefile |1 drivers/hwmon/i5k_amb.c | 531 +++ include/linux/pci_ids.h |3 4 files changed, 545 insertions(+), 0 deletions(-) Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ibmpex: Change printk to dev_{info,err} macros
Hi: * Jean Delvare [EMAIL PROTECTED] [2007-10-20 23:30:52 +0200]: On Fri, 19 Oct 2007 16:35:07 -0700, Darrick J. Wong wrote: Ok, I'll change the message to be a bit more accurate. --- Clean up printk use in ibmpex. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] --- Acked-by: Jean Delvare [EMAIL PROTECTED] Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] hwmon/ibmpex.c: fix NULL dereference
Hi:
* Adrian Bunk <[EMAIL PROTECTED]> [2007-10-17 21:29:02 +0200]:
> Don't dereference "data" when we know for sure it's NULL.
>
> Spotted by the Coverity checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> 66bec2ef5c6d55fc30ef6ac5bb97fdfcfaf394f2
> diff --git a/drivers/hwmon/ibmpex.c b/drivers/hwmon/ibmpex.c
> index c462824..e14ce3d 100644
> --- a/drivers/hwmon/ibmpex.c
> +++ b/drivers/hwmon/ibmpex.c
> @@ -457,7 +457,7 @@ static void ibmpex_register_bmc(int iface, struct device
> *dev)
> data = kzalloc(sizeof(*data), GFP_KERNEL);
> if (!data) {
> printk(KERN_ERR DRVNAME ": Insufficient memory for BMC "
> -"interface %d.\n", data->interface);
> +"interface.\n");
> return;
> }
>
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: hwmon/f75375s.c: buggy if()
Hi:
* Riku Voipio <[EMAIL PROTECTED]> [2007-10-17 23:45:08 +0300]:
> > <-- snip -->
> >
> > ...
> > static ssize_t set_pwm_mode(struct device *dev, struct device_attribute
> > *attr,
> > const char *buf, size_t count)
> > {
> > ...
> > if (val != 0 || val != 1 || data->kind == f75373)
> > return -EINVAL;
> > ...
> >
> > <-- snip -->
>
> > I'm not sure what exactly was intended, but it was for sure not intended
> > to always return -EINVAL...
>
> Aiee. val should be 1 or 0, and kind must not be f75373.
>
> Signed-off-by: Riku Voipio <[EMAIL PROTECTED]>
> ---
> drivers/hwmon/f75375s.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/hwmon/f75375s.c b/drivers/hwmon/f75375s.c
> index f1df57a..885bfe9 100644
> --- a/drivers/hwmon/f75375s.c
> +++ b/drivers/hwmon/f75375s.c
> @@ -344,7 +344,7 @@ static ssize_t set_pwm_mode(struct device *dev, struct
> device_attribute *attr,
> int val = simple_strtoul(buf, NULL, 10);
> u8 conf = 0;
>
> - if (val != 0 || val != 1 || data->kind == f75373)
> + if (!(val == 0 || val == 1 ) || data->kind == f75373)
> return -EINVAL;
>
> mutex_lock(>update_lock);
> --
> 1.5.3.1
That patch doesn't apply here, so I applied this:
commit 805763cd743f2aed41dc61a55569fa43cf1f240c
Author: Riku Voipio <[EMAIL PROTECTED]>
Date: Thu Oct 18 09:29:53 2007 -0400
hwmon: (f75375s) fix pwm mode setting
Spotted by the Coverity checker. (Thanks Adrian Bunk)
Signed-off-by: Riku Voipio <[EMAIL PROTECTED]>
Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]>
diff --git a/drivers/hwmon/f75375s.c b/drivers/hwmon/f75375s.c
index 13a0413..59a3470 100644
--- a/drivers/hwmon/f75375s.c
+++ b/drivers/hwmon/f75375s.c
@@ -323,7 +323,7 @@ static ssize_t set_pwm_mode(struct device *dev, struct
device_attribute *attr,
int val = simple_strtoul(buf, NULL, 10);
u8 conf = 0;
- if (val != 0 || val != 1 || data->kind == f75373)
+ if (!(val == 0 || val == 1) || data->kind == f75373)
return -EINVAL;
mutex_lock(>update_lock);
Thanks & regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] i5k_amb: New memory temperature sensor driver
dev_id = PCI_DEVICE_ID_INTEL_5000_FBD0;
> + break;
> + case 1:
> + dev_id = PCI_DEVICE_ID_INTEL_5000_FBD1;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
Awkward: see suggested patch at the bottom of this message.
> + /* Copy the DIMM presence map for these two channels */
> + pcidev = pci_get_device(PCI_VENDOR_ID_INTEL, dev_id, NULL);
> + if (!pcidev)
> + return -ENODEV;
> +
> + if (pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, ))
> + goto out;
> + data->amb_present[which * 2] = val16;
> +
> + if (pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, ))
> + goto out;
> + data->amb_present[which * 2 + 1] = val16;
> +
> + res = 0;
> +
> +out:
> + pci_dev_put(pcidev);
> + return res;
> +}
> +
> +static int __devinit i5k_amb_probe(struct platform_device *pdev)
> +{
> + struct i5k_amb_data *data;
> + struct resource *reso;
> + int res = -ENODEV;
> +
> + data = kzalloc(sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + /* Figure out where the AMB registers live */
> + res = i5k_find_amb_registers(data);
> + if (res)
> + goto err;
> +
> + /* Copy the DIMM presence map for the first two channels */
> + res = i5k_channel_probe(data, 0);
> + if (res)
> + goto err;
> +
> + /* Copy the DIMM presence map for the optional second two channels */
> + i5k_channel_probe(data, 1);
> +
> + /* Set up resource regions */
> + reso = request_mem_region(data->amb_base, data->amb_len, DRVNAME);
> + if (!reso) {
> + res = -EBUSY;
> + goto err;
> + }
> +
> + data->amb_mmio = ioremap_nocache(data->amb_base, data->amb_len);
> + if (!data->amb_mmio) {
> + res = -EBUSY;
> + goto err_map_failed;
> + }
> +
> + platform_set_drvdata(pdev, data);
> +
> + res = i5k_amb_hwmon_init(pdev);
> + if (res)
> + goto err_init_failed;
> +
> + return res;
> +
> +err_init_failed:
> + iounmap(data->amb_mmio);
> + platform_set_drvdata(pdev, NULL);
> +err_map_failed:
> + release_mem_region(data->amb_base, data->amb_len);
> +err:
> + kfree(data);
> + return res;
> +}
> +
> +static int __devexit i5k_amb_remove(struct platform_device *pdev)
> +{
> + int i;
> + struct i5k_amb_data *data = platform_get_drvdata(pdev);
> +
> + hwmon_device_unregister(data->hwmon_dev);
> + device_remove_file(>dev, _attr_name);
> + for (i = 0; i < data->num_attrs; i++)
> + device_remove_file(>dev, >attrs[i].s_attr.dev_attr);
> + kfree(data->attrs);
> + iounmap(data->amb_mmio);
> + release_mem_region(data->amb_base, data->amb_len);
> + platform_set_drvdata(pdev, NULL);
> + kfree(data);
> + return 0;
> +}
> +
> +static struct platform_driver i5k_amb_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = DRVNAME,
> + },
> + .probe = i5k_amb_probe,
> + .remove = __devexit_p(i5k_amb_remove),
> +};
> +
> +static int __init i5k_amb_init(void)
> +{
> + int res;
> +
> + res = platform_driver_register(_amb_driver);
> + if (res)
> + return res;
> +
> + res = i5k_amb_add();
> + if (res)
> + platform_driver_unregister(_amb_driver);
> +
> + return res;
> +}
> +
> +static void __exit i5k_amb_exit(void)
> +{
> + platform_device_unregister(amb_pdev);
> + platform_driver_unregister(_amb_driver);
> +}
> +
> +MODULE_AUTHOR("Darrick J. Wong <[EMAIL PROTECTED]>");
> +MODULE_DESCRIPTION("Intel 5000 chipset FB-DIMM AMB temperature sensor");
> +MODULE_LICENSE("GPL");
> +
> +module_init(i5k_amb_init);
> +module_exit(i5k_amb_exit);
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 55f307f..d641b2f 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2241,6 +2241,9 @@
> #define PCI_DEVICE_ID_INTEL_82915G_IG0x2582
> #define PCI_DEVICE_ID_INTEL_82915GM_HB 0x2590
> #define PCI_DEVICE_ID_INTEL_82915GM_IG 0x2592
> +#define PCI_DEVICE_ID_INTEL_5000_ERR 0x25F0
> +#define PCI_DEVICE_ID_INTEL_5000_FBD00x25F5
> +#define PCI_DEVICE_ID_INTEL_5000_FBD10x25F6
> #define PCI_DEVICE_ID_INTEL_82945G_HB0x2770
> #define PCI_DEVICE_ID_INTEL_82945G_IG0x2772
> #define PCI_DEVICE_ID_INTEL_3000_HB 0x2778
diff --git a/drivers/hwmon/i5k_amb.c b/drivers/hwmon/i5k_amb.c
index 3bde717..65ecc56 100644
--- a/drivers/hwmon/i5k_amb.c
+++ b/drivers/hwmon/i5k_amb.c
@@ -400,25 +400,12 @@ out:
return res;
}
-static int __devinit i5k_channel_probe(struct i5k_amb_data *data, int which)
+static int __devinit i5k_channel_probe(u16 *amb_present, unsigned long dev_id)
{
struct pci_dev *pcidev;
- unsigned long dev_id;
u16 val16;
int res = -ENODEV;
- /* Two memory channels per FBD PCI device */
- switch (which) {
- case 0:
- dev_id = PCI_DEVICE_ID_INTEL_5000_FBD0;
- break;
- case 1:
- dev_id = PCI_DEVICE_ID_INTEL_5000_FBD1;
- break;
- default:
- return -EINVAL;
- }
-
/* Copy the DIMM presence map for these two channels */
pcidev = pci_get_device(PCI_VENDOR_ID_INTEL, dev_id, NULL);
if (!pcidev)
@@ -426,11 +413,11 @@ static int __devinit i5k_channel_probe(struct
i5k_amb_data *data, int which)
if (pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, ))
goto out;
- data->amb_present[which * 2] = val16;
+ amb_present[0] = val16;
if (pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, ))
goto out;
- data->amb_present[which * 2 + 1] = val16;
+ amb_present[1] = val16;
res = 0;
@@ -455,12 +442,14 @@ static int __devinit i5k_amb_probe(struct platform_device
*pdev)
goto err;
/* Copy the DIMM presence map for the first two channels */
- res = i5k_channel_probe(data, 0);
+ res = i5k_channel_probe(>amb_present[0],
+ PCI_DEVICE_ID_INTEL_5000_FBD0);
if (res)
goto err;
/* Copy the DIMM presence map for the optional second two channels */
- i5k_channel_probe(data, 1);
+ i5k_channel_probe(>amb_present[2],
+ PCI_DEVICE_ID_INTEL_5000_FBD1);
/* Set up resource regions */
reso = request_mem_region(data->amb_base, data->amb_len, DRVNAME);
Thanks & regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] i5k_amb: New memory temperature sensor driver
)
+{
+ int i;
+ struct i5k_amb_data *data = platform_get_drvdata(pdev);
+
+ hwmon_device_unregister(data-hwmon_dev);
+ device_remove_file(pdev-dev, dev_attr_name);
+ for (i = 0; i data-num_attrs; i++)
+ device_remove_file(pdev-dev, data-attrs[i].s_attr.dev_attr);
+ kfree(data-attrs);
+ iounmap(data-amb_mmio);
+ release_mem_region(data-amb_base, data-amb_len);
+ platform_set_drvdata(pdev, NULL);
+ kfree(data);
+ return 0;
+}
+
+static struct platform_driver i5k_amb_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRVNAME,
+ },
+ .probe = i5k_amb_probe,
+ .remove = __devexit_p(i5k_amb_remove),
+};
+
+static int __init i5k_amb_init(void)
+{
+ int res;
+
+ res = platform_driver_register(i5k_amb_driver);
+ if (res)
+ return res;
+
+ res = i5k_amb_add();
+ if (res)
+ platform_driver_unregister(i5k_amb_driver);
+
+ return res;
+}
+
+static void __exit i5k_amb_exit(void)
+{
+ platform_device_unregister(amb_pdev);
+ platform_driver_unregister(i5k_amb_driver);
+}
+
+MODULE_AUTHOR(Darrick J. Wong [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Intel 5000 chipset FB-DIMM AMB temperature sensor);
+MODULE_LICENSE(GPL);
+
+module_init(i5k_amb_init);
+module_exit(i5k_amb_exit);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 55f307f..d641b2f 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2241,6 +2241,9 @@
#define PCI_DEVICE_ID_INTEL_82915G_IG0x2582
#define PCI_DEVICE_ID_INTEL_82915GM_HB 0x2590
#define PCI_DEVICE_ID_INTEL_82915GM_IG 0x2592
+#define PCI_DEVICE_ID_INTEL_5000_ERR 0x25F0
+#define PCI_DEVICE_ID_INTEL_5000_FBD00x25F5
+#define PCI_DEVICE_ID_INTEL_5000_FBD10x25F6
#define PCI_DEVICE_ID_INTEL_82945G_HB0x2770
#define PCI_DEVICE_ID_INTEL_82945G_IG0x2772
#define PCI_DEVICE_ID_INTEL_3000_HB 0x2778
diff --git a/drivers/hwmon/i5k_amb.c b/drivers/hwmon/i5k_amb.c
index 3bde717..65ecc56 100644
--- a/drivers/hwmon/i5k_amb.c
+++ b/drivers/hwmon/i5k_amb.c
@@ -400,25 +400,12 @@ out:
return res;
}
-static int __devinit i5k_channel_probe(struct i5k_amb_data *data, int which)
+static int __devinit i5k_channel_probe(u16 *amb_present, unsigned long dev_id)
{
struct pci_dev *pcidev;
- unsigned long dev_id;
u16 val16;
int res = -ENODEV;
- /* Two memory channels per FBD PCI device */
- switch (which) {
- case 0:
- dev_id = PCI_DEVICE_ID_INTEL_5000_FBD0;
- break;
- case 1:
- dev_id = PCI_DEVICE_ID_INTEL_5000_FBD1;
- break;
- default:
- return -EINVAL;
- }
-
/* Copy the DIMM presence map for these two channels */
pcidev = pci_get_device(PCI_VENDOR_ID_INTEL, dev_id, NULL);
if (!pcidev)
@@ -426,11 +413,11 @@ static int __devinit i5k_channel_probe(struct
i5k_amb_data *data, int which)
if (pci_read_config_word(pcidev, I5K_REG_CHAN0_PRESENCE_ADDR, val16))
goto out;
- data-amb_present[which * 2] = val16;
+ amb_present[0] = val16;
if (pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, val16))
goto out;
- data-amb_present[which * 2 + 1] = val16;
+ amb_present[1] = val16;
res = 0;
@@ -455,12 +442,14 @@ static int __devinit i5k_amb_probe(struct platform_device
*pdev)
goto err;
/* Copy the DIMM presence map for the first two channels */
- res = i5k_channel_probe(data, 0);
+ res = i5k_channel_probe(data-amb_present[0],
+ PCI_DEVICE_ID_INTEL_5000_FBD0);
if (res)
goto err;
/* Copy the DIMM presence map for the optional second two channels */
- i5k_channel_probe(data, 1);
+ i5k_channel_probe(data-amb_present[2],
+ PCI_DEVICE_ID_INTEL_5000_FBD1);
/* Set up resource regions */
reso = request_mem_region(data-amb_base, data-amb_len, DRVNAME);
Thanks regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: hwmon/f75375s.c: buggy if()
Hi:
* Riku Voipio [EMAIL PROTECTED] [2007-10-17 23:45:08 +0300]:
-- snip --
...
static ssize_t set_pwm_mode(struct device *dev, struct device_attribute
*attr,
const char *buf, size_t count)
{
...
if (val != 0 || val != 1 || data-kind == f75373)
return -EINVAL;
...
-- snip --
I'm not sure what exactly was intended, but it was for sure not intended
to always return -EINVAL...
Aiee. val should be 1 or 0, and kind must not be f75373.
Signed-off-by: Riku Voipio [EMAIL PROTECTED]
---
drivers/hwmon/f75375s.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/hwmon/f75375s.c b/drivers/hwmon/f75375s.c
index f1df57a..885bfe9 100644
--- a/drivers/hwmon/f75375s.c
+++ b/drivers/hwmon/f75375s.c
@@ -344,7 +344,7 @@ static ssize_t set_pwm_mode(struct device *dev, struct
device_attribute *attr,
int val = simple_strtoul(buf, NULL, 10);
u8 conf = 0;
- if (val != 0 || val != 1 || data-kind == f75373)
+ if (!(val == 0 || val == 1 ) || data-kind == f75373)
return -EINVAL;
mutex_lock(data-update_lock);
--
1.5.3.1
That patch doesn't apply here, so I applied this:
commit 805763cd743f2aed41dc61a55569fa43cf1f240c
Author: Riku Voipio [EMAIL PROTECTED]
Date: Thu Oct 18 09:29:53 2007 -0400
hwmon: (f75375s) fix pwm mode setting
Spotted by the Coverity checker. (Thanks Adrian Bunk)
Signed-off-by: Riku Voipio [EMAIL PROTECTED]
Signed-off-by: Mark M. Hoffman [EMAIL PROTECTED]
diff --git a/drivers/hwmon/f75375s.c b/drivers/hwmon/f75375s.c
index 13a0413..59a3470 100644
--- a/drivers/hwmon/f75375s.c
+++ b/drivers/hwmon/f75375s.c
@@ -323,7 +323,7 @@ static ssize_t set_pwm_mode(struct device *dev, struct
device_attribute *attr,
int val = simple_strtoul(buf, NULL, 10);
u8 conf = 0;
- if (val != 0 || val != 1 || data-kind == f75373)
+ if (!(val == 0 || val == 1) || data-kind == f75373)
return -EINVAL;
mutex_lock(data-update_lock);
Thanks regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] hwmon/ibmpex.c: fix NULL dereference
Hi:
* Adrian Bunk [EMAIL PROTECTED] [2007-10-17 21:29:02 +0200]:
Don't dereference data when we know for sure it's NULL.
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
66bec2ef5c6d55fc30ef6ac5bb97fdfcfaf394f2
diff --git a/drivers/hwmon/ibmpex.c b/drivers/hwmon/ibmpex.c
index c462824..e14ce3d 100644
--- a/drivers/hwmon/ibmpex.c
+++ b/drivers/hwmon/ibmpex.c
@@ -457,7 +457,7 @@ static void ibmpex_register_bmc(int iface, struct device
*dev)
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data) {
printk(KERN_ERR DRVNAME : Insufficient memory for BMC
-interface %d.\n, data-interface);
+interface.\n);
return;
}
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH v3] hwmon: Add power meter spec to Documentation/hwmon/sysfs-interface
Hi: > On Tue, 9 Oct 2007 13:39:24 -0700, Darrick J. Wong wrote: > > Update the hwmon sysfs interface documentation to include a specification > > for power meters. > > > > Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]> > > --- > > > > Documentation/hwmon/sysfs-interface | 31 +++ > > 1 files changed, 31 insertions(+), 0 deletions(-) * Jean Delvare <[EMAIL PROTECTED]> [2007-10-15 17:10:29 +0200]: > Looks good, thanks for your patience :) > > Acked-by: Jean Delvare <[EMAIL PROTECTED]> Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH v3] hwmon: Add power meter spec to Documentation/hwmon/sysfs-interface
Hi: On Tue, 9 Oct 2007 13:39:24 -0700, Darrick J. Wong wrote: Update the hwmon sysfs interface documentation to include a specification for power meters. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] --- Documentation/hwmon/sysfs-interface | 31 +++ 1 files changed, 31 insertions(+), 0 deletions(-) * Jean Delvare [EMAIL PROTECTED] [2007-10-15 17:10:29 +0200]: Looks good, thanks for your patience :) Acked-by: Jean Delvare [EMAIL PROTECTED] Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23.1 x86 hardware monitoring bug?
Hi Justin: (added some CCs) * Justin Piszcz <[EMAIL PROTECTED]> [2007-10-14 15:30:18 -0400]: > As a regular user, I cannot see the sensors on the A-bit board, but I can > see the CPU temperature, how come I can see one but not the other? > > Kernel: $ uname -a > Linux mybox 2.6.23.1 #4 SMP PREEMPT Sun Oct 14 15:20:53 EDT 2007 i686 > GNU/Linux > Distribution: Debian Lenny > > $ sensors > abituguru3-isa-00e0 > Adapter: ISA adapter > > coretemp-isa- > Adapter: ISA adapter > temp1: +35°C (high = +85°C) > > coretemp-isa-0001 > Adapter: ISA adapter > temp1: +36°C (high = +85°C) > > As root: > > # sensors > abituguru3-isa-00e0 > Adapter: ISA adapter > CPU Core: +1.35 V (min +0.00 V, max +1.60 V) > DDR2: +2.02 V (min +1.60 V, max +2.40 V) > DDR2 VTT: +1.01 V (min +0.80 V, max +1.20 V) > CPU VTT 1.2V: +1.22 V (min +0.95 V, max +1.45 V) > MCH & PCIE 1.5V:+1.50 V (min +1.20 V, max +1.80 V) > MCH 2.5V: +2.58 V (min +2.00 V, max +3.00 V) > ICH 1.05V: +1.04 V (min +0.85 V, max +1.25 V) > ATX +12V (24-Pin): +12.18 V (min +9.60 V, max +14.40 V) > ATX +12V (4-pin): +12.24 V (min +9.60 V, max +14.40 V) > ATX +5V:+5.07 V (min +3.99 V, max +6.00 V) > +3.3V: +3.40 V (min +2.64 V, max +3.94 V) > 5VSB: +5.10 V (min +3.99 V, max +6.00 V) > CPU: +43°C (high = +75°C, crit = +85°C) > System : +38°C (high = +55°C, crit = +65°C) > PWM1: +43°C (high = +80°C, crit = +90°C) > PWM2: +43°C (high = +80°C, crit = +90°C) > PWM3: +46°C (high = +80°C, crit = +90°C) > PWM4: +40°C (high = +80°C, crit = +90°C) > CPU Fan: 1380 RPM (min 300 RPM) > NB Fan: 0 RPM (min 300 RPM) > SYS Fan: 0 RPM (min 300 RPM) > AUX1 Fan: 0 RPM (min 300 RPM) > AUX2 Fan: 0 RPM (min 300 RPM) > AUX3 Fan: 0 RPM (min 300 RPM) > OTES1 Fan:0 RPM (min 300 RPM) > > coretemp-isa- > Adapter: ISA adapter > Core 0: +39°C (high = +85°C) > > coretemp-isa-0001 > Adapter: ISA adapter > Core 1: +39°C (high = +85°C) Strange. What does 'ls -lH /sys/class/hwmon/hwmon*/device' say? Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates against v2.6.23
essages hwmon: Update the sysfs interface documentation hwmon: (lm85) Use dynamic sysfs callbacks hwmon: (lm85) Export in5, in6 and in7 voltage channels hwmon: (lm85) Add individual alarm files hwmon: (lm85) Clean up the handling of additional resolution bits hwmon: (lm85) Let the user set the fan min limit to 0 hwmon: (lm93) Use standard names for vid files hwmon: (it87) Add support for fan4 and fan5 hwmon: Kconfig dependency cleanups hwmon: (lm90) Export temperature offset values hwmon: (lm78) Add individual alarm files hwmon: (lm87) Fix a division by zero hwmon: (lm87) Add individual alarm files hwmon: (thmc50) Don't create temp3 if not enabled hwmon: (thmc50) Fix a debug message hwmon: Fix the code examples in documentation hwmon: VRM is not read from registers hwmon: (w83781d) Add individual alarm and beep files hwmon: (lm87) Disable VID when it should be hwmon: (w83627hf) Fix setting fan min right after driver load hwmon: (w83627hf) don't assume bank 0 Jim Cromie (1): hwmon: (w83627hf) De-macro sysfs callback functions Juerg Haefliger (3): hwmon: (dme1737) cleanups hwmon: (dme1737) group functions logically hwmon: (dme1737) Add sch311x support Krzysztof Helt (5): hwmon: adm1021 clean ups hwmon: (thmc50) add individual alarm & fault files hwmon: (thmc50) Fix alarms clearing hwmon: (adm1021) dynamic sysfs callbacks conversion hwmon: (adm1021) individual alarm files Mark M. Hoffman (5): hwmon: (f71882fg) trivial whitespace cleanup MAINTAINERS: update hwmon subsystem git trees hwmon: (dme1737) Fix some merge conflicts hwmon: (sis5595) fix sparse warning hwmon: (vt8231) fix sparse warning Riku Voipio (1): hwmon: Add f75375s driver Rudolf Marek (1): hwmon: (coretemp) Add support for Celeron 4xx Satyam Sharma (1): hwmon: (coretemp) Remove bogus __cpuinitdata etc cleanup Tony Jones (1): hwmon: Convert from class_device to device -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates against v2.6.23
hwmon: Update the sysfs interface documentation hwmon: (lm85) Use dynamic sysfs callbacks hwmon: (lm85) Export in5, in6 and in7 voltage channels hwmon: (lm85) Add individual alarm files hwmon: (lm85) Clean up the handling of additional resolution bits hwmon: (lm85) Let the user set the fan min limit to 0 hwmon: (lm93) Use standard names for vid files hwmon: (it87) Add support for fan4 and fan5 hwmon: Kconfig dependency cleanups hwmon: (lm90) Export temperature offset values hwmon: (lm78) Add individual alarm files hwmon: (lm87) Fix a division by zero hwmon: (lm87) Add individual alarm files hwmon: (thmc50) Don't create temp3 if not enabled hwmon: (thmc50) Fix a debug message hwmon: Fix the code examples in documentation hwmon: VRM is not read from registers hwmon: (w83781d) Add individual alarm and beep files hwmon: (lm87) Disable VID when it should be hwmon: (w83627hf) Fix setting fan min right after driver load hwmon: (w83627hf) don't assume bank 0 Jim Cromie (1): hwmon: (w83627hf) De-macro sysfs callback functions Juerg Haefliger (3): hwmon: (dme1737) cleanups hwmon: (dme1737) group functions logically hwmon: (dme1737) Add sch311x support Krzysztof Helt (5): hwmon: adm1021 clean ups hwmon: (thmc50) add individual alarm fault files hwmon: (thmc50) Fix alarms clearing hwmon: (adm1021) dynamic sysfs callbacks conversion hwmon: (adm1021) individual alarm files Mark M. Hoffman (5): hwmon: (f71882fg) trivial whitespace cleanup MAINTAINERS: update hwmon subsystem git trees hwmon: (dme1737) Fix some merge conflicts hwmon: (sis5595) fix sparse warning hwmon: (vt8231) fix sparse warning Riku Voipio (1): hwmon: Add f75375s driver Rudolf Marek (1): hwmon: (coretemp) Add support for Celeron 4xx Satyam Sharma (1): hwmon: (coretemp) Remove bogus __cpuinitdata etc cleanup Tony Jones (1): hwmon: Convert from class_device to device -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23.1 x86 hardware monitoring bug?
Hi Justin: (added some CCs) * Justin Piszcz [EMAIL PROTECTED] [2007-10-14 15:30:18 -0400]: As a regular user, I cannot see the sensors on the A-bit board, but I can see the CPU temperature, how come I can see one but not the other? Kernel: $ uname -a Linux mybox 2.6.23.1 #4 SMP PREEMPT Sun Oct 14 15:20:53 EDT 2007 i686 GNU/Linux Distribution: Debian Lenny $ sensors abituguru3-isa-00e0 Adapter: ISA adapter coretemp-isa- Adapter: ISA adapter temp1: +35°C (high = +85°C) coretemp-isa-0001 Adapter: ISA adapter temp1: +36°C (high = +85°C) As root: # sensors abituguru3-isa-00e0 Adapter: ISA adapter CPU Core: +1.35 V (min +0.00 V, max +1.60 V) DDR2: +2.02 V (min +1.60 V, max +2.40 V) DDR2 VTT: +1.01 V (min +0.80 V, max +1.20 V) CPU VTT 1.2V: +1.22 V (min +0.95 V, max +1.45 V) MCH PCIE 1.5V:+1.50 V (min +1.20 V, max +1.80 V) MCH 2.5V: +2.58 V (min +2.00 V, max +3.00 V) ICH 1.05V: +1.04 V (min +0.85 V, max +1.25 V) ATX +12V (24-Pin): +12.18 V (min +9.60 V, max +14.40 V) ATX +12V (4-pin): +12.24 V (min +9.60 V, max +14.40 V) ATX +5V:+5.07 V (min +3.99 V, max +6.00 V) +3.3V: +3.40 V (min +2.64 V, max +3.94 V) 5VSB: +5.10 V (min +3.99 V, max +6.00 V) CPU: +43°C (high = +75°C, crit = +85°C) System : +38°C (high = +55°C, crit = +65°C) PWM1: +43°C (high = +80°C, crit = +90°C) PWM2: +43°C (high = +80°C, crit = +90°C) PWM3: +46°C (high = +80°C, crit = +90°C) PWM4: +40°C (high = +80°C, crit = +90°C) CPU Fan: 1380 RPM (min 300 RPM) NB Fan: 0 RPM (min 300 RPM) SYS Fan: 0 RPM (min 300 RPM) AUX1 Fan: 0 RPM (min 300 RPM) AUX2 Fan: 0 RPM (min 300 RPM) AUX3 Fan: 0 RPM (min 300 RPM) OTES1 Fan:0 RPM (min 300 RPM) coretemp-isa- Adapter: ISA adapter Core 0: +39°C (high = +85°C) coretemp-isa-0001 Adapter: ISA adapter Core 1: +39°C (high = +85°C) Strange. What does 'ls -lH /sys/class/hwmon/hwmon*/device' say? Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ibmpex: Release IPMI user if hwmon registration fails
Hi: * Darrick J. Wong <[EMAIL PROTECTED]> [2007-10-09 15:08:24 -0700]: > Roel Kluin <[EMAIL PROTECTED]> found a minor defect in the init code if > hwmon device registration fails. > > Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]> > --- > > drivers/hwmon/ibmpex.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwmon/ibmpex.c b/drivers/hwmon/ibmpex.c > index fe2c261..c462824 100644 > --- a/drivers/hwmon/ibmpex.c > +++ b/drivers/hwmon/ibmpex.c > @@ -498,8 +498,7 @@ static void ibmpex_register_bmc(int iface, struct device > *dev) > printk(KERN_ERR DRVNAME ": Error, unable to register hwmon " > "class device for interface %d\n", > data->interface); > - kfree(data); > - return; > + goto out_user; > } > > /* finally add the new bmc data to the bmc data list */ Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ibmpex: Release IPMI user if hwmon registration fails
Hi: * Darrick J. Wong [EMAIL PROTECTED] [2007-10-09 15:08:24 -0700]: Roel Kluin [EMAIL PROTECTED] found a minor defect in the init code if hwmon device registration fails. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] --- drivers/hwmon/ibmpex.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/hwmon/ibmpex.c b/drivers/hwmon/ibmpex.c index fe2c261..c462824 100644 --- a/drivers/hwmon/ibmpex.c +++ b/drivers/hwmon/ibmpex.c @@ -498,8 +498,7 @@ static void ibmpex_register_bmc(int iface, struct device *dev) printk(KERN_ERR DRVNAME : Error, unable to register hwmon class device for interface %d\n, data-interface); - kfree(data); - return; + goto out_user; } /* finally add the new bmc data to the bmc data list */ Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] IBM power meter driver
data->interface = iface;
> + data->bmc_device = dev;
> +
> + /* Create IPMI messaging interface user */
> + err = ipmi_create_user(data->interface, _data.ipmi_hndlrs,
> +data, >user);
> + if (err < 0) {
> + printk(KERN_ERR DRVNAME ": Error, unable to register user with "
> +"ipmi interface %d\n",
> +data->interface);
> + goto out;
> + }
> +
> + mutex_init(>lock);
> +
> + /* Initialize message */
> + data->tx_msgid = 0;
> + init_completion(>read_complete);
> + data->tx_message.netfn = PEX_NET_FUNCTION;
> + data->tx_message.cmd = PEX_COMMAND;
> + data->tx_message.data = data->tx_msg_data;
> +
> + /* Does this BMC support PowerExecutive? */
> + err = ibmpex_ver_check(data);
> + if (err)
> + goto out_user;
> +
> + /* Register the BMC as a HWMON class device */
> + data->hwmon_dev = hwmon_device_register(data->bmc_device);
> +
> + if (IS_ERR(data->hwmon_dev)) {
> + printk(KERN_ERR DRVNAME ": Error, unable to register hwmon "
> +"class device for interface %d\n",
> +data->interface);
> + kfree(data);
> + return;
> + }
> +
> + /* finally add the new bmc data to the bmc data list */
> + dev_set_drvdata(dev, data);
> + list_add_tail(>list, _data.bmc_data);
> +
> + /* Now go find all the sensors */
> + err = ibmpex_find_sensors(data);
> + if (err) {
> + printk(KERN_ERR "Error %d allocating memory\n", err);
> + goto out_register;
> + }
> +
> + return;
> +
> +out_register:
> + hwmon_device_unregister(data->hwmon_dev);
> +out_user:
> + ipmi_destroy_user(data->user);
> +out:
> + kfree(data);
> +}
> +
> +static void ibmpex_bmc_delete(struct ibmpex_bmc_data *data)
> +{
> + int i, j;
> +
> + device_remove_file(data->bmc_device,
> +_dev_attr_reset_high_low.dev_attr);
> + device_remove_file(data->bmc_device, _dev_attr_name.dev_attr);
> + for (i = 0; i < data->num_sensors; i++)
> + for (j = 0; j < PEX_NUM_SENSOR_FUNCS; j++) {
> + if (!data->sensors[i].attr[j].dev_attr.attr.name)
> + continue;
> + device_remove_file(data->bmc_device,
> + >sensors[i].attr[j].dev_attr);
> + kfree(data->sensors[i].attr[j].dev_attr.attr.name);
> + }
> +
> + list_del(>list);
> + dev_set_drvdata(data->bmc_device, NULL);
> + hwmon_device_unregister(data->hwmon_dev);
> + ipmi_destroy_user(data->user);
> + kfree(data->sensors);
> + kfree(data);
> +}
> +
> +static void ibmpex_bmc_gone(int iface)
> +{
> + struct ibmpex_bmc_data *data = get_bmc_data(iface);
> +
> + if (!data)
> + return;
> +
> + ibmpex_bmc_delete(data);
> +}
> +
> +static void ibmpex_msg_handler(struct ipmi_recv_msg *msg, void
> *user_msg_data)
> +{
> + struct ibmpex_bmc_data *data = (struct ibmpex_bmc_data *)user_msg_data;
> +
> + if (msg->msgid != data->tx_msgid) {
> + printk(KERN_ERR "Received msgid (%02x) and transmitted "
> +"msgid (%02x) mismatch!\n",
> +(int)msg->msgid,
> +(int)data->tx_msgid);
> + ipmi_free_recv_msg(msg);
> + return;
> + }
> +
> + data->rx_recv_type = msg->recv_type;
> + if (msg->msg.data_len > 0)
> + data->rx_result = msg->msg.data[0];
> + else
> + data->rx_result = IPMI_UNKNOWN_ERR_COMPLETION_CODE;
> +
> + if (msg->msg.data_len > 1) {
> + data->rx_msg_len = msg->msg.data_len - 1;
> + memcpy(data->rx_msg_data, msg->msg.data + 1, data->rx_msg_len);
> + } else
> + data->rx_msg_len = 0;
> +
> + ipmi_free_recv_msg(msg);
> + complete(>read_complete);
> +}
> +
> +static int __init ibmpex_init(void)
> +{
> + return ipmi_smi_watcher_register(_data.bmc_events);
> +}
> +
> +static void __exit ibmpex_exit(void)
> +{
> + struct ibmpex_bmc_data *p, *next;
> +
> + ipmi_smi_watcher_unregister(_data.bmc_events);
> + list_for_each_entry_safe(p, next, _data.bmc_data, list)
> + ibmpex_bmc_delete(p);
> +}
> +
> +MODULE_AUTHOR("Darrick J. Wong <[EMAIL PROTECTED]>");
> +MODULE_DESCRIPTION("IBM PowerExecutive power/temperature sensor driver");
> +MODULE_LICENSE("GPL");
> +
> +module_init(ibmpex_init);
> +module_exit(ibmpex_exit);
Regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] IBM power meter driver
-user);
+ kfree(data-sensors);
+ kfree(data);
+}
+
+static void ibmpex_bmc_gone(int iface)
+{
+ struct ibmpex_bmc_data *data = get_bmc_data(iface);
+
+ if (!data)
+ return;
+
+ ibmpex_bmc_delete(data);
+}
+
+static void ibmpex_msg_handler(struct ipmi_recv_msg *msg, void
*user_msg_data)
+{
+ struct ibmpex_bmc_data *data = (struct ibmpex_bmc_data *)user_msg_data;
+
+ if (msg-msgid != data-tx_msgid) {
+ printk(KERN_ERR Received msgid (%02x) and transmitted
+msgid (%02x) mismatch!\n,
+(int)msg-msgid,
+(int)data-tx_msgid);
+ ipmi_free_recv_msg(msg);
+ return;
+ }
+
+ data-rx_recv_type = msg-recv_type;
+ if (msg-msg.data_len 0)
+ data-rx_result = msg-msg.data[0];
+ else
+ data-rx_result = IPMI_UNKNOWN_ERR_COMPLETION_CODE;
+
+ if (msg-msg.data_len 1) {
+ data-rx_msg_len = msg-msg.data_len - 1;
+ memcpy(data-rx_msg_data, msg-msg.data + 1, data-rx_msg_len);
+ } else
+ data-rx_msg_len = 0;
+
+ ipmi_free_recv_msg(msg);
+ complete(data-read_complete);
+}
+
+static int __init ibmpex_init(void)
+{
+ return ipmi_smi_watcher_register(driver_data.bmc_events);
+}
+
+static void __exit ibmpex_exit(void)
+{
+ struct ibmpex_bmc_data *p, *next;
+
+ ipmi_smi_watcher_unregister(driver_data.bmc_events);
+ list_for_each_entry_safe(p, next, driver_data.bmc_data, list)
+ ibmpex_bmc_delete(p);
+}
+
+MODULE_AUTHOR(Darrick J. Wong [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(IBM PowerExecutive power/temperature sensor driver);
+MODULE_LICENSE(GPL);
+
+module_init(ibmpex_init);
+module_exit(ibmpex_exit);
Regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] v3 of IBM power meter driver
>address.data[0] = 0;
> + data->interface = iface;
> + data->bmc_device = dev;
> +
> + /* Create IPMI messaging interface user */
> + err = ipmi_create_user(data->interface, _data.ipmi_hndlrs,
> +data, >user);
> + if (err < 0) {
> + printk(KERN_ERR DRVNAME ": Error, unable to register user with "
> +"ipmi interface %d\n",
> +data->interface);
> + goto out;
> + }
> +
> + mutex_init(>lock);
> +
> + /* Initialize message */
> + data->tx_msgid = 0;
> + init_completion(>read_complete);
> + data->tx_message.netfn = PEX_NET_FUNCTION;
> + data->tx_message.cmd = PEX_COMMAND;
> + data->tx_message.data = data->tx_msg_data;
> +
> + /* Does this BMC support PowerExecutive? */
> + err = ibmpex_ver_check(data);
> + if (err)
> + goto out_user;
> +
> + /* Register the BMC as a HWMON class device */
> + data->class_dev = hwmon_device_register(data->bmc_device);
> +
> + if (IS_ERR(data->class_dev)) {
> + printk(KERN_ERR DRVNAME ": Error, unable to register hwmon "
> +"class device for interface %d\n",
> +data->interface);
> + kfree(data);
> + return;
> + }
> +
> + /* finally add the new bmc data to the bmc data list */
> + list_add_tail(>list, _data.bmc_data);
> +
> + /* Now go find all the sensors */
> + err = ibmpex_find_sensors(data);
> + if (err) {
> + printk(KERN_ERR "Error %d allocating memory\n", err);
> + goto out_register;
> + }
> +
> + return;
> +
> +out_register:
> + hwmon_device_unregister(data->class_dev);
> +out_user:
> + ipmi_destroy_user(data->user);
> +out:
> + kfree(data);
> +}
> +
> +static void ibmpex_bmc_delete(struct ibmpex_bmc_data *data)
> +{
> + int i, j;
> +
> + device_remove_file(data->bmc_device, _dev_attr_name.dev_attr);
> + for (i = 0; i < data->num_sensors; i++)
> + for (j = 0; j < PEX_NUM_SENSOR_FUNCS; j++) {
> + if (!data->sensors[i].attr[j].dev_attr.attr.name)
> + continue;
> + device_remove_file(data->bmc_device,
> + >sensors[i].attr[j].dev_attr);
> + kfree(data->sensors[i].attr[j].dev_attr.attr.name);
> + }
> +
> + list_del(>list);
> + hwmon_device_unregister(data->class_dev);
> + ipmi_destroy_user(data->user);
> + if (data->sensors)
> + kfree(data->sensors);
> + kfree(data);
> +}
> +
> +static void ibmpex_bmc_gone(int iface)
> +{
> + struct ibmpex_bmc_data *data = get_bmc_data(iface);
> +
> + if (!data)
> + return;
> +
> + ibmpex_bmc_delete(data);
> +}
> +
> +static void ibmpex_msg_handler(struct ipmi_recv_msg *msg, void
> *user_msg_data)
> +{
> + struct ibmpex_bmc_data *data = (struct ibmpex_bmc_data *)user_msg_data;
> +
> + if (msg->msgid != data->tx_msgid) {
> + printk(KERN_ERR "Received msgid (%02x) and transmitted "
> +"msgid (%02x) mismatch!\n",
> +(int)msg->msgid,
> +(int)data->tx_msgid);
> + ipmi_free_recv_msg(msg);
> + return;
> + }
> +
> + data->rx_recv_type = msg->recv_type;
> + if (msg->msg.data_len > 0)
> + data->rx_result = msg->msg.data[0];
> + else
> + data->rx_result = IPMI_UNKNOWN_ERR_COMPLETION_CODE;
> +
> + if (msg->msg.data_len > 1) {
> + data->rx_msg_len = msg->msg.data_len - 1;
> + memcpy(data->rx_msg_data, msg->msg.data + 1, data->rx_msg_len);
> + } else
> + data->rx_msg_len = 0;
> +
> + ipmi_free_recv_msg(msg);
> + complete(>read_complete);
> +}
> +
> +static int __init ibmpex_init(void)
> +{
> + return ipmi_smi_watcher_register(_data.bmc_events);
> +}
> +
> +static void __exit ibmpex_exit(void)
> +{
> + struct ibmpex_bmc_data *p, *next;
> +
> + ipmi_smi_watcher_unregister(_data.bmc_events);
> + list_for_each_entry_safe(p, next, _data.bmc_data, list)
> + ibmpex_bmc_delete(p);
> +}
> +
> +MODULE_AUTHOR("Darrick J. Wong <[EMAIL PROTECTED]>");
> +MODULE_DESCRIPTION("IBM PowerExecutive power/temperature sensor driver");
> +MODULE_LICENSE("GPL");
> +
> +module_init(ibmpex_init);
> +module_exit(ibmpex_exit);
Regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] v3 of IBM power meter driver
-sensors)
+ kfree(data-sensors);
+ kfree(data);
+}
+
+static void ibmpex_bmc_gone(int iface)
+{
+ struct ibmpex_bmc_data *data = get_bmc_data(iface);
+
+ if (!data)
+ return;
+
+ ibmpex_bmc_delete(data);
+}
+
+static void ibmpex_msg_handler(struct ipmi_recv_msg *msg, void
*user_msg_data)
+{
+ struct ibmpex_bmc_data *data = (struct ibmpex_bmc_data *)user_msg_data;
+
+ if (msg-msgid != data-tx_msgid) {
+ printk(KERN_ERR Received msgid (%02x) and transmitted
+msgid (%02x) mismatch!\n,
+(int)msg-msgid,
+(int)data-tx_msgid);
+ ipmi_free_recv_msg(msg);
+ return;
+ }
+
+ data-rx_recv_type = msg-recv_type;
+ if (msg-msg.data_len 0)
+ data-rx_result = msg-msg.data[0];
+ else
+ data-rx_result = IPMI_UNKNOWN_ERR_COMPLETION_CODE;
+
+ if (msg-msg.data_len 1) {
+ data-rx_msg_len = msg-msg.data_len - 1;
+ memcpy(data-rx_msg_data, msg-msg.data + 1, data-rx_msg_len);
+ } else
+ data-rx_msg_len = 0;
+
+ ipmi_free_recv_msg(msg);
+ complete(data-read_complete);
+}
+
+static int __init ibmpex_init(void)
+{
+ return ipmi_smi_watcher_register(driver_data.bmc_events);
+}
+
+static void __exit ibmpex_exit(void)
+{
+ struct ibmpex_bmc_data *p, *next;
+
+ ipmi_smi_watcher_unregister(driver_data.bmc_events);
+ list_for_each_entry_safe(p, next, driver_data.bmc_data, list)
+ ibmpex_bmc_delete(p);
+}
+
+MODULE_AUTHOR(Darrick J. Wong [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(IBM PowerExecutive power/temperature sensor driver);
+MODULE_LICENSE(GPL);
+
+module_init(ibmpex_init);
+module_exit(ibmpex_exit);
Regards,
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon update against v2.6.23-rc5-git1
Hi Linus:
Please pull from:
git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release
You will get one patch (below), which fixes a potential regression from v2.6.22
(although AFAIK there have been no reports about this one.)
commit 15bde2f1a8e819213f54314505a5a0509673109b
Author: Jean Delvare <[EMAIL PROTECTED]>
Date: Wed Aug 29 10:39:57 2007 +0200
hwmon: End of I/O region off-by-one
Fix an off-by-one error in the I/O region declaration of two
hardware monitoring drivers (lm78 and w83781d.) We were requesting
one extra port at the end of the region.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]>
diff --git a/drivers/hwmon/lm78.c b/drivers/hwmon/lm78.c
index 565c4e6..6eea347 100644
--- a/drivers/hwmon/lm78.c
+++ b/drivers/hwmon/lm78.c
@@ -882,7 +882,7 @@ static int __init lm78_isa_device_add(unsigned short
address)
{
struct resource res = {
.start = address,
- .end= address + LM78_EXTENT,
+ .end= address + LM78_EXTENT - 1,
.name = "lm78",
.flags = IORESOURCE_IO,
};
diff --git a/drivers/hwmon/w83781d.c b/drivers/hwmon/w83781d.c
index c95909c..dcc941a 100644
--- a/drivers/hwmon/w83781d.c
+++ b/drivers/hwmon/w83781d.c
@@ -1746,7 +1746,7 @@ w83781d_isa_device_add(unsigned short address)
{
struct resource res = {
.start = address,
- .end= address + W83781D_EXTENT,
+ .end= address + W83781D_EXTENT - 1,
.name = "w83781d",
.flags = IORESOURCE_IO,
};
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon update against v2.6.23-rc5-git1
Hi Linus:
Please pull from:
git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release
You will get one patch (below), which fixes a potential regression from v2.6.22
(although AFAIK there have been no reports about this one.)
commit 15bde2f1a8e819213f54314505a5a0509673109b
Author: Jean Delvare [EMAIL PROTECTED]
Date: Wed Aug 29 10:39:57 2007 +0200
hwmon: End of I/O region off-by-one
Fix an off-by-one error in the I/O region declaration of two
hardware monitoring drivers (lm78 and w83781d.) We were requesting
one extra port at the end of the region.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Signed-off-by: Mark M. Hoffman [EMAIL PROTECTED]
diff --git a/drivers/hwmon/lm78.c b/drivers/hwmon/lm78.c
index 565c4e6..6eea347 100644
--- a/drivers/hwmon/lm78.c
+++ b/drivers/hwmon/lm78.c
@@ -882,7 +882,7 @@ static int __init lm78_isa_device_add(unsigned short
address)
{
struct resource res = {
.start = address,
- .end= address + LM78_EXTENT,
+ .end= address + LM78_EXTENT - 1,
.name = lm78,
.flags = IORESOURCE_IO,
};
diff --git a/drivers/hwmon/w83781d.c b/drivers/hwmon/w83781d.c
index c95909c..dcc941a 100644
--- a/drivers/hwmon/w83781d.c
+++ b/drivers/hwmon/w83781d.c
@@ -1746,7 +1746,7 @@ w83781d_isa_device_add(unsigned short address)
{
struct resource res = {
.start = address,
- .end= address + W83781D_EXTENT,
+ .end= address + W83781D_EXTENT - 1,
.name = w83781d,
.flags = IORESOURCE_IO,
};
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hwmon coretemp: Remove bogus __cpuinitdata etc cleanup
Hi Satyam:
* Satyam Sharma <[EMAIL PROTECTED]> [2007-08-23 09:14:25 +0530]:
>
> The CPU hotplug notifier_block coretemp_cpu_notifier is already defined
> inside an #ifdef HOTPLUG_CPU, therefore marking it as __cpuinitdata is
> quite a pointless thing to do.
>
> Also, remove duplicate prototype of function coretemp_update_device()
> at the top of this file (another one already exists barely 10 lines
> above this one :-)
>
> Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Applied to hwmon-2.6.git/testing, thanks.
> [ Rudolf, Mark, would it be acceptable to you to remove all the open
> #ifdef HOTPLUG_CPU from this file and replace them with __cpuinit{data}
> instead? That could increase size of modular builds, but would remain
> consistent with rest of kernel, and make the file #ifdef-clean ... ]
I am not automatically repulsed by #ifdefs as some are, and in this case the
usage is pretty clear and easy to read (not to mention useful).
I would prefer to leave it.
> drivers/hwmon/coretemp.c |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
> index 7c17952..f7b0ef4 100644
> --- a/drivers/hwmon/coretemp.c
> +++ b/drivers/hwmon/coretemp.c
> @@ -58,8 +58,6 @@ struct coretemp_data {
> u8 alarm;
> };
>
> -static struct coretemp_data *coretemp_update_device(struct device *dev);
> -
> /*
> * Sysfs stuff
> */
> @@ -350,7 +348,7 @@ static int coretemp_cpu_callback(struct notifier_block
> *nfb,
> return NOTIFY_OK;
> }
>
> -static struct notifier_block __cpuinitdata coretemp_cpu_notifier = {
> +static struct notifier_block coretemp_cpu_notifier = {
> .notifier_call = coretemp_cpu_callback,
> };
> #endif /* !CONFIG_HOTPLUG_CPU */
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hwmon coretemp: Remove bogus __cpuinitdata etc cleanup
Hi Satyam:
* Satyam Sharma [EMAIL PROTECTED] [2007-08-23 09:14:25 +0530]:
The CPU hotplug notifier_block coretemp_cpu_notifier is already defined
inside an #ifdef HOTPLUG_CPU, therefore marking it as __cpuinitdata is
quite a pointless thing to do.
Also, remove duplicate prototype of function coretemp_update_device()
at the top of this file (another one already exists barely 10 lines
above this one :-)
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
Applied to hwmon-2.6.git/testing, thanks.
[ Rudolf, Mark, would it be acceptable to you to remove all the open
#ifdef HOTPLUG_CPU from this file and replace them with __cpuinit{data}
instead? That could increase size of modular builds, but would remain
consistent with rest of kernel, and make the file #ifdef-clean ... ]
I am not automatically repulsed by #ifdefs as some are, and in this case the
usage is pretty clear and easy to read (not to mention useful).
I would prefer to leave it.
drivers/hwmon/coretemp.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 7c17952..f7b0ef4 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -58,8 +58,6 @@ struct coretemp_data {
u8 alarm;
};
-static struct coretemp_data *coretemp_update_device(struct device *dev);
-
/*
* Sysfs stuff
*/
@@ -350,7 +348,7 @@ static int coretemp_cpu_callback(struct notifier_block
*nfb,
return NOTIFY_OK;
}
-static struct notifier_block __cpuinitdata coretemp_cpu_notifier = {
+static struct notifier_block coretemp_cpu_notifier = {
.notifier_call = coretemp_cpu_callback,
};
#endif /* !CONFIG_HOTPLUG_CPU */
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [210/2many] MAINTAINERS - HARDWARE MONITORING
Joe: * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-08-12 23:28:20 -0700]: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index e35e29c..f422277 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2015,6 +2015,7 @@ L: [EMAIL PROTECTED] > W: http://www.lm-sensors.org/ > T: git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git > S: Maintained > +F: drivers/hwmon/ > > HARDWARE RANDOM NUMBER GENERATOR CORE > P: Michael Buesch I guess you know by now not to ever do that again. If you collect the hwmon stuff into one (1) patch, I'll take it. Now you'll excuse me while I drive a nail through my delete key. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates against ~v2.6.23-rc2-git
Hi Linus: Please pull from: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release You'll get four bugfixes. This takes care of all known hwmon regressions, and hopefully it's the last you'll hear from me before v2.6.23 goes final. This patch series was also posted to the lm-sensors list yesterday: http://lists.lm-sensors.org/pipermail/lm-sensors/2007-August/020843.html Thanks & regards, drivers/hwmon/smsc47m1.c |2 + drivers/hwmon/w83627ehf.c | 56 +--- drivers/hwmon/w83781d.c |4 +- 3 files changed, 36 insertions(+), 26 deletions(-) Jean Delvare (2): hwmon: (w83627ehf) don't assume bank 0 hwmon: (smsc47m1) restore missing name attribute Mark M. Hoffman (2): hwmon: fix w83781d temp sensor type setting hwmon: (w83627ehf) read fan_div values during probe -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates against ~v2.6.23-rc2-git
Hi Linus: Please pull from: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release You'll get four bugfixes. This takes care of all known hwmon regressions, and hopefully it's the last you'll hear from me before v2.6.23 goes final. This patch series was also posted to the lm-sensors list yesterday: http://lists.lm-sensors.org/pipermail/lm-sensors/2007-August/020843.html Thanks regards, drivers/hwmon/smsc47m1.c |2 + drivers/hwmon/w83627ehf.c | 56 +--- drivers/hwmon/w83781d.c |4 +- 3 files changed, 36 insertions(+), 26 deletions(-) Jean Delvare (2): hwmon: (w83627ehf) don't assume bank 0 hwmon: (smsc47m1) restore missing name attribute Mark M. Hoffman (2): hwmon: fix w83781d temp sensor type setting hwmon: (w83627ehf) read fan_div values during probe -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [210/2many] MAINTAINERS - HARDWARE MONITORING
Joe: * [EMAIL PROTECTED] [EMAIL PROTECTED] [2007-08-12 23:28:20 -0700]: Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index e35e29c..f422277 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2015,6 +2015,7 @@ L: [EMAIL PROTECTED] W: http://www.lm-sensors.org/ T: git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git S: Maintained +F: drivers/hwmon/ HARDWARE RANDOM NUMBER GENERATOR CORE P: Michael Buesch I guess you know by now not to ever do that again. If you collect the hwmon stuff into one (1) patch, I'll take it. Now you'll excuse me while I drive a nail through my delete key. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1 regression: hwmon/w83627ehf: wrong fan speed
Hi Jean:
* Jean Delvare <[EMAIL PROTECTED]> [2007-08-11 13:57:05 +0200]:
> Don't assume that the default bank is 0. For one thing, we don't even
> set it to 0 when the driver is loaded, so the initial state might be
> different. For another, something (say, the BIOS) might access the chip
> and leave with the bank set to something different, so assuming that
> the bank value is 0 is not safe.
>
> Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
> ---
> drivers/hwmon/w83627ehf.c |8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> --- linux-2.6.23-rc2.orig/drivers/hwmon/w83627ehf.c 2007-07-23
> 16:44:35.0 +0200
> +++ linux-2.6.23-rc2/drivers/hwmon/w83627ehf.c2007-08-11
> 12:55:58.0 +0200
> @@ -309,18 +309,16 @@ static inline int is_word_sized(u16 reg)
> || (reg & 0x00ff) == 0x55));
> }
>
> -/* We assume that the default bank is 0, thus the following two functions do
> - nothing for registers which live in bank 0. For others, they respectively
> - set the bank register to the correct value (before the register is
> - accessed), and back to 0 (afterwards). */
> +/* Registers 0x50-0x5f are banked */
> static inline void w83627ehf_set_bank(struct w83627ehf_data *data, u16 reg)
> {
> - if (reg & 0xff00) {
> + if ((reg & 0x00f0) == 0x50) {
> outb_p(W83627EHF_REG_BANK, data->addr + ADDR_REG_OFFSET);
> outb_p(reg >> 8, data->addr + DATA_REG_OFFSET);
> }
> }
>
> +/* Not strictly necessary, but play it safe for now */
> static inline void w83627ehf_reset_bank(struct w83627ehf_data *data, u16 reg)
> {
> if (reg & 0xff00) {
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1 regression: hwmon/w83627ehf: wrong fan speed
Hi Jean:
* Jean Delvare [EMAIL PROTECTED] [2007-08-11 13:57:05 +0200]:
Don't assume that the default bank is 0. For one thing, we don't even
set it to 0 when the driver is loaded, so the initial state might be
different. For another, something (say, the BIOS) might access the chip
and leave with the bank set to something different, so assuming that
the bank value is 0 is not safe.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/hwmon/w83627ehf.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
--- linux-2.6.23-rc2.orig/drivers/hwmon/w83627ehf.c 2007-07-23
16:44:35.0 +0200
+++ linux-2.6.23-rc2/drivers/hwmon/w83627ehf.c2007-08-11
12:55:58.0 +0200
@@ -309,18 +309,16 @@ static inline int is_word_sized(u16 reg)
|| (reg 0x00ff) == 0x55));
}
-/* We assume that the default bank is 0, thus the following two functions do
- nothing for registers which live in bank 0. For others, they respectively
- set the bank register to the correct value (before the register is
- accessed), and back to 0 (afterwards). */
+/* Registers 0x50-0x5f are banked */
static inline void w83627ehf_set_bank(struct w83627ehf_data *data, u16 reg)
{
- if (reg 0xff00) {
+ if ((reg 0x00f0) == 0x50) {
outb_p(W83627EHF_REG_BANK, data-addr + ADDR_REG_OFFSET);
outb_p(reg 8, data-addr + DATA_REG_OFFSET);
}
}
+/* Not strictly necessary, but play it safe for now */
static inline void w83627ehf_reset_bank(struct w83627ehf_data *data, u16 reg)
{
if (reg 0xff00) {
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] bad temperature values from w83781d in 2.6.22
Hi Joerg:
> On Wed, Aug 08, 2007 at 11:56:42PM -0400, Mark M. Hoffman wrote:
> > Thanks for sending all that. I see one bug clearly, and I'm pretty close to
> > seeing the other one. But for tonight, I need sleep.
There's just one bug after all. The second was a figment of my sleep-deprived
imagination.
> > In the meantime, please try this command as root, against the newer kernel,
> > *after* you've done 'sensors -s':
> >
> > # i2cset -f 0 0x2d 0x5d 0x0e b
> >
> > Wait > 2 seconds for the hardware to update itself, then run 'sensors'
> > again.
> > I'm pretty sure you'll see the correct temps.
* Joerg Sommrey <[EMAIL PROTECTED]> [2007-08-09 09:09:15 +0200]:
> The displayed temperatures changed to 67.5°C / 66.0°C. Still, this seems to
> be too high. The power supply's fan runs too slow for such CPU
> temperatures. In older kernels it becomes noisy above 50°C.
>
> Under load the temperatures shown are around 95°C, way too high.
My bad, there's a second i2cset command that would have done it. Please try
this patch against v2.6.22.
* * * * *
commit af720da3a173153b00cebc129c48cd3a40af
Author: Mark M. Hoffman <[EMAIL PROTECTED]>
Date: Thu Aug 9 08:12:46 2007 -0400
hwmon: fix w83781d temp sensor type setting
Commit 348753379a7704087603dad403603e825422fd9a introduced a regression that
caused temp2 and temp3 sensor type settings to be written to temp1 instead.
The result is that temp sensor readings could be way off.
Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]>
diff --git a/drivers/hwmon/w83781d.c b/drivers/hwmon/w83781d.c
index f85b48f..c95909c 100644
--- a/drivers/hwmon/w83781d.c
+++ b/drivers/hwmon/w83781d.c
@@ -740,9 +740,9 @@ store_sensor(struct device *dev, struct device_attribute
*da,
static SENSOR_DEVICE_ATTR(temp1_type, S_IRUGO | S_IWUSR,
show_sensor, store_sensor, 0);
static SENSOR_DEVICE_ATTR(temp2_type, S_IRUGO | S_IWUSR,
- show_sensor, store_sensor, 0);
+ show_sensor, store_sensor, 1);
static SENSOR_DEVICE_ATTR(temp3_type, S_IRUGO | S_IWUSR,
- show_sensor, store_sensor, 0);
+ show_sensor, store_sensor, 2);
/* I2C devices get this name attribute automatically, but for ISA devices
we must create it by ourselves. */
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] bad temperature values from w83781d in 2.6.22
Hi Joerg: On Wed, Aug 08, 2007 at 11:56:42PM -0400, Mark M. Hoffman wrote: Thanks for sending all that. I see one bug clearly, and I'm pretty close to seeing the other one. But for tonight, I need sleep. There's just one bug after all. The second was a figment of my sleep-deprived imagination. In the meantime, please try this command as root, against the newer kernel, *after* you've done 'sensors -s': # i2cset -f 0 0x2d 0x5d 0x0e b Wait 2 seconds for the hardware to update itself, then run 'sensors' again. I'm pretty sure you'll see the correct temps. * Joerg Sommrey [EMAIL PROTECTED] [2007-08-09 09:09:15 +0200]: The displayed temperatures changed to 67.5°C / 66.0°C. Still, this seems to be too high. The power supply's fan runs too slow for such CPU temperatures. In older kernels it becomes noisy above 50°C. Under load the temperatures shown are around 95°C, way too high. My bad, there's a second i2cset command that would have done it. Please try this patch against v2.6.22. * * * * * commit af720da3a173153b00cebc129c48cd3a40af Author: Mark M. Hoffman [EMAIL PROTECTED] Date: Thu Aug 9 08:12:46 2007 -0400 hwmon: fix w83781d temp sensor type setting Commit 348753379a7704087603dad403603e825422fd9a introduced a regression that caused temp2 and temp3 sensor type settings to be written to temp1 instead. The result is that temp sensor readings could be way off. Signed-off-by: Mark M. Hoffman [EMAIL PROTECTED] diff --git a/drivers/hwmon/w83781d.c b/drivers/hwmon/w83781d.c index f85b48f..c95909c 100644 --- a/drivers/hwmon/w83781d.c +++ b/drivers/hwmon/w83781d.c @@ -740,9 +740,9 @@ store_sensor(struct device *dev, struct device_attribute *da, static SENSOR_DEVICE_ATTR(temp1_type, S_IRUGO | S_IWUSR, show_sensor, store_sensor, 0); static SENSOR_DEVICE_ATTR(temp2_type, S_IRUGO | S_IWUSR, - show_sensor, store_sensor, 0); + show_sensor, store_sensor, 1); static SENSOR_DEVICE_ATTR(temp3_type, S_IRUGO | S_IWUSR, - show_sensor, store_sensor, 0); + show_sensor, store_sensor, 2); /* I2C devices get this name attribute automatically, but for ISA devices we must create it by ourselves. */ -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] bad temperature values from w83781d in 2.6.22
Hi Joerg: * Joerg Sommrey <[EMAIL PROTECTED]> [2007-08-08 17:17:16 +0200]: > Hi Mark, > > just to eliminate as many impacts as possible, I did: > - reinstall the unmodified sensors.conf from Tyan's support page > - power off before rebooting > > A call to "sensors -s" is done without errors in all cases. > The module parameters I use currently with both kernels: > > options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49 > options w83627hf force_addr=0x0c00 > > When I first realized the problem, I didn't use w83627hf yet. Results > are the same when w83781d is used as driver for w83627hf. > Parameters in that case just from Tyan: > > options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49 > force_w83627hf=0,0x2c force_subclients=0,0x2c,0x4a,0x4b init=0 > > "My" i2cdump doesn't accept an -y option, maybe a Debianism. Results > see below. Newer i2cdump skips the 5-second warning when given -y, that's all. > ### 2.6.21 ### > Script started on Wed Aug 8 16:53:10 2007 > bear:~/hwmon# i2cdump 0 0x2d b 0 0x4e (snip tons of results) Thanks for sending all that. I see one bug clearly, and I'm pretty close to seeing the other one. But for tonight, I need sleep. In the meantime, please try this command as root, against the newer kernel, *after* you've done 'sensors -s': # i2cset -f 0 0x2d 0x5d 0x0e b Wait > 2 seconds for the hardware to update itself, then run 'sensors' again. I'm pretty sure you'll see the correct temps. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add missing newlines to some uses of dev_ messages
* Joe Perches <[EMAIL PROTECTED]> [2007-08-07 18:09:39 -0700]: > Found these while looking at printk uses. > > Add missing newlines to dev_ uses > Add missing KERN_ prefixes to multiline dev_s > Fixed a wierd->weird spelling typo > Added a newline to a printk > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Looks good. > drivers/hwmon/adm1026.c|2 +- > drivers/hwmon/lm63.c |2 +- > drivers/hwmon/vt1211.c |2 +- > drivers/hwmon/w83791d.c|2 +- > drivers/hwmon/w83792d.c|4 +- Acked-by: Mark M. Hoffman <[EMAIL PROTECTED]> Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add missing newlines to some uses of dev_level messages
* Joe Perches [EMAIL PROTECTED] [2007-08-07 18:09:39 -0700]: Found these while looking at printk uses. Add missing newlines to dev_level uses Add missing KERN_level prefixes to multiline dev_levels Fixed a wierd-weird spelling typo Added a newline to a printk Signed-off-by: Joe Perches [EMAIL PROTECTED] Looks good. drivers/hwmon/adm1026.c|2 +- drivers/hwmon/lm63.c |2 +- drivers/hwmon/vt1211.c |2 +- drivers/hwmon/w83791d.c|2 +- drivers/hwmon/w83792d.c|4 +- Acked-by: Mark M. Hoffman [EMAIL PROTECTED] Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] bad temperature values from w83781d in 2.6.22
Hi Joerg: * Joerg Sommrey [EMAIL PROTECTED] [2007-08-08 17:17:16 +0200]: Hi Mark, just to eliminate as many impacts as possible, I did: - reinstall the unmodified sensors.conf from Tyan's support page - power off before rebooting A call to sensors -s is done without errors in all cases. The module parameters I use currently with both kernels: options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49 options w83627hf force_addr=0x0c00 When I first realized the problem, I didn't use w83627hf yet. Results are the same when w83781d is used as driver for w83627hf. Parameters in that case just from Tyan: options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49 force_w83627hf=0,0x2c force_subclients=0,0x2c,0x4a,0x4b init=0 My i2cdump doesn't accept an -y option, maybe a Debianism. Results see below. Newer i2cdump skips the 5-second warning when given -y, that's all. ### 2.6.21 ### Script started on Wed Aug 8 16:53:10 2007 bear:~/hwmon# i2cdump 0 0x2d b 0 0x4e (snip tons of results) Thanks for sending all that. I see one bug clearly, and I'm pretty close to seeing the other one. But for tonight, I need sleep. In the meantime, please try this command as root, against the newer kernel, *after* you've done 'sensors -s': # i2cset -f 0 0x2d 0x5d 0x0e b Wait 2 seconds for the hardware to update itself, then run 'sensors' again. I'm pretty sure you'll see the correct temps. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bad temperature values from w83781d in 2.6.22
Hi Joerg: (I tried to follow-up using the gmane.org mail/news gateway... didn't seem to work.) * Joerg Sommrey <[EMAIL PROTECTED]> [2007-08-05 12:26:04 +0200]: > Hi, > > after upgrading from 2.6.21 to 2.6.22 the CPU temperatures shown by > w83781d look unreal. They were in a range from 40°C when idle to > 75°C under full load with 2.6.21. The values shown now are in a very > small range from 77°C to 82°C. From the (low) noise of the fan I can > tell that the temperature is <50°C. > The third temperature shown is completely wrong. > > I have a Tyan Tiger MPX board with a w83782d chip. Output from > "sensors": > > w83782d-i2c-0-2d > Adapter: SMBus AMD768 adapter at 80e0 > +5 V: +4.81 V (min = +4.76 V, max = +5.24 V) > 3 VSB: +3.30 V (min = +2.85 V, max = +3.15 V) ALARM > chs3 Fan: 2122 RPM (min = 2657 RPM, div = 4) ALARM > VRM2 Temp: -208°C (high = -176°C, hyst = -181°C) sensor = transistor > CPU1 Temp: +78.5°C (high = +80°C, hyst = +75°C) sensor = transistor > ALARM > CPU2 Temp: +77.5°C (high = +80°C, hyst = +75°C) sensor = transistor > ALARM > alarms: > beep_enable: > Sound alarm enabled > > # cat /sys/bus/i2c/devices/0-002d/temp*_input > -209000 > 77500 > 77500 > > Any ideas? Please run the following commands as root (against both kernel versions) and reply-to-all with the results: # modprobe i2c-dev # i2cdump -y 0 0x2d b 0 0x4e # i2cdump -y 0 0x48 # i2cdump -y 0 0x49 Also, can you confirm that you're using the sensors.conf from here: http://www.tyan.com/support_download_utility.aspx?model=s.s2466 Finally, can you confirm that "sensors -s" is running (without error) some time during system startup, w/ both kernel versions? Thanks & regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bad temperature values from w83781d in 2.6.22
Hi Joerg: (I tried to follow-up using the gmane.org mail/news gateway... didn't seem to work.) * Joerg Sommrey [EMAIL PROTECTED] [2007-08-05 12:26:04 +0200]: Hi, after upgrading from 2.6.21 to 2.6.22 the CPU temperatures shown by w83781d look unreal. They were in a range from 40°C when idle to 75°C under full load with 2.6.21. The values shown now are in a very small range from 77°C to 82°C. From the (low) noise of the fan I can tell that the temperature is 50°C. The third temperature shown is completely wrong. I have a Tyan Tiger MPX board with a w83782d chip. Output from sensors: w83782d-i2c-0-2d Adapter: SMBus AMD768 adapter at 80e0 +5 V: +4.81 V (min = +4.76 V, max = +5.24 V) 3 VSB: +3.30 V (min = +2.85 V, max = +3.15 V) ALARM chs3 Fan: 2122 RPM (min = 2657 RPM, div = 4) ALARM VRM2 Temp: -208°C (high = -176°C, hyst = -181°C) sensor = transistor CPU1 Temp: +78.5°C (high = +80°C, hyst = +75°C) sensor = transistor ALARM CPU2 Temp: +77.5°C (high = +80°C, hyst = +75°C) sensor = transistor ALARM alarms: beep_enable: Sound alarm enabled # cat /sys/bus/i2c/devices/0-002d/temp*_input -209000 77500 77500 Any ideas? Please run the following commands as root (against both kernel versions) and reply-to-all with the results: # modprobe i2c-dev # i2cdump -y 0 0x2d b 0 0x4e # i2cdump -y 0 0x48 # i2cdump -y 0 0x49 Also, can you confirm that you're using the sensors.conf from here: http://www.tyan.com/support_download_utility.aspx?model=s.s2466 Finally, can you confirm that sensors -s is running (without error) some time during system startup, w/ both kernel versions? Thanks regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1 regression: hwmon/w83627ehf: wrong fan speed
Hi Stefan:
* Stefan Richter <[EMAIL PROTECTED]> [2007-08-05 13:20:48 +0200]:
> Now that I booted from 2.6.22-rc5 to 2.6.23-rc2 I noticed that ksensors
> displayed 1/16 of the actual speed of the CPU fan (correct is ca. 1400
> RPM under light load) and 0 for the case fan (correct is ca. 480 RPM
> under light load).
>
> I reverted patch
> hwmon/w83627ehf: No need to initialize fan_min
> and the behaviour changed as follows: ksensors displays the correct CPU
> fan speed when loaded for the first time after the w83627ehf was loaded,
> then drops to 1/16th the next time it refreshes the display. (I
> configured 30s update interval in ksensors.) But the case fan's speed
> is now correctly displayed all the time. Ksensors' fan speed
> multipliers are configured as 1.
>
> I then also reverted
> hwmon/w83627ehf: Be quiet when no chip is found
> hwmon/w83627ehf: Export the thermal sensor types
> hwmon/w83627ehf: Enable VBAT monitoring
> hwmon/w83627ehf: Add support for the VID inputs
> hwmon/w83627ehf: Fix timing issues
> hwmon/w83627ehf: Add error messages for two error cases
> one after another but it didn't change anything. More surprisingly, if
> I put all patches including "No need to initialize fan_min" back in, the
> behaviour remains like after referting that single patch, i.e. wrong CPU
> fan speed after first display update, correct case fan speed. I didn't
> reboot between tests though, I only unloaded and reloaded w83627ehf.
>
> I wasn't able to revert
> hwmon/w83627ehf: Convert to a platform driver
> to something that compiles but I didn't try very hard.
>
> Kernel messages when I load the drivers:
> w83627ehf: unsupported chip ID: 0x
> w83627ehf: Found W83627EHG chip at 0x290
> The former message is normally suppressed by patch "Be quiet when no
> chip is found". Mainboard is an MSI 945GT Speedster-A4R, userland is
> Gentoo's lm_sensors-2.10.1 and ksensors-0.7.3.
>
> Booting back into 2.6.22-rc5 (which seems identical with 2.6.22 as far
> as w83627ehf is concerned) brings back the correct fan speeds.
Does this patch (against v2.6.23-rc2) fix it?
commit f15c50e703c14ff7d72c3cb34e8e55417476a290
Author: Mark M. Hoffman <[EMAIL PROTECTED]>
Date: Sun Aug 5 12:19:01 2007 -0400
hwmon: read fan_div values during probe
This patch forces the driver to read the fan divider values during early
init.
Otherwise, a call to store_fan_min() could access uninitialized variables.
Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]>
diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index c51ae2e..bca7fbc 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -421,6 +421,31 @@ static void w83627ehf_write_fan_div(struct w83627ehf_data
*data, int nr)
}
}
+static void w83627ehf_update_fan_div(struct w83627ehf_data *data)
+{
+ int i;
+
+ i = w83627ehf_read_value(data, W83627EHF_REG_FANDIV1);
+ data->fan_div[0] = (i >> 4) & 0x03;
+ data->fan_div[1] = (i >> 6) & 0x03;
+ i = w83627ehf_read_value(data, W83627EHF_REG_FANDIV2);
+ data->fan_div[2] = (i >> 6) & 0x03;
+ i = w83627ehf_read_value(data, W83627EHF_REG_VBAT);
+ data->fan_div[0] |= (i >> 3) & 0x04;
+ data->fan_div[1] |= (i >> 4) & 0x04;
+ data->fan_div[2] |= (i >> 5) & 0x04;
+ if (data->has_fan & ((1 << 3) | (1 << 4))) {
+ i = w83627ehf_read_value(data, W83627EHF_REG_DIODE);
+ data->fan_div[3] = i & 0x03;
+ data->fan_div[4] = ((i >> 2) & 0x03)
+| ((i >> 5) & 0x04);
+ }
+ if (data->has_fan & (1 << 3)) {
+ i = w83627ehf_read_value(data, W83627EHF_REG_SMI_OVT);
+ data->fan_div[3] |= (i >> 5) & 0x04;
+ }
+}
+
static struct w83627ehf_data *w83627ehf_update_device(struct device *dev)
{
struct w83627ehf_data *data = dev_get_drvdata(dev);
@@ -432,25 +457,7 @@ static struct w83627ehf_data
*w83627ehf_update_device(struct device *dev)
if (time_after(jiffies, data->last_updated + HZ + HZ/2)
|| !data->valid) {
/* Fan clock dividers */
- i = w83627ehf_read_value(data, W83627EHF_REG_FANDIV1);
- data->fan_div[0] = (i >> 4) & 0x03;
- data->fan_div[1] = (i >> 6) & 0x03;
- i = w83627ehf_read_value(data, W83627EHF_REG_FANDIV2);
- data->fan_div[2] = (i >> 6) & 0x03;
- i = w83627ehf_read_value(data, W83627EHF_REG_VBAT);
- data->fan_div[0] |= (i >> 3)
Re: 2.6.23-rc1 regression: hwmon/w83627ehf: wrong fan speed
Hi Stefan: * Stefan Richter <[EMAIL PROTECTED]> [2007-08-05 16:51:07 +0200]: > Mark M. Hoffman wrote: > > It's more likely the patch before that: > > > > hwmon/w83627ehf: Preserve speed reading when changing fan min > > I reverted this patch alone and rebooted, still the same problem. > After reboot: >0 RPM for case fan, >correct CPU fan speed, drops to 1/16 after kmsensors' first refresh > After unloading and reloading the driver: >correct speed of case fan, >correct CPU fan speed, drops to 1/16 after kmsensors' first refresh OK, thanks for trying that. I'll keep looking here. > > I'll reexamine the patch series here. If you have time, it would help if > > you > > could do a git bisect. Use this command: > > > > $ git bisect start v2.6.23-rc2 v2.6.22-rc5 drivers/hwmon/w83627ehf.c > > > > Doing it this way will force you to reboot between tests; I think we would > > need that anyway. > > I'll try to reserve the time for that on some evening next week. > Thanks, There are a total of 9 patches between v2.6.22-rc5 and v2.6.23-rc2, so the bisection shouldn't take long. Also, please enable HWMON_DEBUG when you do this, and send the resulting syslog messages. Thanks. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1 regression: hwmon/w83627ehf: wrong fan speed
Hi Stefan: * Stefan Richter <[EMAIL PROTECTED]> [2007-08-05 13:20:48 +0200]: > Now that I booted from 2.6.22-rc5 to 2.6.23-rc2 I noticed that ksensors > displayed 1/16 of the actual speed of the CPU fan (correct is ca. 1400 > RPM under light load) and 0 for the case fan (correct is ca. 480 RPM > under light load). > > I reverted patch > hwmon/w83627ehf: No need to initialize fan_min > and the behaviour changed as follows: ksensors displays the correct CPU > fan speed when loaded for the first time after the w83627ehf was loaded, > then drops to 1/16th the next time it refreshes the display. (I > configured 30s update interval in ksensors.) But the case fan's speed > is now correctly displayed all the time. Ksensors' fan speed > multipliers are configured as 1. > > I then also reverted > hwmon/w83627ehf: Be quiet when no chip is found > hwmon/w83627ehf: Export the thermal sensor types > hwmon/w83627ehf: Enable VBAT monitoring > hwmon/w83627ehf: Add support for the VID inputs > hwmon/w83627ehf: Fix timing issues > hwmon/w83627ehf: Add error messages for two error cases > one after another but it didn't change anything. More surprisingly, if > I put all patches including "No need to initialize fan_min" back in, the > behaviour remains like after referting that single patch, i.e. wrong CPU > fan speed after first display update, correct case fan speed. I didn't > reboot between tests though, I only unloaded and reloaded w83627ehf. It's not always sufficient to just reload the driver, especially when it's an initialization problem as yours seems to be. So what you're seeing there is not too surprising. > I wasn't able to revert > hwmon/w83627ehf: Convert to a platform driver > to something that compiles but I didn't try very hard. That's because a later patch removes the i2c-isa support on which this driver depends, prior to this patch. If you can use git to back up, that would be easier. That said, I doubt the "Convert to a platform driver" is the problem. It's more likely the patch before that: hwmon/w83627ehf: Preserve speed reading when changing fan min I'll reexamine the patch series here. If you have time, it would help if you could do a git bisect. Use this command: $ git bisect start v2.6.23-rc2 v2.6.22-rc5 drivers/hwmon/w83627ehf.c Doing it this way will force you to reboot between tests; I think we would need that anyway. > Kernel messages when I load the drivers: > w83627ehf: unsupported chip ID: 0x > w83627ehf: Found W83627EHG chip at 0x290 > The former message is normally suppressed by patch "Be quiet when no > chip is found". Mainboard is an MSI 945GT Speedster-A4R, userland is > Gentoo's lm_sensors-2.10.1 and ksensors-0.7.3. > > Booting back into 2.6.22-rc5 (which seems identical with 2.6.22 as far > as w83627ehf is concerned) brings back the correct fan speeds. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1 regression: hwmon/w83627ehf: wrong fan speed
Hi Stefan: * Stefan Richter [EMAIL PROTECTED] [2007-08-05 16:51:07 +0200]: Mark M. Hoffman wrote: It's more likely the patch before that: hwmon/w83627ehf: Preserve speed reading when changing fan min I reverted this patch alone and rebooted, still the same problem. After reboot: 0 RPM for case fan, correct CPU fan speed, drops to 1/16 after kmsensors' first refresh After unloading and reloading the driver: correct speed of case fan, correct CPU fan speed, drops to 1/16 after kmsensors' first refresh OK, thanks for trying that. I'll keep looking here. I'll reexamine the patch series here. If you have time, it would help if you could do a git bisect. Use this command: $ git bisect start v2.6.23-rc2 v2.6.22-rc5 drivers/hwmon/w83627ehf.c Doing it this way will force you to reboot between tests; I think we would need that anyway. I'll try to reserve the time for that on some evening next week. Thanks, There are a total of 9 patches between v2.6.22-rc5 and v2.6.23-rc2, so the bisection shouldn't take long. Also, please enable HWMON_DEBUG when you do this, and send the resulting syslog messages. Thanks. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1 regression: hwmon/w83627ehf: wrong fan speed
Hi Stefan:
* Stefan Richter [EMAIL PROTECTED] [2007-08-05 13:20:48 +0200]:
Now that I booted from 2.6.22-rc5 to 2.6.23-rc2 I noticed that ksensors
displayed 1/16 of the actual speed of the CPU fan (correct is ca. 1400
RPM under light load) and 0 for the case fan (correct is ca. 480 RPM
under light load).
I reverted patch
hwmon/w83627ehf: No need to initialize fan_min
and the behaviour changed as follows: ksensors displays the correct CPU
fan speed when loaded for the first time after the w83627ehf was loaded,
then drops to 1/16th the next time it refreshes the display. (I
configured 30s update interval in ksensors.) But the case fan's speed
is now correctly displayed all the time. Ksensors' fan speed
multipliers are configured as 1.
I then also reverted
hwmon/w83627ehf: Be quiet when no chip is found
hwmon/w83627ehf: Export the thermal sensor types
hwmon/w83627ehf: Enable VBAT monitoring
hwmon/w83627ehf: Add support for the VID inputs
hwmon/w83627ehf: Fix timing issues
hwmon/w83627ehf: Add error messages for two error cases
one after another but it didn't change anything. More surprisingly, if
I put all patches including No need to initialize fan_min back in, the
behaviour remains like after referting that single patch, i.e. wrong CPU
fan speed after first display update, correct case fan speed. I didn't
reboot between tests though, I only unloaded and reloaded w83627ehf.
I wasn't able to revert
hwmon/w83627ehf: Convert to a platform driver
to something that compiles but I didn't try very hard.
Kernel messages when I load the drivers:
w83627ehf: unsupported chip ID: 0x
w83627ehf: Found W83627EHG chip at 0x290
The former message is normally suppressed by patch Be quiet when no
chip is found. Mainboard is an MSI 945GT Speedster-A4R, userland is
Gentoo's lm_sensors-2.10.1 and ksensors-0.7.3.
Booting back into 2.6.22-rc5 (which seems identical with 2.6.22 as far
as w83627ehf is concerned) brings back the correct fan speeds.
Does this patch (against v2.6.23-rc2) fix it?
commit f15c50e703c14ff7d72c3cb34e8e55417476a290
Author: Mark M. Hoffman [EMAIL PROTECTED]
Date: Sun Aug 5 12:19:01 2007 -0400
hwmon: read fan_div values during probe
This patch forces the driver to read the fan divider values during early
init.
Otherwise, a call to store_fan_min() could access uninitialized variables.
Signed-off-by: Mark M. Hoffman [EMAIL PROTECTED]
diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index c51ae2e..bca7fbc 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -421,6 +421,31 @@ static void w83627ehf_write_fan_div(struct w83627ehf_data
*data, int nr)
}
}
+static void w83627ehf_update_fan_div(struct w83627ehf_data *data)
+{
+ int i;
+
+ i = w83627ehf_read_value(data, W83627EHF_REG_FANDIV1);
+ data-fan_div[0] = (i 4) 0x03;
+ data-fan_div[1] = (i 6) 0x03;
+ i = w83627ehf_read_value(data, W83627EHF_REG_FANDIV2);
+ data-fan_div[2] = (i 6) 0x03;
+ i = w83627ehf_read_value(data, W83627EHF_REG_VBAT);
+ data-fan_div[0] |= (i 3) 0x04;
+ data-fan_div[1] |= (i 4) 0x04;
+ data-fan_div[2] |= (i 5) 0x04;
+ if (data-has_fan ((1 3) | (1 4))) {
+ i = w83627ehf_read_value(data, W83627EHF_REG_DIODE);
+ data-fan_div[3] = i 0x03;
+ data-fan_div[4] = ((i 2) 0x03)
+| ((i 5) 0x04);
+ }
+ if (data-has_fan (1 3)) {
+ i = w83627ehf_read_value(data, W83627EHF_REG_SMI_OVT);
+ data-fan_div[3] |= (i 5) 0x04;
+ }
+}
+
static struct w83627ehf_data *w83627ehf_update_device(struct device *dev)
{
struct w83627ehf_data *data = dev_get_drvdata(dev);
@@ -432,25 +457,7 @@ static struct w83627ehf_data
*w83627ehf_update_device(struct device *dev)
if (time_after(jiffies, data-last_updated + HZ + HZ/2)
|| !data-valid) {
/* Fan clock dividers */
- i = w83627ehf_read_value(data, W83627EHF_REG_FANDIV1);
- data-fan_div[0] = (i 4) 0x03;
- data-fan_div[1] = (i 6) 0x03;
- i = w83627ehf_read_value(data, W83627EHF_REG_FANDIV2);
- data-fan_div[2] = (i 6) 0x03;
- i = w83627ehf_read_value(data, W83627EHF_REG_VBAT);
- data-fan_div[0] |= (i 3) 0x04;
- data-fan_div[1] |= (i 4) 0x04;
- data-fan_div[2] |= (i 5) 0x04;
- if (data-has_fan ((1 3) | (1 4))) {
- i = w83627ehf_read_value(data, W83627EHF_REG_DIODE);
- data-fan_div[3] = i 0x03;
- data-fan_div[4] = ((i 2) 0x03)
-| ((i 5) 0x04);
- }
- if (data-has_fan (1 3)) {
- i
Re: 2.6.23-rc1 regression: hwmon/w83627ehf: wrong fan speed
Hi Stefan: * Stefan Richter [EMAIL PROTECTED] [2007-08-05 13:20:48 +0200]: Now that I booted from 2.6.22-rc5 to 2.6.23-rc2 I noticed that ksensors displayed 1/16 of the actual speed of the CPU fan (correct is ca. 1400 RPM under light load) and 0 for the case fan (correct is ca. 480 RPM under light load). I reverted patch hwmon/w83627ehf: No need to initialize fan_min and the behaviour changed as follows: ksensors displays the correct CPU fan speed when loaded for the first time after the w83627ehf was loaded, then drops to 1/16th the next time it refreshes the display. (I configured 30s update interval in ksensors.) But the case fan's speed is now correctly displayed all the time. Ksensors' fan speed multipliers are configured as 1. I then also reverted hwmon/w83627ehf: Be quiet when no chip is found hwmon/w83627ehf: Export the thermal sensor types hwmon/w83627ehf: Enable VBAT monitoring hwmon/w83627ehf: Add support for the VID inputs hwmon/w83627ehf: Fix timing issues hwmon/w83627ehf: Add error messages for two error cases one after another but it didn't change anything. More surprisingly, if I put all patches including No need to initialize fan_min back in, the behaviour remains like after referting that single patch, i.e. wrong CPU fan speed after first display update, correct case fan speed. I didn't reboot between tests though, I only unloaded and reloaded w83627ehf. It's not always sufficient to just reload the driver, especially when it's an initialization problem as yours seems to be. So what you're seeing there is not too surprising. I wasn't able to revert hwmon/w83627ehf: Convert to a platform driver to something that compiles but I didn't try very hard. That's because a later patch removes the i2c-isa support on which this driver depends, prior to this patch. If you can use git to back up, that would be easier. That said, I doubt the Convert to a platform driver is the problem. It's more likely the patch before that: hwmon/w83627ehf: Preserve speed reading when changing fan min I'll reexamine the patch series here. If you have time, it would help if you could do a git bisect. Use this command: $ git bisect start v2.6.23-rc2 v2.6.22-rc5 drivers/hwmon/w83627ehf.c Doing it this way will force you to reboot between tests; I think we would need that anyway. Kernel messages when I load the drivers: w83627ehf: unsupported chip ID: 0x w83627ehf: Found W83627EHG chip at 0x290 The former message is normally suppressed by patch Be quiet when no chip is found. Mainboard is an MSI 945GT Speedster-A4R, userland is Gentoo's lm_sensors-2.10.1 and ksensors-0.7.3. Booting back into 2.6.22-rc5 (which seems identical with 2.6.22 as far as w83627ehf is concerned) brings back the correct fan speeds. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates against ~v2.6.23-rc1-git8
Hi Linus: Please pull from: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release You'll get a handful of cleanups and bugfixes (including a couple that fix regressions since 2.6.22). The Macbook gets some additional sensors, and there's also one brand new driver, which has spent some time in the latest -mm. This patch series was also posted to the lm-sensors list yesterday: http://lists.lm-sensors.org/pipermail/lm-sensors/2007-July/020730.html Thanks & regards, Documentation/hwmon/adm1031 |4 +- Documentation/hwmon/thmc50 | 74 +++ drivers/hwmon/Kconfig| 10 + drivers/hwmon/Makefile |1 + drivers/hwmon/abituguru3.c |5 +- drivers/hwmon/ams/ams-core.c |1 - drivers/hwmon/applesmc.c | 14 +- drivers/hwmon/dme1737.c |2 +- drivers/hwmon/fscher.c |4 +- drivers/hwmon/it87.c |2 +- drivers/hwmon/lm78.c |2 +- drivers/hwmon/lm90.c |2 +- drivers/hwmon/lm93.c |2 +- drivers/hwmon/pc87360.c |2 +- drivers/hwmon/sis5595.c |2 +- drivers/hwmon/smsc47m1.c |2 +- drivers/hwmon/thmc50.c | 440 ++ drivers/hwmon/via686a.c |2 +- drivers/hwmon/vt8231.c |4 +- drivers/hwmon/w83627hf.c |2 +- 20 files changed, 554 insertions(+), 23 deletions(-) create mode 100644 Documentation/hwmon/thmc50 create mode 100644 drivers/hwmon/thmc50.c Adrian Bunk (1): hwmon: make abituguru3_read_increment_offset() static Guillaume Chazarain (1): hwmon: Fix regression caused by typo in lm90.c Hans de Goede (3): hwmon: fix lm78 detection regression hwmon: fscher control update bugfix hwmon: fscher read control bugfix Hans-Jürgen Koch (1): hwmon: fix array overruns in lm93.c Jean Delvare (2): hwmon: Add missing __devexit tags in various drivers hwmon: (adm1031) Fix broken links in documentation Jesper Juhl (1): hwmon: clean up duplicate includes Juerg Haefliger (1): hwmon: fix dme1737 temp fault attribute Krzysztof Helt (1): hwmon: add support for THMC50 and ADM1022 Martin Szulecki (1): hwmon: (applesmc) add temperature sensors set for Macbook -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] hwmon updates against ~v2.6.23-rc1-git8
Hi Linus: Please pull from: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release You'll get a handful of cleanups and bugfixes (including a couple that fix regressions since 2.6.22). The Macbook gets some additional sensors, and there's also one brand new driver, which has spent some time in the latest -mm. This patch series was also posted to the lm-sensors list yesterday: http://lists.lm-sensors.org/pipermail/lm-sensors/2007-July/020730.html Thanks regards, Documentation/hwmon/adm1031 |4 +- Documentation/hwmon/thmc50 | 74 +++ drivers/hwmon/Kconfig| 10 + drivers/hwmon/Makefile |1 + drivers/hwmon/abituguru3.c |5 +- drivers/hwmon/ams/ams-core.c |1 - drivers/hwmon/applesmc.c | 14 +- drivers/hwmon/dme1737.c |2 +- drivers/hwmon/fscher.c |4 +- drivers/hwmon/it87.c |2 +- drivers/hwmon/lm78.c |2 +- drivers/hwmon/lm90.c |2 +- drivers/hwmon/lm93.c |2 +- drivers/hwmon/pc87360.c |2 +- drivers/hwmon/sis5595.c |2 +- drivers/hwmon/smsc47m1.c |2 +- drivers/hwmon/thmc50.c | 440 ++ drivers/hwmon/via686a.c |2 +- drivers/hwmon/vt8231.c |4 +- drivers/hwmon/w83627hf.c |2 +- 20 files changed, 554 insertions(+), 23 deletions(-) create mode 100644 Documentation/hwmon/thmc50 create mode 100644 drivers/hwmon/thmc50.c Adrian Bunk (1): hwmon: make abituguru3_read_increment_offset() static Guillaume Chazarain (1): hwmon: Fix regression caused by typo in lm90.c Hans de Goede (3): hwmon: fix lm78 detection regression hwmon: fscher control update bugfix hwmon: fscher read control bugfix Hans-Jürgen Koch (1): hwmon: fix array overruns in lm93.c Jean Delvare (2): hwmon: Add missing __devexit tags in various drivers hwmon: (adm1031) Fix broken links in documentation Jesper Juhl (1): hwmon: clean up duplicate includes Juerg Haefliger (1): hwmon: fix dme1737 temp fault attribute Krzysztof Helt (1): hwmon: add support for THMC50 and ADM1022 Martin Szulecki (1): hwmon: (applesmc) add temperature sensors set for Macbook -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [2.6 patch] make abituguru3_read_increment_offset() static
Hi:
* Hans de Goede <[EMAIL PROTECTED]> [2007-07-29 18:08:46 +0200]:
> Adrian Bunk wrote:
> >abituguru3_read_increment_offset() can become static.
> >
> >Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> Looks good, good catch.
>
> Acked-by: Hans de Goede <[EMAIL PROTECTED]>
>
> >
> >---
> >--- linux-2.6.23-rc1-mm1/drivers/hwmon/abituguru3.c.old 2007-07-26
> >08:56:33.0 +0200
> >+++ linux-2.6.23-rc1-mm1/drivers/hwmon/abituguru3.c 2007-07-26
> >08:57:00.0 +0200
> >@@ -691,8 +691,9 @@
> >
> > /* Sensor settings are stored 1 byte per offset with the bytes
> >placed add consecutive offsets. */
> >-int abituguru3_read_increment_offset(struct abituguru3_data *data, u8
> >bank,
> >-u8 offset, u8 count, u8 *buf, int offset_count)
> >+static int abituguru3_read_increment_offset(struct abituguru3_data *data,
> >+u8 bank, u8 offset, u8 count,
> >+ u8 *buf, int offset_count)
> > {
> > int i, x;
> >
> >
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix regression caused by typo in lm90.c
Hi:
> On 7/26/2007, "Guillaume Chazarain" <[EMAIL PROTECTED]> wrote:
> >diff -r 4cad6fced1a8 drivers/hwmon/lm90.c
> >--- a/drivers/hwmon/lm90.c Thu Jul 26 13:44:58 2007 -0700
> >+++ b/drivers/hwmon/lm90.c Tue Jul 24 00:02:52 2007 +0200
> >@@ -585,7 +585,7 @@ static int lm90_detect(struct i2c_adapte
> > * those of the man_id register.
> > */
> > if (chip_id == man_id
> >- && (address == 0x4F || address == 0x4D)
> >+ && (address == 0x4C || address == 0x4D)
> > && (reg_config1 & 0x1F) == (man_id & 0x0F)
> > && reg_convrate <= 0x09) {
> > kind = max6657;
* Jean Delvare <[EMAIL PROTECTED]> [2007-07-27 10:07:45 +0200]:
> Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix regression caused by typo in lm90.c
Hi:
On 7/26/2007, Guillaume Chazarain [EMAIL PROTECTED] wrote:
diff -r 4cad6fced1a8 drivers/hwmon/lm90.c
--- a/drivers/hwmon/lm90.c Thu Jul 26 13:44:58 2007 -0700
+++ b/drivers/hwmon/lm90.c Tue Jul 24 00:02:52 2007 +0200
@@ -585,7 +585,7 @@ static int lm90_detect(struct i2c_adapte
* those of the man_id register.
*/
if (chip_id == man_id
- (address == 0x4F || address == 0x4D)
+ (address == 0x4C || address == 0x4D)
(reg_config1 0x1F) == (man_id 0x0F)
reg_convrate = 0x09) {
kind = max6657;
* Jean Delvare [EMAIL PROTECTED] [2007-07-27 10:07:45 +0200]:
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [2.6 patch] make abituguru3_read_increment_offset() static
Hi:
* Hans de Goede [EMAIL PROTECTED] [2007-07-29 18:08:46 +0200]:
Adrian Bunk wrote:
abituguru3_read_increment_offset() can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Looks good, good catch.
Acked-by: Hans de Goede [EMAIL PROTECTED]
---
--- linux-2.6.23-rc1-mm1/drivers/hwmon/abituguru3.c.old 2007-07-26
08:56:33.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/hwmon/abituguru3.c 2007-07-26
08:57:00.0 +0200
@@ -691,8 +691,9 @@
/* Sensor settings are stored 1 byte per offset with the bytes
placed add consecutive offsets. */
-int abituguru3_read_increment_offset(struct abituguru3_data *data, u8
bank,
-u8 offset, u8 count, u8 *buf, int offset_count)
+static int abituguru3_read_increment_offset(struct abituguru3_data *data,
+u8 bank, u8 offset, u8 count,
+u8 *buf, int offset_count)
{
int i, x;
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hwmon: Add missing __devexit tags in various drivers
8231_data *data = platform_get_drvdata(pdev);
> int i;
> --- linux-2.6.23-pre.orig/drivers/hwmon/w83627hf.c2007-07-22
> 11:51:49.0 +0200
> +++ linux-2.6.23-pre/drivers/hwmon/w83627hf.c 2007-07-22 11:56:48.0
> +0200
> @@ -384,7 +384,7 @@ struct w83627hf_sio_data {
>
>
> static int w83627hf_probe(struct platform_device *pdev);
> -static int w83627hf_remove(struct platform_device *pdev);
> +static int __devexit w83627hf_remove(struct platform_device *pdev);
>
> static int w83627hf_read_value(struct w83627hf_data *data, u16 reg);
> static int w83627hf_write_value(struct w83627hf_data *data, u16 reg, u16
> value);
>
>
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][07/37] Clean up duplicate includes in drivers/hwmon/
Hi Jesper: * Jesper Juhl <[EMAIL PROTECTED]> [2007-07-21 17:02:01 +0200]: > Hi, > > This patch cleans up duplicate includes in > drivers/hwmon/ > > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> > --- > > diff --git a/drivers/hwmon/ams/ams-core.c b/drivers/hwmon/ams/ams-core.c > index 6db9737..a112a03 100644 > --- a/drivers/hwmon/ams/ams-core.c > +++ b/drivers/hwmon/ams/ams-core.c > @@ -23,7 +23,6 @@ > #include > #include > #include > -#include > #include > #include > Applied to hwmon-2.6.git/testing, thanks. -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drivers/hwmon/lm93.c: array overruns
* Hans-Jürgen Koch <[EMAIL PROTECTED]> [2007-07-23 09:36:57 +0200]:
> Am Montag 23 Juli 2007 02:54 schrieb Adrian Bunk:
> > The Coverity checker spotted the following array overruns
> > in drivers/hwmon/lm93.c:
> >
> > <-- snip -->
> >
> > ...
> > struct lm93_data {
> > ...
> > struct {
> > u8 min;
> > u8 max;
> > } temp_lim[3];
> > ...
> > };
> > ...
> > static void lm93_update_client_common(struct lm93_data *data,
> > struct i2c_client *client)
> > {
> > ...
> > for (i = 0; i < 4; i++) {
> > data->temp_lim[i].min =
> > lm93_read_byte(client, LM93_REG_TEMP_MIN(i));
> > data->temp_lim[i].max =
> > lm93_read_byte(client, LM93_REG_TEMP_MAX(i));
> > }
> > ...
> >
> > <-- snip -->
>
> This patch should fix it. Thanks a lot, Adrian!
>
>
> This fixes an array overflow bug. We have 4 pairs of min/max temperature
> limits, not 3.
>
> Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]>
>
> --
> Index: linux-2.6.23-rc/drivers/hwmon/lm93.c
> ===
> --- linux-2.6.23-rc.orig/drivers/hwmon/lm93.c 2007-07-23 09:22:56.0
> +0200
> +++ linux-2.6.23-rc/drivers/hwmon/lm93.c 2007-07-23 09:29:37.0
> +0200
> @@ -234,7 +234,7 @@
> struct {
> u8 min;
> u8 max;
> - } temp_lim[3];
> + } temp_lim[4];
>
> /* vin1 - vin16: low and high limits */
> struct {
>
>
Applied to testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drivers/hwmon/lm93.c: array overruns
* Hans-Jürgen Koch [EMAIL PROTECTED] [2007-07-23 09:36:57 +0200]:
Am Montag 23 Juli 2007 02:54 schrieb Adrian Bunk:
The Coverity checker spotted the following array overruns
in drivers/hwmon/lm93.c:
-- snip --
...
struct lm93_data {
...
struct {
u8 min;
u8 max;
} temp_lim[3];
...
};
...
static void lm93_update_client_common(struct lm93_data *data,
struct i2c_client *client)
{
...
for (i = 0; i 4; i++) {
data-temp_lim[i].min =
lm93_read_byte(client, LM93_REG_TEMP_MIN(i));
data-temp_lim[i].max =
lm93_read_byte(client, LM93_REG_TEMP_MAX(i));
}
...
-- snip --
This patch should fix it. Thanks a lot, Adrian!
This fixes an array overflow bug. We have 4 pairs of min/max temperature
limits, not 3.
Signed-off-by: Hans J. Koch [EMAIL PROTECTED]
--
Index: linux-2.6.23-rc/drivers/hwmon/lm93.c
===
--- linux-2.6.23-rc.orig/drivers/hwmon/lm93.c 2007-07-23 09:22:56.0
+0200
+++ linux-2.6.23-rc/drivers/hwmon/lm93.c 2007-07-23 09:29:37.0
+0200
@@ -234,7 +234,7 @@
struct {
u8 min;
u8 max;
- } temp_lim[3];
+ } temp_lim[4];
/* vin1 - vin16: low and high limits */
struct {
Applied to testing, thanks.
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
