linux-dev/drivers/misc/lis3lv02d, branch master

i2c: Make remove callback return void

2022-08-16T10:46:26Z

The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Reviewed-by: Peter Senna Tschudin Reviewed-by: Jeremy Kerr Reviewed-by: Benjamin Mugnier Reviewed-by: Javier Martinez Canillas Reviewed-by: Crt Mori Reviewed-by: Heikki Krogerus Acked-by: Greg Kroah-Hartman Acked-by: Marek Behún # for leds-turris-omnia Acked-by: Andy Shevchenko Reviewed-by: Petr Machata # for mlxsw Reviewed-by: Maximilian Luz # for surface3_power Acked-by: Srinivas Pandruvada # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil # for media/* + staging/media/* Acked-by: Miguel Ojeda # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli # for versaclock5 Reviewed-by: Ajay Gupta # for ucsi_ccg Acked-by: Jonathan Cameron # for iio Acked-by: Peter Rosin # for i2c-mux-*, max9860 Acked-by: Adrien Grassein # for lontium-lt8912b Reviewed-by: Jean Delvare # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard # for IPMI Reviewed-by: Vladimir Oltean Acked-by: Dmitry Torokhov Acked-by: Sebastian Reichel # for drivers/power Acked-by: Krzysztof Hałasa Signed-off-by: Uwe Kleine-König Signed-off-by: Wolfram Sang

spi: make remove callback a void function

2022-02-09T13:00:45Z

The value returned by an spi driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Signed-off-by: Uwe Kleine-König Acked-by: Marc Kleine-Budde Acked-by: Andy Shevchenko Reviewed-by: Geert Uytterhoeven Acked-by: Jérôme Pouiller Acked-by: Miquel Raynal Acked-by: Jonathan Cameron Acked-by: Claudius Heine Acked-by: Stefan Schmidt Acked-by: Alexandre Belloni Acked-by: Ulf Hansson # For MMC Acked-by: Marcus Folkesson Acked-by: Łukasz Stelmach Acked-by: Lee Jones Link: https://lore.kernel.org/r/20220123175201.34839-6-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown

misc: lis3lv02d: Make lis3lv02d_remove_fs() return void

2021-10-13T12:35:20Z

Up to now lis3lv02d_remove_fs() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20211012153945.2651412-13-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

platform/x86: hp_accel: Remove _INI method call

2021-08-26T13:09:18Z

According to ACPI specification the _INI method must be called when device is enumerated first time. After that there is no need to repeat the procedure. Convert the lis3lv02d_acpi_init() to be a stub (Note, we may not remove it because it is called unconditionally by the accelerometer main driver). Signed-off-by: Andy Shevchenko Tested-by: Kai-Heng Feng Link: https://lore.kernel.org/r/20210823093222.19544-2-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/x86: hp_accel: Avoid invoking _INI to speed up resume

2021-05-11T11:44:18Z

hp_accel can take almost two seconds to resume on some HP laptops. The bottleneck is on evaluating _INI, which is only needed to run once. Resolve the issue by only invoking _INI when it's necessary. Namely, on probe and on hibernation restore. Signed-off-by: Kai-Heng Feng Acked-by: Éric Piel Link: https://lore.kernel.org/r/20210430060736.590321-1-kai.heng.feng@canonical.com Signed-off-by: Hans de Goede

misc: lis3lv02d: Do not log an error when kmalloc fails

2021-03-24T07:26:29Z

Logging an error when kmalloc fails is not necessary (and in general should be avoided) because the malloc failure will already complain loudly itself. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210217102501.31758-3-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman

misc: lis3lv02d: Change lis3lv02d_init_device() return value for unknown sensors to -ENODEV

2021-03-24T07:26:29Z

Modern HP laptops do not necessarily actually contain a lis3lv02d sensor, yet they still define a HPQ6007 device in there ACPI tables. This leads to the following messages being logged in dmesg: [ 17.376342] hp_accel: laptop model unknown, using default axes configuration [ 17.399766] lis3lv02d: unknown sensor type 0x0 [ 17.399804] hp_accel: probe of HPQ6007:00 failed with error -22 The third message is unnecessary and does not provide any useful info, change the return value for unknown sensors to -ENODEV. This is the proper return value to indicate that the driver will not be handling the device and it silences the pr_warn printing the third message. Signed-off-by: Hans de Goede BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199715 Link: https://lore.kernel.org/r/20210217102501.31758-2-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman

misc: lis3lv02d: Fix false-positive WARN on various HP models

2021-03-24T07:26:29Z

Before this commit lis3lv02d_get_pwron_wait() had a WARN_ONCE() to catch a potential divide by 0. WARN macros should only be used to catch internal kernel bugs and that is not the case here. We have been receiving a lot of bug reports about kernel backtraces caused by this WARN. The div value being checked comes from the lis3->odrs[] array. Which is sized to be a power-of-2 matching the number of bits in lis3->odr_mask. The only lis3 model where this array is not entirely filled with non zero values. IOW the only model where we can hit the div == 0 check is the 3dc ("8 bits 3DC sensor") model: int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000}; Note the 0 value at index 0, according to the datasheet an odr index of 0 means "Power-down mode". HP typically uses a lis3 accelerometer for HDD fall protection. What I believe is happening here is that on newer HP devices, which only contain a SDD, the BIOS is leaving the lis3 device powered-down since it is not used for HDD fall protection. Note that the lis3_3dc_rates array initializer only specifies 10 values, which matches the datasheet. So it also contains 6 zero values at the end. Replace the WARN with a normal check, which treats an odr index of 0 as power-down and uses a normal dev_err() to report the error in case odr index point past the initialized part of the array. Fixes: 1510dd5954be ("lis3lv02d: avoid divide by zero due to unchecked") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=785814 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1817027 BugLink: https://bugs.centos.org/view.php?id=10720 Link: https://lore.kernel.org/r/20210217102501.31758-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman

lis3lv02d: switch to using input device polling mode

2019-10-10T13:24:19Z

Now that instances of input_dev support polling mode natively, we no longer need to create input_polled_dev instance. Signed-off-by: Dmitry Torokhov Link: https://lore.kernel.org/r/20191002215658.GA134561@dtor-ws Signed-off-by: Greg Kroah-Hartman

Merge 5.2-rc4 into char-misc-next

2019-06-09T07:11:21Z

We want the char/misc driver fixes in here as well. Signed-off-by: Greg Kroah-Hartman