[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] 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: 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(&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: [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
> &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/
[GIT PATCH] hwmon updates against v2.6.24 (~git17)
ps hwmon: (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/
[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,
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] 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/
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
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: [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 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: [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(&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: [PATCH v3] i5k_amb: New memory temperature sensor driver
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;
> + }
> +
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, &val16))
> + goto out;
> + data->amb_present[which * 2] = val16;
> +
> + if (pci_read_config_word(pcidev, I5K_REG_CHAN1_PRESENCE_ADDR, &val16))
> + 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(&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 0x259
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
ebugging messages 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: [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
t; + return;
> + }
> +
> + data->address.addr_type = IPMI_SYSTEM_INTERFACE_ADDR_TYPE;
> + data->address.channel = IPMI_BMC_CHANNEL;
> + data->address.data[0] = 0;
> + data->interface = iface;
> + data->bmc_device = dev;
> +
> + /* Create IPMI messaging interface user */
> + err = ipmi_create_user(data->interface, &driver_data.ipmi_hndlrs,
> +data, &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(&data->lock);
> +
> + /* Initialize message */
> + data->tx_msgid = 0;
> + init_completion(&data->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(&data->list, &driver_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,
> +&sensor_dev_attr_reset_high_low.dev_attr);
> + device_remove_file(data->bmc_device, &sensor_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,
> + &data->sensors[i].attr[j].dev_attr);
> + kfree(data->sensors[i].attr[j].dev_attr.attr.name);
> + }
> +
> + list_del(&data->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(&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
BMC "
> +"interface %d.\n", data->interface);
> + return;
> + }
> +
> + data->address.addr_type = IPMI_SYSTEM_INTERFACE_ADDR_TYPE;
> + data->address.channel = IPMI_BMC_CHANNEL;
> + data->address.data[0] = 0;
> + data->interface = iface;
> + data->bmc_device = dev;
> +
> + /* Create IPMI messaging interface user */
> + err = ipmi_create_user(data->interface, &driver_data.ipmi_hndlrs,
> +data, &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(&data->lock);
> +
> + /* Initialize message */
> + data->tx_msgid = 0;
> + init_completion(&data->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(&data->list, &driver_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, &sensor_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,
> + &data->sensors[i].attr[j].dev_attr);
> + kfree(data->sensors[i].attr[j].dev_attr.attr.name);
> + }
> +
> + list_del(&data->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(&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/
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/
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/
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: 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);
- da
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/
[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] hwmon: Add missing __devexit tags in various drivers
latform_device *pdev)
> {
> struct vt8231_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/
[GIT PATCH] hwmon patches against 2.6.22
to a platform driver hwmon: Use platform_device_add_data() hwmon: Fault files naming convention hwmon/via686a: Temperature interrupt configuration fix hwmon/via686a: Convert to a platform driver hwmon/via686a: Use dynamic sysfs callbacks hwmon/sis5595: Convert to a platform driver hwmon/sis5595: Use dynamic sysfs callbacks hwmon/sis5595: Use PCI_REVISION_ID hwmon: Fix a potential race condition on unload hwmon/w83627ehf: Preserve speed reading when changing fan min hwmon/smsc47b397: Don't report missing fans as spinning at 82 RPM hwmon: Improve the pwmN_enable documentation hwmon/w83627ehf: Fix timing issues hwmon/w83627ehf: Add support for the VID inputs hwmon/w83627ehf: Enable VBAT monitoring hwmon/w83627ehf: Export the thermal sensor types hwmon/w83627ehf: No need to initialize fan_min hwmon/w83627ehf: Be quiet when no chip is found i2c: Delete the i2c-isa pseudo bus driver Juerg Haefliger (3): hwmon: New SMSC DME1737 driver hwmon/dme1737: Add documentation hwmon: add SCH5317 to smsc47b397 driver Mark M. Hoffman (1): hwmon: New maintainer Phil Endecott (1): hwmon/f71805f: Add temperature-tracking fan control mode Rainer Birkenmaier (1): hwmon/lm90: Add support for the Maxim MAX6680/MAX6681 Roger Lucas (1): hwmon: Convert vt8231 to a platform driver Rudolf Marek (1): hwmon/it87: Add IT8726F support corentin.labbe (1): hwmon: convert it87 to platform driver -- 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 coretemp_device_remove() static
Hi Jean, Adrian:
* Jean Delvare <[EMAIL PROTECTED]> [2007-07-07 21:22:28 +0200]:
> Hi Adrian,
>
> On Fri, 6 Jul 2007 01:23:06 +0200, Adrian Bunk wrote:
> > coretemp_device_remove() can become static.
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> Obviously correct.
>
> Acked-by: Jean Delvare <[EMAIL PROTECTED]>
>
> > ---
> > --- linux-2.6.22-rc6-mm1/drivers/hwmon/coretemp.c.old 2007-07-04
> > 20:46:05.0 +0200
> > +++ linux-2.6.22-rc6-mm1/drivers/hwmon/coretemp.c 2007-07-04
> > 20:46:20.0 +0200
> > @@ -318,7 +318,7 @@
> > }
> >
> > #ifdef CONFIG_HOTPLUG_CPU
> > -void coretemp_device_remove(unsigned int cpu)
> > +static void coretemp_device_remove(unsigned int cpu)
> > {
> > struct pdev_entry *p, *n;
> > mutex_lock(&pdev_list_mutex);
Applied to my testing tree; 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 3/5] use mutex instead of semaphore in SMSC LPC47M192 driver
Hi Matthias: * Matthias Kaehlcke <[EMAIL PROTECTED]> [2007-07-01 18:32:24 +0200]: > The SMSC LPC47M192 driver uses a semaphore as mutex. Use the mutex API > instead of the (binary) semaphore. > > Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]> Already in my testing tree[1] and therefore in latest -mm as well. [1] http://lm-sensors.org/kernel?p=kernel/mhoffman/hwmon-2.6.git;a=shortlog;h=testing 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/
New hwmon maintainer
Hi Andrew: I am maintaining a git tree for the hwmon subsystem now. You may pull from it here: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git testing The current contents include the remainder of Jean Delvare's quilt patch series, plus a single patch to MAINTAINERS. Once you start pulling from this git tree, Jean said he will delete his patch series entirely. BTW: None of these patches are needed before 2.6.23. Thanks & regards, PS: Thanks for your good work and help, Jean. -- 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] Hardware monitoring subsystem maintainer position is open
Hi Jean, et al: * Jean Delvare <[EMAIL PROTECTED]> [2007-04-10 15:02:27 +0200]: > I am resigning from my role as hardware monitoring subsystem > (drivers/hwmon) maintainer. This is too much work for me, I do not have > the necessary bandwidth to review all the incoming patches, in > particular new drivers, in a timely manner. Patch authors have been > complaining about this repeatedly. This is no fun for them, and even > less for me, so I'd rather let someone else with more spare time take > care of it. If there are volunteers, this is the right time to speak up. > > I will still be maintaining the individual hardware monitoring drivers > I am listed for in file MAINTAINERS (adm1025, f71805f, lm83 and lm90) > as well as the I2C subsystem. No change here. > > I will continue to feed -mm with pending hwmon patches until 2.6.21 > final is released, then I'll send everything I have to Linus for > 2.6.22-rc1, the last of which will be: > (...) /me throws hat in I volunteer to become the new MAINTAINER, but in a much more limited sense of the term than Jean is/was. I can take care of a couple git trees, and do some detailed reviews when I have time. For the most part, I will have to rely on others to do reviews as well. I would not be volunteering for this role, if Juerg and others had not also volunteered to be more active reviewers. As for the discussions later in this thread about process... IMHO that's a little premature. I intend to get brand new stuff into -mm perhaps a little earlier than Jean did... but it still ain't going to Linus before it's ready. Other than that, I would rather just see what works for me and for you (other hwmon authors). Assuming no one else wants the job (ruik?) I'll start working with Jean to get things set up as soon as I can. 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: [-mm patch] remove quirk_sis_96x_compatible()
Hi Adrian:
> On Sun, Jan 07, 2007 at 10:40:49AM -0500, Mark M. Hoffman wrote:
> > It's just cruft from the original quirk. The "compatible" printk could have
> > had value as a diagnostic in case the new quirk didn't work for some reason,
> > but I never saw any complaints about it (apart from the link order problem,
> > which is something different.) It's safe to remove by now.
* Adrian Bunk <[EMAIL PROTECTED]> [2007-01-14 14:46:32 +0100]:
> Below is a patch to remove it.
>
> Since 2.6.0-test10, all quirk_sis_96x_compatible() had any effect on
> was a printk().
>
> This patch therefore removes it.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Mark M. Hoffman <[EMAIL PROTECTED]>
> ---
>
> drivers/pci/quirks.c | 15 ---
> 1 file changed, 15 deletions(-)
>
> --- linux-2.6.20-rc4-mm1/drivers/pci/quirks.c.old 2007-01-14
> 09:58:01.0 +0100
> +++ linux-2.6.20-rc4-mm1/drivers/pci/quirks.c 2007-01-14 09:58:37.0
> +0100
> @@ -1141,8 +1141,6 @@
> *
> * We can also enable the sis96x bit in the discovery register..
> */
> -static int __devinitdata sis_96x_compatible = 0;
> -
> #define SIS_DETECT_REGISTER 0x40
>
> static void quirk_sis_503(struct pci_dev *dev)
> @@ -1158,9 +1156,6 @@
> return;
> }
>
> - /* Make people aware that we changed the config.. */
> - printk(KERN_WARNING "Uncovering SIS%x that hid as a SIS503
> (compatible=%d)\n", devid, sis_96x_compatible);
> -
> /*
>* Ok, it now shows up as a 96x.. run the 96x quirk by
>* hand in case it has already been processed.
> @@ -1172,16 +1167,6 @@
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_503,
> quirk_sis_503 );
> DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_503,
> quirk_sis_503 );
>
> -static void __init quirk_sis_96x_compatible(struct pci_dev *dev)
> -{
> - sis_96x_compatible = 1;
> -}
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_645,
> quirk_sis_96x_compatible );
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_646,
> quirk_sis_96x_compatible );
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_648,
> quirk_sis_96x_compatible );
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_650,
> quirk_sis_96x_compatible );
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_651,
> quirk_sis_96x_compatible );
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_735,
> quirk_sis_96x_compatible );
>
> /*
> * On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
--
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: [-mm patch] drivers/pci/quirks.c: cleanup
Hi Jean: > On Mon, 8 Jan 2007 22:02:26 -0500, Mark M. Hoffman wrote: > > 3) I've just confirmed that this quirk is still broken on recent FC6 > > kernels. > > Perhaps they should have picked my patch out of their bugzilla, but they > > didn't. * Jean Delvare <[EMAIL PROTECTED]> [2007-01-09 14:17:21 +0100]: > I am worried about the Intel/Asus SMBus quirk then, which affects many > more users than the SiS SMBus one, and would suffer from a reordering as > well. Intel/Asus users on FC[456] would surely have screamed if that was true. But I was curious so I looked deeper. There is a fundamental difference between the Intel SMBus quirks and the SiS SMBus quirk... Intel: 1) The first quirk keys off the host bridge, setting a flag. 2) The second quirk keys off the LPC, enabling the SMBus if the flag was set. SiS: 1) The first quirk keys off the *old* LPC ID... this causes the ID to change.[1] 2) The second quirk keys off the *new* LPC ID; this one enables the SMBus. In the SiS case, both quirks key off the *same* *device*, but with potentially different IDs. The quirk list ordering matters there because the list is scanned only once per device. For the Intel case, the only ordering that matters is that the host bridge device is added [pci_device_add()] before the LPC; AFAICT, that is reliable, perhaps even by definition. So I don't think you have to worry about the Intel SMBus quirks. [1] That's right, the first quirk actually changes the PCI device ID of the LPC. Unless it actually *is* older hardware... in which case the quirk just tickles a reserved bit that is ignored. Thank you SiS, that's just beautiful. 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/
[PATCH 2.6.20-rc4] i2c/pci: fix sis96x smbus quirk once and for all
The sis96x SMBus PCI device depends on two different quirks to run
in a specific order. Apart from being fragile, this was found to
actually break on (at least) recent FC4, FC5, and FC6 kernels. This
patch fixes the quirks so that they work without relying on the
compiler and/or linker to put them in any specific order.
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-April/015962.html
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189719
I tested this patch. Please apply.
Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]>
---
drivers/pci/quirks.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
--- linux-2.6.orig/drivers/pci/quirks.c
+++ linux-2.6/drivers/pci/quirks.c
@@ -1117,10 +1117,11 @@ DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_I
static void quirk_sis_96x_smbus(struct pci_dev *dev)
{
u8 val = 0;
- printk(KERN_INFO "Enabling SiS 96x SMBus.\n");
- pci_read_config_byte(dev, 0x77, &val);
- pci_write_config_byte(dev, 0x77, val & ~0x10);
pci_read_config_byte(dev, 0x77, &val);
+ if (val & 0x10) {
+ printk(KERN_INFO "Enabling SiS 96x SMBus.\n");
+ pci_write_config_byte(dev, 0x77, val & ~0x10);
+ }
}
/*
@@ -1152,11 +1153,12 @@ static void quirk_sis_503(struct pci_dev
printk(KERN_WARNING "Uncovering SIS%x that hid as a SIS503
(compatible=%d)\n", devid, sis_96x_compatible);
/*
-* Ok, it now shows up as a 96x.. The 96x quirks are after
-* the 503 quirk in the quirk table, so they'll automatically
-* run and enable things like the SMBus device
+* Ok, it now shows up as a 96x.. run the 96x quirk by
+* hand in case it has already been processed.
+* (depends on link order, which is apparently not guaranteed)
*/
dev->device = devid;
+ quirk_sis_96x_smbus(dev);
}
static void __init quirk_sis_96x_compatible(struct pci_dev *dev)
--
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: [-mm patch] drivers/pci/quirks.c: cleanup
Jean: * Jean Delvare <[EMAIL PROTECTED]> [2007-01-08 12:10:55 +0100]: > Hi Mark, > > On Sun, 7 Jan 2007 10:44:41 -0500, Mark M. Hoffman wrote: > > Hi Jean, Adrian: > > > > > On Tue, 19 Dec 2006 05:13:15 +0100, Adrian Bunk wrote: > > > > @@ -1122,6 +1123,14 @@ static void quirk_sis_96x_smbus(struct p > > > > pci_write_config_byte(dev, 0x77, val & ~0x10); > > > > pci_read_config_byte(dev, 0x77, &val); > > > > } > > > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_961, > > > > quirk_sis_96x_smbus ); > > > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_962, > > > > quirk_sis_96x_smbus ); > > > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_963, > > > > quirk_sis_96x_smbus ); > > > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_LPC, > > > > quirk_sis_96x_smbus ); > > > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_961, > > > > quirk_sis_96x_smbus ); > > > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_962, > > > > quirk_sis_96x_smbus ); > > > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_963, > > > > quirk_sis_96x_smbus ); > > > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_LPC, > > > > quirk_sis_96x_smbus ); > > > > > > > > /* > > > > * ... This is further complicated by the fact that some SiS96x south > > > > @@ -1158,6 +1167,8 @@ static void quirk_sis_503(struct pci_dev > > > > */ > > > > dev->device = devid; > > > > } > > > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_503, > > > > quirk_sis_503 ); > > > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_503, > > > > quirk_sis_503 ); > > > > * Jean Delvare <[EMAIL PROTECTED]> [2007-01-05 09:52:33 +0100]: > > > Was this patch tested on the SiS-based boards which need these quirks? > > > I think you broke them. If I remember correctly, quirk_sis_503() must > > > be called before quirk_sis_96x_smbus() for some boards to work > > > properly, and we currently rely on the linking order to guarantee that. > > > Likewise, quirk_sis_96x_compatible() should be called before > > > quirk_sis_503() otherwise the warning message in quirk_sis_503() will > > > no longer be correct. > > > > > > So if you want to put the calls right after the quirk functions, you > > > need to reorder the functions themselves as well. Feel free to add a > > > comment explaining the order requirement so that nobody breaks it > > > accidentally again in the future. > > > > It is fragile for this code to depend on link order; Adrian's obvious and > > trivial cleanups broke it. Not only that, but some FC kernels had/have the > > link order reversed such that this quirk is broken anyway. > > The former problem would be addressed just fine by a proper ordering > (as Adrian's patch was attempting to bring) and a comment explaining > the dependency. That's still fragile. Someone is bound to reorder the stupid things by mistake (again). I'm tired of screwing around with this quirk already. The patch that I sent last May would have fixed it permanently. And the funny part is that *you* suggested the fix. ;) > > I sent a patch for this back in May: > > http://lists.lm-sensors.org/pipermail/lm-sensors/2006-May/016113.html > > > > There was some discussion on the linux-pci mailing list as well; can't seem > > to > > find an archive of that though. Basically, it was not understood how the FC > > kernels could have a reversed link order. I never followed up on it, my > > bad. > > As long as it isn't explained, I call it a compiler bug in FC. 1) What standard specifies the link order of objects in a module? I have seen other compilers reorder objects this way. 2) So what if it was a compiler bug? I guess we don't allow patches to work around compiler bugs. 3) I've just confirmed that this quirk is still broken on recent FC6 kernels. Perhaps they should have picked my patch out of their bugzilla, but they didn't. > > At any rate, can we please get the patch above applied? I will send a new > > one > > if necessary. > > This is a PCI patch, so I'm not the one picking it. I seem to remember > Greg was fine with the patch except for the comment about the linking > order. I'll resend it shortly... 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: [-mm patch] drivers/pci/quirks.c: cleanup
Hi Jean, Adrian, et. al.:
* Jean Delvare <[EMAIL PROTECTED]> [2007-01-07 12:30:13 +0100]:
> Hi Adrian,
>
> On Sat, 6 Jan 2007 00:29:13 +0100, Adrian Bunk wrote:
> > While looking at the code, I also noted the following:
> >
> > quirk_sis_96x_compatible() is pretty useless since all it does is to set
> > a static variable that is only used in a printk().
> >
> > quirk_sis_96x_compatible() was added with:
> >
> >
> > 2003/05/13 13:48:50-07:00 mhoffman
> > [PATCH] i2c: Add SiS96x I2C/SMBus driver
> >
> > This patch adds support for the SMBus of SiS96x south
> > bridges. It is based on i2c-sis645.c from the lm sensors
> > project, which never made it into an official kernel and
> > was anyway mis-named.
> >
> > This driver works on my SiS 645/961 board vs w83781d.
> >
> >
> > It's usage in
> >
> >
> > static void __init quirk_sis_503_smbus(struct pci_dev *dev)
> > {
> >if (sis_96x_compatible)
> >quirk_sis_96x_smbus(dev);
> > }
> >
> >
> > Was removed in
> >
> >
> > Author: torvalds
> > Date: Thu Oct 30 19:03:38 2003 +
> >
> > Stop SIS 96x chips from lying about themselves.
> >
> > Some machines with the SIS 96x southbridge have it set up
> > to claim it is a SIS 503 chip. That breaks irq routing logic
> > among other things. Fix it properly by making everybody aware
> > of the duplicity.
> >
> >
> > Was this intentional (and quirk_sis_96x_compatible() should be removed),
> > or is this a bug that should be fixed?
>
> I noticed this too in April 2006, see:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2006-April/016016.html
>
> Quoting myself back then:
> "The whole sis_96x_compatible stuff looks superfluous now. It was used
> before 2.6.0-test10, but we could certainly get rid of it now."
>
> I do not think there is a bug here, or someone would have complained by
> now. Note though that I do not have a SiS-based motherboard to test on.
> Mark may be able to help with testing.
It's just cruft from the original quirk. The "compatible" printk could have
had value as a diagnostic in case the new quirk didn't work for some reason,
but I never saw any complaints about it (apart from the link order problem,
which is something different.) It's safe to remove by now.
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: [-mm patch] drivers/pci/quirks.c: cleanup
Hi Jean, Adrian: > On Tue, 19 Dec 2006 05:13:15 +0100, Adrian Bunk wrote: > > @@ -1122,6 +1123,14 @@ static void quirk_sis_96x_smbus(struct p > > pci_write_config_byte(dev, 0x77, val & ~0x10); > > pci_read_config_byte(dev, 0x77, &val); > > } > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_961, > > quirk_sis_96x_smbus ); > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_962, > > quirk_sis_96x_smbus ); > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_963, > > quirk_sis_96x_smbus ); > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_LPC, > > quirk_sis_96x_smbus ); > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_961, > > quirk_sis_96x_smbus ); > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_962, > > quirk_sis_96x_smbus ); > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_963, > > quirk_sis_96x_smbus ); > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_LPC, > > quirk_sis_96x_smbus ); > > > > /* > > * ... This is further complicated by the fact that some SiS96x south > > @@ -1158,6 +1167,8 @@ static void quirk_sis_503(struct pci_dev > > */ > > dev->device = devid; > > } > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_503, > > quirk_sis_503 ); > > +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_503, > > quirk_sis_503 ); * Jean Delvare <[EMAIL PROTECTED]> [2007-01-05 09:52:33 +0100]: > Was this patch tested on the SiS-based boards which need these quirks? > I think you broke them. If I remember correctly, quirk_sis_503() must > be called before quirk_sis_96x_smbus() for some boards to work > properly, and we currently rely on the linking order to guarantee that. > Likewise, quirk_sis_96x_compatible() should be called before > quirk_sis_503() otherwise the warning message in quirk_sis_503() will > no longer be correct. > > So if you want to put the calls right after the quirk functions, you > need to reorder the functions themselves as well. Feel free to add a > comment explaining the order requirement so that nobody breaks it > accidentally again in the future. It is fragile for this code to depend on link order; Adrian's obvious and trivial cleanups broke it. Not only that, but some FC kernels had/have the link order reversed such that this quirk is broken anyway. I sent a patch for this back in May: http://lists.lm-sensors.org/pipermail/lm-sensors/2006-May/016113.html There was some discussion on the linux-pci mailing list as well; can't seem to find an archive of that though. Basically, it was not understood how the FC kernels could have a reversed link order. I never followed up on it, my bad. At any rate, can we please get the patch above applied? I will send a new one if necessary. 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] I2C block reads with i2c-viapro: testers wanted
Hi Jean: * Jean Delvare <[EMAIL PROTECTED]> [2005-08-09 23:13:28 +0200]: > I am implementing I2C block reads in the i2c-viapro driver, and am > looking for testers. I was able to test on my own VT8237R chip, it works > OK, now I'd need to know how it works on older VIA south bridges, namely > the VT8235 and the VT82C686B. South bridges before that (VT82C686A, > VT8233A and older) are supposed not to work according to the datasheets, > but a confirmation would be welcome, who knows, it might simply not be > documented. > > My experimental patch follows. I have enabled the I2C block read > function for all VIA south bridges, so that it can be tested on all > chips. I'll restrict that after the test phase, of course. I fired it up on one of the older chipsets... # lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 23) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 11) 00:07.3 Host bridge: VIA Technologies, Inc. VT82C596 Power Management (rev 30) # lspci -n 00:00.0 Class 0600: 1106:0691 (rev c4) 00:01.0 Class 0604: 1106:8598 00:07.0 Class 0601: 1106:0596 (rev 23) 00:07.1 Class 0101: 1106:0571 (rev 10) 00:07.2 Class 0c03: 1106:3038 (rev 11) 00:07.3 Class 0600: 1106:3050 (rev 30) As you suspected, it didn't work. # i2cdump -y 0 0x50 i Error: Block read failed, return code 0 > On my system, the dump is down from over 2 seconds without the patch to > below 0.2 second with the patch, which proves how efficient I2C block > reads are and explains why I want to implement this function. I also found something interesting, by accident. With a stock FC4 kernel, the i2cdump clocked at 1.02s total. With 2.6.13-rc6, it took 5.11s! The only relevant difference that I can see is that the FC4 kernel uses HZ of 1000 while my 2.6.13-rc6 kernel uses 100. Because the i2c-viapro is a polling driver, it becomes slower as HZ decreases. I.e. the improvement you are seeing with byte vs. block xfers is quite exaggerated because we poll the device relatively infrequently. *All* the xfers are slower than they could be w/ a non-polling driver. 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: make -j4 gets stuck w/ ccache over NFS - solved!
Hi Tridge, Greg, et. al.: I wrote, some months ago: > > I'm using ccache version 2.4 [1]. I just changed ~/.ccache to a symbolic > > link to a directory which is NFS mounted [2]. The kernel source itself is > > on a local FS. With the ccache suitably primed, when I do a kernel compile > > using 'make -j4' it seems to get stuck for seconds at a time. When it gets > > unstuck, it blows through a handful of files and then gets stuck again. * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2004-12-08 18:25:59 +1100]: > I'd suggest you first narrow down the problem to either being a > locking problem or a file IO problem. To do that, change lock_fd() in > util.c in ccache to just "return 0;". That will mean the ccache stats > file could become corrupted, but if it runs fast then you know that it > is a locking problem. I have noticed severe speed problem with NFS > locking on Linux previosly, which is why I mention this as a > possibility. > > Note that removing this locking will not cause ccache to produce > incorrect object files, it will just mean the stats printed with > "ccache -s" may be inaccurate. Thanks for the suggestions. It wasn't very important to me so I didn't make time to follow up on it. I was just playing w/ ccache at the time. Finally I noticed this patch from -mm1... and it solves the problem. nfsd--lockd-dont-try-to-match-callback-requests-against-export-table.patch How I tested: I applied the first 12 patches in 2.6.11-mm1; the above mentioned was last - couldn't reproduce the bug. When I unapplied just that one, I saw it again. original bug report: http://marc.theaimsgroup.com/?l=linux-kernel&m=110238645132535&w=3 Greg: have you considered this one for 2.6.11.x? 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/
