aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* hwmon: (tmp103) Use SIMPLE_DEV_PM_OPS helper macroRahul Bedarkar2017-04-24
| | | | | | | | Replace ifdefs with SIMPLE_DEV_PM_OPS helper macro. Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Acked-by: Heiko Schocher <hs@denx.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (adt7475) set start bit in probeChris Packham2017-04-21
| | | | | | | | | | | | The ADT7475 and ADT7476 have the STRT bit cleared by default[1]. Before any monitoring activities the STRT bit needs to be set. Logically this needs to happen before any of the sensors are read so the probe() function seems the best place for it. [1] - https://www.onsemi.com/pub/Collateral/ADT7475-D.PDF Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (ina209) Handled signed registersJoe Schaack2017-04-21
| | | | | | | | | The shunt voltage and current registers are signed 16-bit values so handle them as such. Signed-off-by: Joe Schaack <jschaack@xes-inc.com> Reviewed-by: Aaron Sierra <asierra@xes-inc.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (lm87) Add OF device ID tableJavier Martinez Canillas2017-04-13
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (lm87) Remove unused I2C devices driver_dataJavier Martinez Canillas2017-04-13
| | | | | | | | The I2C device ID entries set a .driver_data but this data is never looked up by the driver. So don't set it and also remove the enum. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* drivers: hwmon: Support for ASPEED PWM/Fan tachJaghathiswari Rankappagounder Natarajan2017-04-10
| | | | | | | | | | | | | | | The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports. The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer inputs. The device driver matches on the device tree node. The configuration values are read from the device tree and written to the respective registers. The driver provides a sysfs entries through which the user can configure the duty-cycle value (ranging from 0 to 100 percent) and read the fan tach rpm value. Signed-off-by: Jaghathiswari Rankappagounder Natarajan <jaghu@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM ↵Jaghathiswari Rankappagounder Natarajan2017-04-10
| | | | | | | | | | | | | and Fan tach controller device driver This binding provides interface for adding values related to ASPEED AST2400/2500 PWM and Fan tach controller support. The PWM controller can support upto 8 PWM output ports. The Fan tach controller can support upto 16 tachometer inputs. Signed-off-by: Jaghathiswari Rankappagounder Natarajan <jaghu@google.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (lm87) Allow channel data to be set from dts fileMahoda Ratnayaka2017-04-02
| | | | | | | | | | | | | | | | | | | Currently there is no method for setting the channel value from the DTS file. When, the driver uses a dts file to initialize the driver platform_data is not set. As a result channel variable may not be set correctly. Without the channel variable set correctly, some of the sensors will not be initialized correctly. For example temp3 sensor sysfs entries. This implements the schema agreed with the device tree binding document. Signed-off-by: Mahoda Ratnayaka <mahoda.ratnayaka@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* Documentation: dtb: lm87: Add hwmon binding documentationMahoda Ratnayaka2017-04-02
| | | | | | | | | This patch adds lm87 hwmon device tree node documentation. Signed-off-by: Mahoda Ratnayaka <mahoda.ratnayaka@alliedtelesis.co.nz> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (ads7828) Accept optional parameters from device treeSam Povilus2017-04-02
| | | | | | | | | | Adding the ability for the ads7828 and ads7830 to use device tree to get optional parameters instead of using platform devices. This allows people using custom boards to also use the ads7828 in a non-default manner. Signed-off-by: Sam Povilus <kernel.development@povil.us> [groeck: Fixed whitespace errors in ads7828.txt] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (dell-smm) Add Dell XPS 15 9560 into DMI listPali Rohár2017-04-02
| | | | | | | | | It was reported that dell-smm-hwmon is working fine on Dell XPS 15 9560. Link: http://www.spinics.net/lists/platform-driver-x86/msg10751.html Reported-by: Vasile Dumitrescu <vasile.dumitrescu@undeva.eu> Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: Constify str parameter of hwmon_ops->read_stringJean Delvare2017-04-02
| | | | | | | | | The read_string callback is supposed to retrieve a pointer to a constant string. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* dt: Add vendor prefix for SensirionMarco Franchi2017-04-02
| | | | | | | | | | Sensirion is a sensor manufacturer, providing relative humidity sensors, temperature sensor and flow sensor solutions. Signed-off-by: Marco Franchi <marco.franchi@nxp.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (tmp421) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (tmp103) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (tmp102) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (stts751) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (ucd9200) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (ucd9000) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (max6697) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (lm95245) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (lm90) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (lm85) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (lm75) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (lm63) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (ina2xx) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (ina209) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (adt7475) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (ads7828) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (ads1015) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (adc128d818) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (ad7414) Add OF device ID tableJavier Martinez Canillas2017-04-02
| | | | | | | | | | | | | The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* hwmon: (w83627ehf) Use request_muxed_regionKatsumi Sato2017-04-02
| | | | | | | | | | | Serialize access to the hardware by using "request_muxed_region". Call to this macro will hold off the requestor if the resource is currently busy. "superio_enter" will return an error if call to "request_muxed_region" fails. Signed-off-by: Katsumi Sato <sato@toshiba-tops.co.jp> Signed-off-by: Atsushi Nemoto <nemoto@toshiba-tops.co.jp> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* docs: hwmon: Fix typo "Microship" should be "Microchip"Chris Packham2017-04-02
| | | | | Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* driver: (adm1275) set the m,b and R coefficients correctly for powerShikhar Dogra2017-03-27
| | | | | | | | | | | | | Seems like coefficient values for m, b and R under power have been put in the wrong order. Rearranging them properly to get correct values of coefficients for power. For specs, please refer to table 7 (page 35) on http://www.analog.com/media/en/technical-documentation/data-sheets/ADM1075.pdf Fixes: 904b296f308d ("hwmon: (adm1275) Introduce configuration data structure for coeffcients") Signed-off-by: Shikhar Dogra <shidogra@cisco.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* Linux 4.11-rc4Linus Torvalds2017-03-26
|
* Merge tag 'char-misc-4.11-rc4' of ↵Linus Torvalds2017-03-26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "A smattering of different small fixes for some random driver subsystems. Nothing all that major, just resolutions for reported issues and bugs. All have been in linux-next with no reported issues" * tag 'char-misc-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (21 commits) extcon: int3496: Set the id pin to direction-input if necessary extcon: int3496: Use gpiod_get instead of gpiod_get_index extcon: int3496: Add dependency on X86 as it's Intel specific extcon: int3496: Add GPIO ACPI mapping table extcon: int3496: Rename GPIO pins in accordance with binding vmw_vmci: handle the return value from pci_alloc_irq_vectors correctly ppdev: fix registering same device name parport: fix attempt to write duplicate procfiles auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches Drivers: hv: vmbus: Don't leak memory when a channel is rescinded Drivers: hv: vmbus: Don't leak channel ids Drivers: hv: util: don't forget to init host_ts.lock Drivers: hv: util: move waiting for release to hv_utils_transport itself vmbus: remove hv_event_tasklet_disable/enable vmbus: use rcu for per-cpu channel list mei: don't wait for os version message reply mei: fix deadlock on mei reset intel_th: pci: Add Gemini Lake support intel_th: pci: Add Denverton SOC support intel_th: Don't leak module refcount on failure to activate ...
| * Merge tag 'extcon-fixes-for-4.11-rc3' of ↵Greg Kroah-Hartman2017-03-22
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-linus Chanwoo writes: Update extcon for v4.11-rc3 This patch fixes issues for Intel INT3496 ACPI device as following: - Propagate error code of gpiod_to_irq(). - Set the ID pin as the input direction if firmware has the bug - Rename the gpio name for bining according to the documentation. - Add gpio acpi mapping table and the dependency on X86. - Use the devm_gpiod_get() instead of gpiod_get_index because of acpi mapping table.
| | * extcon: int3496: Set the id pin to direction-input if necessaryHans de Goede2017-03-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the new more strict ACPI gpio code the dsdt's IoRestriction flags are honored on gpiod_get, but in some dsdt's it is wrong, so explicitly call gpiod_direction_input on the id gpio if necessary. This fixes the following errors when the int3496 code is used together with the new more strict ACPI gpio code: [ 2382.484415] gpio gpiochip1: (INT33FF:01): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ [ 2382.484425] gpio gpiochip1: (INT33FF:01): unable to lock HW IRQ 3 for IRQ [ 2382.484429] genirq: Failed to request resources for INT3496:00 (irq 174) on irqchip chv-gpio [ 2382.484518] intel-int3496 INT3496:00: can't request IRQ for USB ID GPIO: -22 [ 2382.500359] intel-int3496: probe of INT3496:00 failed with error -22 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
| | * extcon: int3496: Use gpiod_get instead of gpiod_get_indexHans de Goede2017-03-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we've an acpi mapping table we should be using gpiod_get instead of gpiod_get_index. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
| | * extcon: int3496: Add dependency on X86 as it's Intel specificPeter Robinson2017-03-22
| | | | | | | | | | | | | | | | | | | | | | | | Add dependency on X86 so it doesn't show up on other arches and add a option for compile test so it still gets build coverage. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
| | * extcon: int3496: Add GPIO ACPI mapping tableAndy Shevchenko2017-03-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to make GPIO ACPI library stricter prepare users of gpiod_get_index() to correctly behave when there no mapping is provided by firmware. Here we add explicit mapping between _CRS GpioIo() resources and their names used in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
| | * extcon: int3496: Rename GPIO pins in accordance with bindingAndy Shevchenko2017-03-22
| | | | | | | | | | | | | | | | | | | | | | | | Update GPIO pin names in extcon-intel-int3496.c driver to follow the existing extcon binding. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
| | * extcon: int3496: Propagate error code of gpiod_to_irq()Andy Shevchenko2017-03-12
| | | | | | | | | | | | | | | | | | | | | | | | gpiod_to_irq() doesn't return 0. Thus, we just adjust condition and replace -EINVAL by actual error code it returns. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
| * | vmw_vmci: handle the return value from pci_alloc_irq_vectors correctlyChristoph Hellwig2017-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It returns the number of vectors allocated when successful, so check for a negative error only. Fixes: 3bb434cd ("vmw_vmci: switch to pci_irq_alloc_vectors") Signed-off-by: Christoph Hellwig <hch@lst.de> Reported-by: Loïc Yhuel <loic.yhuel@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | ppdev: fix registering same device nameSudip Mukherjee2017-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usually every parallel port will have a single pardev registered with it. But ppdev driver is an exception. This userspace parallel port driver allows to create multiple parrallel port devices for a single parallel port. And as a result we were having a big warning like: "sysfs: cannot create duplicate filename '/devices/parport0/ppdev0.0'". And with that many parallel port printers stopped working. We have been using the minor number as the id field while registering a parralel port device with a parralel port. But when there are multiple parrallel port device for one single parallel port, they all tried to register with the same name like 'pardev0.0' and everything started failing. Use an incremented index as the id instead of the minor number. Fixes: 8b7d3a9d903e ("ppdev: use new parport device model") Cc: stable <stable@vger.kernel.org> # v4.9+ Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1414656 Bugzilla: https://bugs.archlinux.org/task/52322 Tested-by: James Feeney <james@nurealm.net> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | parport: fix attempt to write duplicate procfilesSudip Mukherjee2017-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usually every parallel port will have a single pardev registered with it. But ppdev driver is an exception. This userspace parallel port driver allows to create multiple parrallel port devices for a single parallel port. And as a result we were having a nice warning like: "sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists" Use the same logic as used in parport_register_device() and register the proc files only once for each parallel port. Fixes: 6fa45a226897 ("parport: add device-model to parport subsystem") Cc: stable <stable@vger.kernel.org> # v4.4+ Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1414656 Bugzilla: https://bugs.archlinux.org/task/52322 Tested-by: James Feeney <james@nurealm.net> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matchesDmitry Torokhov2017-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OF device table must be terminated, otherwise we'll be walking past it and into areas unknown. Fixes: 0cad855fbd08 ("auxdisplay: img-ascii-lcd: driver for simple ASCII...") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | Drivers: hv: vmbus: Don't leak memory when a channel is rescindedK. Y. Srinivasan2017-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we close a channel that has been rescinded, we will leak memory since vmbus_teardown_gpadl() returns an error. Fix this so that we can properly cleanup the memory allocated to the ring buffers. Fixes: ccb61f8a99e6 ("Drivers: hv: vmbus: Fix a rescind handling bug") Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * | Drivers: hv: vmbus: Don't leak channel idsK. Y. Srinivasan2017-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | If we cannot allocate memory for the channel, free the relid associated with the channel. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>