summaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-06-13iio: accel: bmc150: Drop misleading/duplicate chip identifiersStephan Gerhold4-67/+37
Commit 0ad4bf370176 ("iio:accel:bmc150-accel: Use the chip ID to detect sensor variant") stopped using the I2C/ACPI match data to look up the bmc150_accel_chip_info. However, the bmc150_accel_chip_info_tbl remained as-is, with multiple entries with the same chip_id (e.g. 0xFA for BMC150/BMI055/BMA255). This is redundant now because actually the driver will always select the first entry with a matching chip_id. So even if a device probes e.g. with BMA0255 it will end up using the chip_info for BMC150. And in general that's fine for now, the entries for BMC150/BMI055/BMA255 were exactly the same anyway (except for the name, which is replaced with the more accurate one later). But in this case it's misleading because it suggests that one should add even more entries with the same chip_id when adding support for new variants. Let's make that more clear by removing the enum with the chip identifiers entirely and instead have only one entry per chip_id. Note that we may need to bring back some mechanism to differentiate between different chips with the same chip_id in the future. For example, BMA250 (currently supported by the bma180 driver) has the same chip_id = 0x03 as BMA222 even though they have different channel sizes (8 bits vs 10 bits). But in any case, that mechanism would need to look quite different from what we have right now. Cc: Bastien Nocera <hadess@hadess.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-4-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Clarify combo modules in KconfigStephan Gerhold1-2/+5
The Kconfig option currently says that all Bosch accelerometers supported by the bmc150-accel driver are combo chips with both accelerometer and magnetometer. This is wrong: actually only BMC150 is such a combo. The BMA* variants only contain an accelerometer and the BMI055 actually is a accelerometer + gyroscope combo. Clarify this in the help text and also make the list of supported variants complete and sorted for consistency. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-3-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Fix bma222 scale unitStephan Gerhold1-4/+5
According to sysfs-bus-iio documentation the unit for accelerometer values after applying scale/offset should be m/s^2, not g, which explains why the scale values for the other variants in bmc150-accel do not match exactly the values given in the datasheet. To get the correct values, we need to multiply the BMA222 scale values by g = 9.80665 m/s^2. Fixes: a1a210bf29a1 ("iio: accel: bmc150-accel: Add support for BMA222") Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-2-stephan@gerhold.net Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: dummy: Fix build error when CONFIG_IIO_TRIGGERED_BUFFER is not setWei Yongjun1-0/+1
Gcc reports build error when CONFIG_IIO_TRIGGERED_BUFFER is not set: riscv64-linux-gnu-ld: drivers/iio/dummy/iio_simple_dummy_buffer.o: in function `iio_simple_dummy_configure_buffer': iio_simple_dummy_buffer.c:(.text+0x2b0): undefined reference to `iio_triggered_buffer_setup_ext' riscv64-linux-gnu-ld: drivers/iio/dummy/iio_simple_dummy_buffer.o: in function `.L0 ': iio_simple_dummy_buffer.c:(.text+0x2fc): undefined reference to `iio_triggered_buffer_cleanup' Fix it by select IIO_TRIGGERED_BUFFER for config IIO_SIMPLE_DUMMY_BUFFER. Fixes: 738f6ba11800 ("iio: dummy: iio_simple_dummy_buffer: use triggered buffer core calls") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: frequency: adf4350: disable reg and clk on error in adf4350_probe()Yang Yingliang1-2/+4
Disable reg and clk when devm_gpiod_get_optional() fails in adf4350_probe(). Fixes:4a89d2f47ccd ("iio: adf4350: Convert to use GPIO descriptor") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210601142605.3613605-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bma180: Fix BMA25x bandwidth register valuesStephan Gerhold1-2/+7
According to the BMA253 datasheet [1] and BMA250 datasheet [2] the bandwidth value for BMA25x should be set as 01xxx: "Settings 00xxx result in a bandwidth of 7.81 Hz; [...] It is recommended [...] to use the range from ´01000b´ to ´01111b´ only in order to be compatible with future products." However, at the moment the drivers sets bandwidth values from 0 to 6, which is not recommended and always results into 7.81 Hz bandwidth according to the datasheet. Fix this by introducing a bw_offset = 8 = 01000b for BMA25x, so the additional bit is always set for BMA25x. [1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bma253-ds000.pdf [2]: https://datasheet.octopart.com/BMA250-Bosch-datasheet-15540103.pdf Cc: Peter Meerwald <pmeerw@pmeerw.net> Fixes: 2017cff24cc0 ("iio:bma180: Add BMA250 chip support") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210526094408.34298-2-stephan@gerhold.net Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13counter: intel-qep: Use to_pci_dev() helperJarkko Nikula1-2/+2
Use to_pci_dev() helper instead of container_of(d, struct pci_dev, dev); Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/20210611115558.796338-2-jarkko.nikula@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13counter: intel-qep: Mark PM callbacks with __maybe_unusedJarkko Nikula1-4/+2
Remove CONFIG_PM ifdef and mark PM callbacks with __maybe_unused. Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/20210611115558.796338-1-jarkko.nikula@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: adc: remove unused private data assigned with spi_set_drvdata()Alexandru Ardelean11-20/+0
These were usually used before the conversion to devm_ functions, so that the remove hook would be able to retrieve the pointer and do cleanups on remove. When the conversion happened, they should have been removed, but were omitted. Some drivers were copied from drivers that fit the criteria described above. In any case, in order to prevent more drivers from being used as example (and have spi_set_drvdata() needlessly set), this change removes it from the IIO ADC group. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210513111035.77950-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: imu: remove unused private data assigned with spi_set_drvdata()Alexandru Ardelean4-7/+0
These were usually used before the conversion to devm_ functions, so that the remove hook would be able to retrieve the pointer and do cleanups on remove. When the conversion happened, they should have been removed, but were omitted. Some drivers were copied from drivers that fit the criteria described above. In any case, in order to prevent more drivers from being used as example (and have spi_set_drvdata() needlessly set), this change removes it from the IIO IMU group. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210513122512.93187-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: adc: ad_sigma_delta: remove ad_sd_{setup,cleanup}_buffer_and_trigger()Alexandru Ardelean1-86/+0
Since all AD Sigma-Delta drivers now use the devm_ad_sd_setup_buffer_and_trigger() function, we can remove the old ad_sd_{setup,cleanup}_buffer_and_trigger() functions. This way we can discourage new drivers that use the ad_sigma_delta lib-driver to use these (older functions). Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210513120752.90074-13-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: adc: ad7124: Use devm_ managed calls for all of probe() + drop remove()Jonathan Cameron1-33/+15
As not many steps were not already devm_ managed, use devm_add_action_or_reset() to handle the rest. This also uses the new devm_ad_sd_setup_buffer_and_trigger() function. Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210513120752.90074-12-aardelean@deviqon.com
2021-06-13iio: adc: ad7192: convert to device-managed functionsAlexandru Ardelean1-53/+36
With the devm_ad_sd_setup_buffer_and_trigger() helper, it's a bit easier now to convert the probe of the AD7192 driver to use device-managed functions. The regulators and the mclk requires devm_add_action_or_reset() callbacks though. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210513120752.90074-11-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: adc: ad7192: use devm_clk_get_optional() for mclkAlexandru Ardelean1-3/+3
The devm_clk_get_optional() helper returns NULL when devm_clk_get() returns -ENOENT. This makes things slightly cleaner. The added benefit is mostly cosmetic. Also, a minor detail with this call, is that the reference for the parent device is taken as `spi->dev` instead of `&st->sd.spi->dev` (which looks a little quirky). Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210513120752.90074-10-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: adc: ad7780: convert to device-managed functionsAlexandru Ardelean1-28/+10
With the devm_ad_sd_setup_buffer_and_trigger() helper, it's a bit easier now to convert the probe of the AD7780 driver to use device-managed functions. Only the regulator disable requires a devm_add_action_or_reset() callback. This change does that, cleaning up the driver a bit. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210513120752.90074-9-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: adc: ad7791: convert to device-managed functionsAlexandru Ardelean1-31/+13
With the devm_ad_sd_setup_buffer_and_trigger() helper, it's a bit easier now to convert the probe of the AD7791 driver to use device-managed functions. Only the regulator disable requires a devm_add_action_or_reset() callback. This change does that, cleaning up the driver a bit. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210513120752.90074-8-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: adc: ad7793: convert to device-managed functionsAlexandru Ardelean1-38/+15
With the devm_ad_sd_setup_buffer_and_trigger() helper, it's a bit easier now to convert the probe of the AD7793 driver to use device-managed functions. Only the regulator disable requires a devm_add_action_or_reset() callback. This change does that, cleaning up the driver a bit. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210513120752.90074-7-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: adc: ad_sigma_delta: introduct devm_ad_sd_setup_buffer_and_trigger()Alexandru Ardelean1-0/+60
This is a version of ad_sd_setup_buffer_and_trigger() with all underlying functions (that are used) being replaced with their device-managed variants. One thing to take care here is with {devm_}iio_trigger_alloc(), where both functions take a parent-device object as the first parameter. To make sure nothing quirky is happening, the devm_ad_sd_probe_trigger() function is checking that the provided 'dev' reference is the same as the one stored on the 'struct ad_sigma_delta' driver data. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210513120752.90074-6-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: accel: bmc150: Set label based on accel-location for ACPI DUAL250E fwnodesHans de Goede1-0/+16
Some Yoga laptops with 1 accelerometer in the display and 1 in the base, use an ACPI HID of DUAL250E instead of BOSC0200. Set the iio-device's label for DUAL250E devices to a value indicating which sensor is which, mirroring how we do this for BOSC0200 dual sensor devices. Note the DUAL250E fwnode unfortunately does not include a mount-matrix. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210523170103.176958-10-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: accel: bmc150: Refactor bmc150_apply_acpi_orientation()Hans de Goede1-5/+13
Factor the BOSC0200 ACPI HID handling out into a new bmc150_apply_bosc0200_acpi_orientation() function and make bmc150_apply_acpi_orientation() call that when dealing with a BOSC0200 ACPI device (and make it return false otherwise). This is a preparation patch for adding special handling for other ACPI HIDs (the "DUAL250E" HID). Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210523170103.176958-9-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: accel: bmc150: Add support for DUAL250E ACPI DSM for setting the hinge ↵Hans de Goede3-0/+116
angle Some 360 degree hinges (yoga) style 2-in-1 devices use 2 bmc150 accels to allow the OS to determine the angle between the display and the base of the device, so that the OS can determine if the 2-in-1 is in laptop or in tablet-mode. On Windows both accelerometers are read (polled) by a special service and this service calls the DSM (Device Specific Method), which in turn translates the angles to one of laptop/tablet/tent/stand mode and then notifies the EC about the new mode and the EC then enables or disables the builtin keyboard and touchpad based in the mode. When the 2-in-1 is powered-on or resumed folded in tablet mode the EC senses this independent of the DSM by using a HALL effect sensor which senses that the keyboard has been folded away behind the display. At power-on or resume the EC disables the keyboard based on this and the only way to get the keyboard to work after this is to call the DSM to re-enable it. Call the DSM on probe() and resume() to fix the keyboard not working when powered-on / resumed in tablet-mode. This patch was developed and tested on a Lenovo Yoga 300-IBR. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210523170103.176958-8-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: accel: bmc150: Remove bmc150_set/get_second_device() accessor functionsHans de Goede3-24/+4
Now that the definition of the bmc150_accel_data struct is no longer private to bmc150-accel-core.c, bmc150-accel-i2c.c can simply directly access the second_dev member and the accessor functions are no longer necessary. Note if the i2c_acpi_new_device() for the second-client now fails, an ERR_PTR gets stored in data->second_dev this is fine since it is only ever passed to i2c_unregister_device() which has an IS_ERR_OR_NULL() check. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210523170103.176958-7-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: accel: bmc150: Move struct bmc150_accel_data definition to bmc150-accel.hHans de Goede2-53/+61
Further patches to bmc150-accel-i2c.c need to store some extra info (on top of the second_dev pointer) in the bmc150_accel_data struct, rather then adding yet more accessor functions for this lets just move the struct bmc150_accel_data definition to bmc150-accel.h. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210523170103.176958-6-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: accel: bmc150: Add support for dual-accelerometers with a DUAL250E HIDHans de Goede1-7/+12
The Lenovo Yoga 300-11IBR has a ACPI fwnode with a HID of DUAL250E which contains I2C and IRQ resources for 2 accelerometers, 1 in the display and one in the base of the device. Add support for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210523170103.176958-5-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: accel: bmc150: Move check for second ACPI device into a separate functionHans de Goede1-29/+51
Move the check for a second ACPI device for BOSC0200 ACPI fwnodes into a new bmc150_acpi_dual_accel_probe() helper function. This is a preparation patch for adding support for a new "DUAL250E" ACPI Hardware-ID (HID) used on some devices. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210523170103.176958-4-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: accel: bmc150: Don't make the remove function of the second ↵Hans de Goede3-4/+4
accelerometer unregister itself On machines with dual accelerometers described in a single ACPI fwnode, the bmc150_accel_probe() instantiates a second i2c-client for the second accelerometer. A pointer to this manually instantiated second i2c-client is stored inside the iio_dev's private-data through bmc150_set_second_device(), so that the i2c-client can be unregistered from bmc150_accel_remove(). Before this commit bmc150_set_second_device() took only 1 argument so it would store the pointer in private-data of the iio_dev belonging to the manually instantiated i2c-client, leading to the bmc150_accel_remove() call for the second_dev trying to unregister *itself* while it was being removed, leading to a deadlock and rmmod hanging. Change bmc150_set_second_device() to take 2 arguments: 1. The i2c-client which is instantiating the second i2c-client for the 2nd accelerometer and 2. The second-device pointer itself (which also is an i2c-client). This will store the second_device pointer in the private data of the iio_dev belonging to the (ACPI instantiated) i2c-client for the first accelerometer and will make bmc150_accel_remove() unregister the second_device i2c-client when called for the first client, avoiding the deadlock. Fixes: 5bfb3a4bd8f6 ("iio: accel: bmc150: Check for a second ACPI device for BOSC0200") Cc: Jeremy Cline <jeremy@jcline.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: accel: bmc150: Fix dereferencing the wrong pointer in ↵Hans de Goede1-7/+3
bmc150_get/set_second_device The drvdata for iio-parent devices points to the struct iio_dev for the iio-device. So by directly casting the return from i2c_get_clientdata() to struct bmc150_accel_data * the code was ending up storing the second_dev pointer in (and retrieving it from) some semi-random offset inside struct iio_dev, rather then storing it in the second_dev member of the bmc150_accel_data struct. Fix the code to get the struct bmc150_accel_data * pointer to call iio_priv() on the struct iio_dev * returned by i2c_get_clientdata(), so that the correct pointer gets dereferenced. This fixes the following oops on rmmod, caused by trying to dereference the wrong return of bmc150_get_second_device(): [ 238.980737] BUG: unable to handle page fault for address: 0000000000004710 [ 238.980755] #PF: supervisor read access in kernel mode [ 238.980760] #PF: error_code(0x0000) - not-present page ... [ 238.980841] i2c_unregister_device.part.0+0x19/0x60 [ 238.980856] 0xffffffffc0815016 [ 238.980863] i2c_device_remove+0x25/0xb0 [ 238.980869] __device_release_driver+0x180/0x240 [ 238.980876] driver_detach+0xd4/0x120 [ 238.980882] bus_remove_driver+0x5b/0xd0 [ 238.980888] i2c_del_driver+0x44/0x70 While at it also remove the now no longer sensible checks for data being NULL, iio_priv never returns NULL for an iio_dev with non 0 sized private-data. Fixes: 5bfb3a4bd8f6 ("iio: accel: bmc150: Check for a second ACPI device for BOSC0200") Cc: Jeremy Cline <jeremy@jcline.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09iio: light: si1145: Drop use of %hhx format specifier.Jonathan Cameron1-5/+5
Since: commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") use of these format strings has been discouraged. As there are only a few such instances in IIO, this is part of a series clearing them out so they don't get copied into new drivers. Use the 0x02x form as the length specifier when used with # includes the 0x prefix and is very unlikely to be what was intended by the author. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210603180612.3635250-5-jic23@kernel.org
2021-06-09iio: imu: inv_mpu6050: Drop use of %hhx format string.Jonathan Cameron1-3/+2
Since: commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") use of these format strings has been discouraged. Use the 0x02x form as the length specifier when used with # includes the 0x prefix and is very unlikely to be what was intended by the author. Part of a series removing all uses from IIO in the interestings of avoiding providing bad examples for people to copy. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210603180612.3635250-4-jic23@kernel.org
2021-06-09iio: light: si1133: Drop remaining uses of %hhx format string.Jonathan Cameron1-7/+7
Since: commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") use of these format strings has been discouraged. Use the 0x02x form as the length specifier when used with # includes the 0x prefix and is very unlikely to be what was intended by the author. As there are not that many in IIO, this is part of an effort to clear them out so we don't have any instances that might get copied into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> Cc: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210603180612.3635250-3-jic23@kernel.org
2021-06-09iio: si1133: fix format string warningsArnd Bergmann1-2/+2
clang complains about multiple instances of printing an integer using the %hhx format string: drivers/iio/light/si1133.c:982:4: error: format specifies type 'unsigned char' but the argument has type 'unsigned int' [-Werror,-Wformat] part_id, rev_id, mfr_id); ^~~~~~~ Print them as a normal integer instead, leaving the "#02" length modifier. Use the 0x02x form as the length specifier when used with # includes the 0x prefix and is very unlikely to be what was intended by the author. Fixes: e01e7eaf37d8 ("iio: light: introduce si1133") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210603180612.3635250-2-jic23@kernel.org
2021-06-09counter: stm32-timer-cnt: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch adds the const qualifier to the stm32_synapse_actions to match actions_list. Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/9675edda958ee2ca371d271f46445d3e1934ba82.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: stm32-lptimer-cnt: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch adds the const qualifier to the stm32_lptim_cnt_synapse_actions to match actions_list. Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/785e0daa3633923ede42394f423fcf94c4469154.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: microchip-tcb-capture: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch adds the const qualifier to the mchp_tc_synapse_actions to match actions_list. Cc: Kamel Bouhara <kamel.bouhara@bootlin.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/165f9682ce308a60a477aaa56fdae7bc949dc218.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: ftm-quaddec: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch adds the const qualifier to the ftm_quaddec_synapse_actions to match actions_list. Cc: Patrick Havelange <patrick.havelange@essensium.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/db1df2021efb1b98e6d1a50787be5a52a1896574.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: 104-quad-8: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-2/+2
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch adds the const qualifier to the quad8_index_actions_list and quad8_synapse_actions_list to match actions_list. Acked-by: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/776ba3ad0a3c609d3600cffe0ed6446baf29fee9.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: stm32-timer-cnt: Add const qualifier for functions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_count functions_list member expects a const enum counter_count_function array. This patch adds the const qualifier to the stm32_count_functions to match functions_list. Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/46a1e7096dd9280d8f241894186b3c903956a55f.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: stm32-lptimer-cnt: Add const qualifier for functions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_count functions_list member expects a const enum counter_count_function array. This patch adds the const qualifier to the stm32_lptim_cnt_functions to match functions_list. Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/08830119594acdb3bc9d36ae2e65b2eb26589ade.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: microchip-tcb-capture: Add const qualifier for functions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_count functions_list member expects a const enum counter_count_function array. This patch adds the const qualifier to the mchp_tc_count_functions to match functions_list. Cc: Kamel Bouhara <kamel.bouhara@bootlin.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/74cb91ab7b459563762ec28633cd8808093aa2ad.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: interrupt-cnt: Add const qualifier for functions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_count functions_list member expects a const enum counter_count_function array. This patch adds the const qualifier to the interrupt__cnt_functions to match functions_list. Cc: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/86f7fb77f703cf2508a6b4ee9cf80aa523392976.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: 104-quad-8: Add const qualifier for functions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_count functions_list member expects a const enum counter_count_function array. This patch adds the const qualifier to the quad8_count_functions_list to match functions_list. Acked-by: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/6847da7553208e7f2554e6c7688e2021f7e19716.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: 104-quad-8: Add const qualifiers for quad8_preset_register_setWilliam Breathitt Gray1-2/+2
Add some safety by qualifying the quad8_preset_register_set() function parameters as const. Acked-by: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/050f1b518eeae8e3683f7d6d11f3219a137adf48.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: 104-quad-8: Annotate hardware config module parameterWilliam Breathitt Gray1-1/+1
When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates the 104-QUAD-8 driver. Acked-by: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/97ce79878a26809f0b15b2eac9a86ca39e0ecd74.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: 104-quad-8: Remove pointless commentWilliam Breathitt Gray1-1/+0
It is obvious that devm_counter_register() is used to register a Counter device, so a comment stating such is pointless here. Acked-by: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/77e9f3daa091d0ad0ee56b8973705dd03db85dd4.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09Merge tag 'iio-for-5.14a' of ↵Greg Kroah-Hartman176-1380/+7156
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: 1st set of new IIO/counter device support, features and cleanup for 5.14 There are a couple of large cleanup sets in here alongside a number of new drivers. Note an immutable branch merged to add a stub for i2c_verify_client() as needed to avoid a build issue in the fxls8962af driver as a result of a workaround for a device errata that only applies when i2c interface is used. Counters ======== New device support * intel,quadrature encoder peripheral found on Elkhart Lake platforms. - New driver. IIO === New device support * amstaos,tsl2591 ambient light sensor. - New driver + bindings - Follow up fix to ensure some local variables are suitable for error handling. * fsl,fxls8962af + fsl,fxls8964af accelerometers - New driver + bindings - Includes an errata work around that cause a build bot failure fixed by adding a stub to i2c. * kionix,kxcjk-1013 - Add support for KX023-1025 device. Mostly a different register map that needed to be supported. * murata,sca3300 accelerometer - New driver + bindings * st,lsm9ds0 IMU - Rework of st,sensors driver to cleanly support this new glue driver that enables the two parts of the LSM9DS0. * ti,tsc2046 touchscreen controller ADC. - New driver. Intent here is to use this with existing IIO consumer drivers such as resistive-adc-touch. - Follow up fix to avoid an issue with unsigned subtraction in error check. * ti,tmp117 digital temperature sensor - New driver + bindings Features * adi,ad5755 - Add missing dt-binding doc * adi,ad7298 - Add ACPI ID used on Intel Galileo Gen 1 boards. - Add missing dt-binding doc * adi,ad7476 - Add missing dt-binding doc * adi,ad7746 - Add missing dt-binding doc for this driver that will hopefully move out of staging shortly. Update staging driver to use the binding instead of platform data. * adi,adis16201 + adis16209 - Add missing dt-binding doc * adi,adis16480 - Support burst mode for adis16495 and adis16497 parts. * bosch,bma220 - Add missing dt-binding doc * fsl,mma7455 - Add missing dt-binding doc * iio-rescale - Support handling of processed channels from provider. Some ADCs require (typically non linear) calibration functions to be applied, and so provide only IIO_CHAN_INFO_PROCESSED read back. They can be used as providers to the iio-rescale driver which needs to handle them somewhat differently from IIO_CHAN_INFO_RAW * sensiron,sps30 - Support the serial interface. Note this required significant refactoring of existing driver. * st,st-sensors - Add mount matrix support for normal dt-binding whilst continuing to support the odd ACPI approach for accelerometers. * ti,dac082s085 + similar - Add missing dt-binding doc * trivial-devices - add entries for - memsic,mx4005, memsic,mx6255 and memsic,mxc6655 - sensortek,stk8312 and sensortek,stk8ba50 Cleanup / minor fixes * core - Use devm_add_action_or_reset() to replace boilerplate in several driver and core IIO devm_* functions. - Fix an error path issue introduced by above, that could return an error pointer rather than the expected null from dev_iio_device_alloc() - Move more IIO internals related fields from struct iio_dev to struct iio_dev_opaque. - Drop unused final update of in_loc in demux setup. * Docs - Move some docs from driver specific to core dos to avoid replication of names which the documentation builder does not allow. Note this means adding a few device specific notes to the general docs to cover the more unusual uses of the ABI. - ABI: Move old buffer/* and scan_elements/* docs to obsolete as now we have the bufferX/* variant. Not we are not getting rid of these interfaces, just encouraging new code to use the new interface. * IIO wide: - Tidy up new cases of dev.parent etc being set in drivers as the core now does it. - Fix more cases of possible miss-aligned buffers when passed to iio_push_to_buffers_with_timestamp(). Note we only have one known instance of anyone seeing this bug actually happening, so this has been a low priority cleanup effort for several cycles. - sysfs_emit() used in more drivers. - Runtime pm tidy up and use of pm_runtime_resume_and_get() - Buffer alignment fixes as iio_push_to_buffers_with_timestamp requires that the timestamp when inserted by naturally aligned + consumers can assume that all fields are naturally aligned. Part of a long running effort, with at least 2 more series to come tackling additional variants. - Stop specifying "mount-matrix" property name in every lookup of the mount matrix from firmware by hard coding it in the core. * adi,ad7476 - Handle the variety of different regulators used by the parts supported by this driver (came up in dt-binding review) * adi,ad7746 - Trivial drop of if (ret) return ret; return 0; pattern - Tidy up comments - Pull capdac setup out to own function. * adi,ad7766 - Trivial drop of if (ret) return ret; return 0; pattern * adi,adis - Avoid returning error codes in interrupt handlers. - Handle a failure in spi_write in the trigger handler. - Rework to add updating of device page after changing it. - Don't push data to IIO buffers when read failed. - Add configuration of burst max speed to core avoid handling this in each driver. - Use the adis_dev_lock() helper in adis16260 and adis16136 drivers. - Excessive includes cleanup via include-what-you-use static checker after zero day highlighted that these needed updating. * afe - Amend binding to add #io-channel-cells, thus allowing this IIO consumer to also be an IIO provider. * aosong,am2315 - Drop ACPI id. Unlikely this one is in the wild and it isn't valid ACPI naming. * bosch,bma180 - Adding missing bandwidth settings (500, 1000 Hz) * bosch,bme680 - Drop ACPI id. Unlikely this one is in the wild and it isn't valid ACPI naming. * ep93xx_adc, - Drop a redundant error print. * maxim,max118 - Convert remainder of probe() to devm_ managed functions. - Avoid some repeated jumping back and forth between iio_dev and spi structures. * maxim,max11100 - Use get_unaligned_be16() instead of open coding. - Convert remainder of probe() to devm_ managed functions. * samsung,exynos_adc - Unused error value dropped. * sensiron,sgp30 - Drop use of %hx in favor of %x and letting the normal type conversion work. * sensortek,stk8312 - Add lowercase device id and note uppercase version deprecated. - Drop ACPI id. Unlikely this one is in the wild and it isn't valid ACPI naming. * sprx,sc72xx_adc - add MODULE_DEVICE_TABLE * st,lsm6dsx - Fix docs of valid ODRs * st,sensors - dt-binding rework. Two efforts on this crossed in a previous cycle so this update cherry picks the best of the two yaml conversions. - Don't copy the channel spec array as now ext_info is no longer modified. * st,stm32-adc - tidy up some docs that were marked as kernel-doc but aren't. * ti,adc081c, ti,adc0832, ti,adc108s102 and ti,adc161s626 - Convert remainder of probe() functions to devm_ managed functions to simplify error handing and remove paths. * tag 'iio-for-5.14a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (171 commits) i2c: core: Add stub for i2c_verify_client() if !CONFIG_I2C iio: adis: Cleanout unused headers iio: accel: bma180: Add missing 500 Hz / 1000 Hz bandwidth counter: Add support for Intel Quadrature Encoder Peripheral staging: iio: cdc: ad7746: extract capac setup to own function staging: iio: cdc: ad7746: clean up probe return staging: iio: cdc: ad7746: remove ordinary comments iio: adc: ti-adc161s626: Use devm managed functions for all of probe. iio: adc: ti-adc108s102: Use devm managed functions for all of probe() iio: adc: ti-adc0832: Use devm managed functions for all of probe() iio: adc: ti-adc081c: Use devm managed functions for all of probe() iio: adc: max1118: Avoid jumping back and forth between spi and iio structures iio: adc: max1118: Use devm_ managed functions for all of probe iio: adc: max11100: Use devm_ functions for rest of probe() iio: adc: max11100: Use get_unaligned_be16() rather than opencoding. iio: chemical: sgp30: Drop use of %hx in format string. iio: gyro: st_gyro: Support mount matrix iio: magnetometer: st_magn: Support mount matrix iio: accel: st_sensors: Stop copying channels iio: accel: st_sensors: Support generic mounting matrix ...
2021-06-09staging: rtl8712: Remove unnecessary alias of printk()Fabio M. De Francesco2-24/+1
This module defines four alias for printk(). Removed them all, because they are not used anywhere else in the driver. Converted the only exception to the explicit use of printk(). Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20210606034038.9657-1-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-04staging: vchiq_core: introduce handle_pollStefan Wahren1-40/+52
The function slot_handler_func() has very deep indentations. Moving the poll handling into separate function could improve the readability. Use the return value to keep the poll_needed handling at the same place. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1622735405-9980-17-git-send-email-stefan.wahren@i2se.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-04staging: vchiq_connected: move EXPORT_SYMBOL below the right functionStefan Wahren1-1/+1
It's more intuitive to have the EXPORT_SYMBOL() call below the matching definition. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1622735405-9980-16-git-send-email-stefan.wahren@i2se.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-04staging: vchiq_core: store message id in local variableStefan Wahren1-16/+12
Some queue_message() calls are still rather complex to read. So store the message ids in a local variable in those cases. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1622735405-9980-15-git-send-email-stefan.wahren@i2se.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-04staging: vchiq_core: reduce indentation in parse_openStefan Wahren1-76/+70
The function parse_open() already has bail out sections like fail_open. So use a goto for the other error cases like payload size is too small and listening service cannot be found. This avoids two indentation levels. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1622735405-9980-14-git-send-email-stefan.wahren@i2se.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>