From c1a1260244d8ffe017fbb3199f65c842e4d42fe6 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Tue, 20 Mar 2012 23:06:34 -0400 Subject: hwmon: (gpio-fan) Fix Kconfig dependencies gpio-fan depends on GPIOLIB, not on GENERIC_GPIO. This fixes the following build error, seen if GPIOLIB is not defined: src/drivers/hwmon/gpio-fan.c: error: implicit declaration of function 'gpio_direction_output': => 372:3 src/drivers/hwmon/gpio-fan.c: error: implicit declaration of function 'gpio_free': => 130:2 src/drivers/hwmon/gpio-fan.c: error: implicit declaration of function 'gpio_get_value': => 79:2 src/drivers/hwmon/gpio-fan.c: error: implicit declaration of function 'gpio_request': => 98:2 src/drivers/hwmon/gpio-fan.c: error: implicit declaration of function 'gpio_set_value': => 156:3 src/drivers/hwmon/gpio-fan.c: error: implicit declaration of function 'gpio_to_irq': => 114:2 Signed-off-by: Guenter Roeck Acked-by: Jean Delvare Acked-by: Simon Guinot diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 5b32d56..496f80d 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -425,7 +425,7 @@ config SENSORS_GL520SM config SENSORS_GPIO_FAN tristate "GPIO fan" - depends on GENERIC_GPIO + depends on GPIOLIB help If you say yes here you get support for fans connected to GPIO lines. -- cgit v0.10.2 From be45d422d96ba22ecd0e34690644099d172e9c6d Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Tue, 20 Mar 2012 23:06:35 -0400 Subject: hwmon: (sht15) Fix Kconfig dependencies sht15 depends on GPIOLIB, not on GENERIC_GPIO. This fixes the following build error, seen if GPIOLIB is not defined: src/drivers/hwmon/sht15.c: error: implicit declaration of function 'gpio_direction_input': => 293:2 src/drivers/hwmon/sht15.c: error: implicit declaration of function 'gpio_direction_output': => 216:2 src/drivers/hwmon/sht15.c: error: implicit declaration of function 'gpio_free': => 1000:2 src/drivers/hwmon/sht15.c: error: implicit declaration of function 'gpio_get_value': => 296:2 src/drivers/hwmon/sht15.c: error: implicit declaration of function 'gpio_request': => 946:2 src/drivers/hwmon/sht15.c: error: implicit declaration of function 'gpio_set_value': => 218:2 src/drivers/hwmon/sht15.c: error: implicit declaration of function 'gpio_to_irq': => 514:2 Signed-off-by: Guenter Roeck Acked-by: Jean Delvare diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 496f80d..670f274 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -883,7 +883,7 @@ source drivers/hwmon/pmbus/Kconfig config SENSORS_SHT15 tristate "Sensiron humidity and temperature sensors. SHT15 and compat." - depends on GENERIC_GPIO + depends on GPIOLIB help If you say yes here you get support for the Sensiron SHT10, SHT11, SHT15, SHT71, SHT75 humidity and temperature sensors. -- cgit v0.10.2 From 52f30f77171f934cb9562908cb279178b890a048 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Thu, 22 Mar 2012 16:23:58 -0400 Subject: hwmon: (max6639) Convert to dev_pm_ops The I2C specific PM operations have been deprecated and printing a warning on boot for over a year now. Signed-off-by: Mark Brown [guenter.roeck@ericsson.com: Added missing #ifdef around pm functions] Cc: stable@vger.kernel.org # 3.0+ Signed-off-by: Guenter Roeck diff --git a/drivers/hwmon/max6639.c b/drivers/hwmon/max6639.c index 193067e..de8f7ad 100644 --- a/drivers/hwmon/max6639.c +++ b/drivers/hwmon/max6639.c @@ -596,8 +596,10 @@ static int max6639_remove(struct i2c_client *client) return 0; } -static int max6639_suspend(struct i2c_client *client, pm_message_t mesg) +#ifdef CONFIG_PM_SLEEP +static int max6639_suspend(struct device *dev) { + struct i2c_client *client = to_i2c_client(dev); int data = i2c_smbus_read_byte_data(client, MAX6639_REG_GCONFIG); if (data < 0) return data; @@ -606,8 +608,9 @@ static int max6639_suspend(struct i2c_client *client, pm_message_t mesg) MAX6639_REG_GCONFIG, data | MAX6639_GCONFIG_STANDBY); } -static int max6639_resume(struct i2c_client *client) +static int max6639_resume(struct device *dev) { + struct i2c_client *client = to_i2c_client(dev); int data = i2c_smbus_read_byte_data(client, MAX6639_REG_GCONFIG); if (data < 0) return data; @@ -615,6 +618,7 @@ static int max6639_resume(struct i2c_client *client) return i2c_smbus_write_byte_data(client, MAX6639_REG_GCONFIG, data & ~MAX6639_GCONFIG_STANDBY); } +#endif /* CONFIG_PM_SLEEP */ static const struct i2c_device_id max6639_id[] = { {"max6639", 0}, @@ -623,15 +627,18 @@ static const struct i2c_device_id max6639_id[] = { MODULE_DEVICE_TABLE(i2c, max6639_id); +static const struct dev_pm_ops max6639_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(max6639_suspend, max6639_resume) +}; + static struct i2c_driver max6639_driver = { .class = I2C_CLASS_HWMON, .driver = { .name = "max6639", + .pm = &max6639_pm_ops, }, .probe = max6639_probe, .remove = max6639_remove, - .suspend = max6639_suspend, - .resume = max6639_resume, .id_table = max6639_id, .detect = max6639_detect, .address_list = normal_i2c, -- cgit v0.10.2 From 6394011d65b7e74666f07cca98747601cf8298fa Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Sat, 24 Mar 2012 08:38:21 -0700 Subject: hwmon: (f75375s) Fix warning message seen in some configurations In some configurations, BUG() does not result in an endless loop but returns to the caller. This results in the following compiler warning: drivers/hwmon/f75375s.c: In function 'duty_mode_enabled': drivers/hwmon/f75375s.c:280: warning: control reaches end of non-void function drivers/hwmon/f75375s.c: In function 'auto_mode_enabled': drivers/hwmon/f75375s.c:295: warning: control reaches end of non-void function Fix the warning by returning something sensible after BUG(). Cc: Nikolaus Schulz Cc: Riku Voipio Signed-off-by: Guenter Roeck Acked-by: Jean Delvare Signed-off-by: Guenter Roeck diff --git a/drivers/hwmon/f75375s.c b/drivers/hwmon/f75375s.c index 729499e..ece4159 100644 --- a/drivers/hwmon/f75375s.c +++ b/drivers/hwmon/f75375s.c @@ -276,6 +276,7 @@ static bool duty_mode_enabled(u8 pwm_enable) return false; default: BUG(); + return true; } } @@ -291,6 +292,7 @@ static bool auto_mode_enabled(u8 pwm_enable) return true; default: BUG(); + return false; } } -- cgit v0.10.2 From ce15a81da33b961852f6e6a55305ccc60856de25 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Sat, 24 Mar 2012 08:51:05 -0700 Subject: hwmon: (adm1031) Fix compiler warning Some configurations produce the following compile warning: drivers/hwmon/adm1031.c: In function 'set_fan_auto_channel': drivers/hwmon/adm1031.c:292: warning: 'reg' may be used uninitialized in this function While this is a false positive, it can easily be fixed by overloading the return value from get_fan_auto_nearest with both register value and error return code (the register value is never negative). Coincidentially, that also reduces module size by a few bytes. Signed-off-by: Guenter Roeck Acked-by: Jean Delvare diff --git a/drivers/hwmon/adm1031.c b/drivers/hwmon/adm1031.c index ff37363..44e1fd7 100644 --- a/drivers/hwmon/adm1031.c +++ b/drivers/hwmon/adm1031.c @@ -233,18 +233,15 @@ static const auto_chan_table_t auto_channel_select_table_adm1030 = { * nearest match if no exact match where found. */ static int -get_fan_auto_nearest(struct adm1031_data *data, - int chan, u8 val, u8 reg, u8 *new_reg) +get_fan_auto_nearest(struct adm1031_data *data, int chan, u8 val, u8 reg) { int i; int first_match = -1, exact_match = -1; u8 other_reg_val = (*data->chan_select_table)[FAN_CHAN_FROM_REG(reg)][chan ? 0 : 1]; - if (val == 0) { - *new_reg = 0; + if (val == 0) return 0; - } for (i = 0; i < 8; i++) { if ((val == (*data->chan_select_table)[i][chan]) && @@ -264,13 +261,11 @@ get_fan_auto_nearest(struct adm1031_data *data, } if (exact_match >= 0) - *new_reg = exact_match; + return exact_match; else if (first_match >= 0) - *new_reg = first_match; - else - return -EINVAL; + return first_match; - return 0; + return -EINVAL; } static ssize_t show_fan_auto_channel(struct device *dev, @@ -301,11 +296,12 @@ set_fan_auto_channel(struct device *dev, struct device_attribute *attr, mutex_lock(&data->update_lock); - ret = get_fan_auto_nearest(data, nr, val, data->conf1, ®); - if (ret) { + ret = get_fan_auto_nearest(data, nr, val, data->conf1); + if (ret < 0) { mutex_unlock(&data->update_lock); return ret; } + reg = ret; data->conf1 = FAN_CHAN_TO_REG(reg, data->conf1); if ((data->conf1 & ADM1031_CONF1_AUTO_MODE) ^ (old_fan_mode & ADM1031_CONF1_AUTO_MODE)) { -- cgit v0.10.2 From 31e354ee653c3d85e802a372f27224130fc95011 Mon Sep 17 00:00:00 2001 From: Kyle McMartin Date: Wed, 28 Mar 2012 15:11:47 -0400 Subject: hwmon: (acpi_power_meter) fix lockdep spew due to non-static lock class Similar to a30dcb4f which fixed asus_atk0110.ko, I recently received a bug report from someone hitting the same issue in acpi_power_meter. [ 13.963168] power_meter ACPI000D:00: Found ACPI power meter. [ 13.963900] BUG: key ffff8802161f3920 not in .data! [ 13.963904] ------------[ cut here ]------------ [ 13.963915] WARNING: at kernel/lockdep.c:2986 lockdep_init_map+0x52f/0x560() So let's fix that up for them by statically declaring the lockdep_class_key. Signed-off-by: Kyle McMartin Cc: stable@vger.kernel.org # 3.0+ Signed-off-by: Guenter Roeck diff --git a/drivers/hwmon/acpi_power_meter.c b/drivers/hwmon/acpi_power_meter.c index 554f046..145f135 100644 --- a/drivers/hwmon/acpi_power_meter.c +++ b/drivers/hwmon/acpi_power_meter.c @@ -632,6 +632,7 @@ static int register_ro_attrs(struct acpi_power_meter_resource *resource, sensors->dev_attr.show = ro->show; sensors->index = ro->index; + sysfs_attr_init(&sensors->dev_attr.attr); res = device_create_file(dev, &sensors->dev_attr); if (res) { sensors->dev_attr.attr.name = NULL; @@ -661,6 +662,7 @@ static int register_rw_attrs(struct acpi_power_meter_resource *resource, sensors->dev_attr.store = rw->set; sensors->index = rw->index; + sysfs_attr_init(&sensors->dev_attr.attr); res = device_create_file(dev, &sensors->dev_attr); if (res) { sensors->dev_attr.attr.name = NULL; -- cgit v0.10.2 From 6f7805a8d9dc6fa8af999f8603188157505558d9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Fri, 30 Mar 2012 16:04:55 -0400 Subject: hwmon: (w83627ehf) mark const init data with __initconst instead of __initdata MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As long as there is no other non-const variable marked __initdata in the same compilation unit it doesn't hurt. If there were one however compilation would fail with error: $variablename causes a section type conflict because a section containing const variables is marked read only and so cannot contain non-const variables. Signed-off-by: Uwe Kleine-König Cc: Jean Delvare Cc: Guenter Roeck Cc: lm-sensors@lm-sensors.org Signed-off-by: Guenter Roeck diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c index a25350c..54922ed 100644 --- a/drivers/hwmon/w83627ehf.c +++ b/drivers/hwmon/w83627ehf.c @@ -2619,15 +2619,15 @@ static struct platform_driver w83627ehf_driver = { static int __init w83627ehf_find(int sioaddr, unsigned short *addr, struct w83627ehf_sio_data *sio_data) { - static const char __initdata sio_name_W83627EHF[] = "W83627EHF"; - static const char __initdata sio_name_W83627EHG[] = "W83627EHG"; - static const char __initdata sio_name_W83627DHG[] = "W83627DHG"; - static const char __initdata sio_name_W83627DHG_P[] = "W83627DHG-P"; - static const char __initdata sio_name_W83627UHG[] = "W83627UHG"; - static const char __initdata sio_name_W83667HG[] = "W83667HG"; - static const char __initdata sio_name_W83667HG_B[] = "W83667HG-B"; - static const char __initdata sio_name_NCT6775[] = "NCT6775F"; - static const char __initdata sio_name_NCT6776[] = "NCT6776F"; + static const char sio_name_W83627EHF[] __initconst = "W83627EHF"; + static const char sio_name_W83627EHG[] __initconst = "W83627EHG"; + static const char sio_name_W83627DHG[] __initconst = "W83627DHG"; + static const char sio_name_W83627DHG_P[] __initconst = "W83627DHG-P"; + static const char sio_name_W83627UHG[] __initconst = "W83627UHG"; + static const char sio_name_W83667HG[] __initconst = "W83667HG"; + static const char sio_name_W83667HG_B[] __initconst = "W83667HG-B"; + static const char sio_name_NCT6775[] __initconst = "NCT6775F"; + static const char sio_name_NCT6776[] __initconst = "NCT6776F"; u16 val; const char *sio_name; -- cgit v0.10.2 From fbc729a446f7d80ec8b73fe90d8c0cc3e95ad277 Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Fri, 30 Mar 2012 16:48:20 -0400 Subject: hwmon: (k10temp) Add support for AMD Trinity CPUs The on-chip northbridge's temperature sensor of the upcoming AMD Trinity CPUs works the same as for the previous CPUs. Since it has a different PCI-ID, we just add the new one to the list supported by k10temp. This allows to use the k10temp driver on those CPUs. Signed-off-by: Andre Przywara Cc: stable@vger.kernel.org # 3.0+ Signed-off-by: Guenter Roeck diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp index a10f736..90956b6 100644 --- a/Documentation/hwmon/k10temp +++ b/Documentation/hwmon/k10temp @@ -11,7 +11,7 @@ Supported chips: Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series) * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series) -* AMD Family 15h processors: "Bulldozer" +* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity" Prefix: 'k10temp' Addresses scanned: PCI space diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 670f274..8deedc1 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -253,7 +253,8 @@ config SENSORS_K10TEMP If you say yes here you get support for the temperature sensor(s) inside your CPU. Supported are later revisions of the AMD Family 10h and all revisions of the AMD Family 11h, - 12h (Llano), 14h (Brazos) and 15h (Bulldozer) microarchitectures. + 12h (Llano), 14h (Brazos) and 15h (Bulldozer/Trinity) + microarchitectures. This driver can also be built as a module. If so, the module will be called k10temp. diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c index aba29d6..307bb32 100644 --- a/drivers/hwmon/k10temp.c +++ b/drivers/hwmon/k10temp.c @@ -33,6 +33,9 @@ static bool force; module_param(force, bool, 0444); MODULE_PARM_DESC(force, "force loading on processors with erratum 319"); +/* PCI-IDs for Northbridge devices not used anywhere else */ +#define PCI_DEVICE_ID_AMD_15H_M10H_NB_F3 0x1403 + /* CPUID function 0x80000001, ebx */ #define CPUID_PKGTYPE_MASK 0xf0000000 #define CPUID_PKGTYPE_F 0x00000000 @@ -210,6 +213,7 @@ static DEFINE_PCI_DEVICE_TABLE(k10temp_id_table) = { { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_11H_NB_MISC) }, { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) }, { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) }, + { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_NB_F3) }, {} }; MODULE_DEVICE_TABLE(pci, k10temp_id_table); -- cgit v0.10.2 From e16de9137c8beab02d78fb4fa82bb96e9f3d0ac3 Mon Sep 17 00:00:00 2001 From: Graeme Smecher Date: Tue, 3 Apr 2012 19:42:21 -0400 Subject: hwmon: (ad7314) Adds missing spi_dev initialization This driver was recently moved from IIO (where it worked) to hwmon (where it doesn't.) This breakage occured because the hwmon version neglected to correctly initialize a reference to spi_dev in its drvdata. The result is a segfault every time the temperature is queried. Signed-off-by: Graeme Smecher Cc: stable@vger.kernel.org # 3.2+ Signed-off-by: Guenter Roeck diff --git a/drivers/hwmon/ad7314.c b/drivers/hwmon/ad7314.c index 0e0cfcc..ce43642 100644 --- a/drivers/hwmon/ad7314.c +++ b/drivers/hwmon/ad7314.c @@ -128,6 +128,7 @@ static int __devinit ad7314_probe(struct spi_device *spi_dev) ret = PTR_ERR(chip->hwmon_dev); goto error_remove_group; } + chip->spi_dev = spi_dev; return 0; error_remove_group: -- cgit v0.10.2