#
0a33755c |
|
03-Oct-2022 |
Matti Vaittinen <mazziesaccount@gmail.com> |
iio: Don't silently expect attribute types The iio_triggered_buffer_setup_ext() and the devm_iio_kfifo_buffer_setup_ext() were changed by commit 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") to silently expect that all attributes given in buffer_attrs array are device-attributes. This expectation was not forced by the API - and some drivers did register attributes created by IIO_CONST_ATTR(). When using IIO_CONST_ATTRs the added attribute "wrapping" does not copy the pointer to stored string constant and when the sysfs file is read the kernel will access to invalid location. Change the function signatures to expect an array of iio_dev_attrs to avoid similar errors in the future. Merge conflict resolved whilst applying due to patch crossing with two new drivers (kx022a accelerometer and ad4130 ADC). Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/63f54787a684eb1232f1c5d275a09c786987fe4a.1664782676.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
c02b2a51 |
|
03-Oct-2022 |
Matti Vaittinen <mazziesaccount@gmail.com> |
iio: bmc150-accel-core: Use IIO_STATIC_CONST_DEVICE_ATTR() Slightly simplify by dropping open-coded constant data iio_dev_attr functions and using the IIO_STATIC_CONST_DEVICE_ATTR() instead. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/b1b0d662705b43d68594639fb7719bc431101f79.1664782676.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
a10a0f38 |
|
03-Oct-2022 |
Matti Vaittinen <mazziesaccount@gmail.com> |
iio: bmc150-accel-core: Fix unsafe buffer attributes The iio_triggered_buffer_setup_ext() was changed by commit 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") to silently expect that all attributes given in buffer_attrs array are device-attributes. This expectation was not forced by the API - and some drivers did register attributes created by IIO_CONST_ATTR(). The added attribute "wrapping" does not copy the pointer to stored string constant and when the sysfs file is read the kernel will access to invalid location. Change the IIO_CONST_ATTRs from the driver to IIO_DEVICE_ATTR in order to prevent the invalid memory access. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") Link: https://lore.kernel.org/r/cf8a56658fc38db8bed64f456d898f5ad5a2814f.1664782676.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
8c576f87 |
|
07-Feb-2022 |
Miquel Raynal <miquel.raynal@bootlin.com> |
iio: core: Hide read accesses to iio_dev->currentmode In order to later move this variable within the opaque structure, let's create a helper for accessing it in read-only mode. This helper will be exposed to device drivers and kept accessible for the few that could need it. The write access to this variable however should be fully reserved to the core so in a second step we will hide this variable into the opaque structure. Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-11-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
26b74d85 |
|
16-Jan-2022 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio:accel:bmc150: Move exports into IIO_BMC150 namespace To avoid unnecessary pollution of the global symbol namespace move the driver core exports into their own namespace and import that into the two bus modules. For more info see https://lwn.net/Articles/760045/ Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20220116180535.2367780-10-jic23@kernel.org
|
#
632fe0bb |
|
06-Jan-2022 |
Miaoqian Lin <linmq006@gmail.com> |
iio: Fix error handling for PM The pm_runtime_enable will increase power disable depth. If the probe fails, we should use pm_runtime_disable() to balance pm_runtime_enable(). In the PM Runtime docs: Drivers in ->remove() callback should undo the runtime PM changes done in ->probe(). Usually this means calling pm_runtime_disable(), pm_runtime_dont_use_autosuspend() etc. We should do this in error handling. Fix this problem for the following drivers: bmc150, bmg160, kmx61, kxcj-1013, mma9551, mma9553. Fixes: 7d0ead5c3f00 ("iio: Reconcile operation order between iio_register/unregister and pm functions") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220106112309.16879-1-linmq006@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
f3d29c85 |
|
28-Nov-2021 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio:accel:bmc150: Mark structure __maybe_unused as only needed with for pm ops. If CONFIG_PM not set then clang warns this structure is unused. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-12-jic23@kernel.org
|
#
9713964f |
|
13-Oct-2021 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
iio: accel: bmc150: Make bmc150_accel_core_remove() return void Up to now bmc150_accel_core_remove() 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 <u.kleine-koenig@pengutronix.de> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211013203223.2694577-3-u.kleine-koenig@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
c02cd5c1 |
|
07-Oct-2021 |
Alexandru Ardelean <alexandru.ardelean@analog.com> |
iio: triggered-buffer: extend support to configure output buffers Now that output (kfifo) buffers are supported, we need to extend the {devm_}iio_triggered_buffer_setup_ext() parameter list to take a direction parameter. This allows us to attach an output triggered buffer to a DAC device. Unfortunately it's a bit difficult to add another macro to avoid changing 5 drivers where {devm_}iio_triggered_buffer_setup_ext() is used. Well, it's doable, but may not be worth the trouble vs just updating all these 5 drivers. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Link: https://lore.kernel.org/r/20211007080035.2531-4-mihail.chindris@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
52ae7c70 |
|
02-Aug-2021 |
Stephan Gerhold <stephan@gerhold.net> |
iio: accel: bmc150: Add support for BMC156 BMC156 is another accelerometer that works just fine with the bmc150-accel driver. It's very similar to BMC150 (also a accelerometer + magnetometer combo) but with only one accelerometer interrupt pin. It would make sense if only INT1 was exposed but someone at Bosch decided to only have an INT2 pin. Try to deal with this by making use of the INT2 support introduced in the previous commit and force using INT2 for BMC156. To detect that we need to bring up a simplified version of the previous type IDs. Note that unlike the type IDs removed in commit c06a6aba6835 ("iio: accel: bmc150: Drop misleading/duplicate chip identifiers") here I only add one for the special case of BMC156. Everything else still happens by reading the CHIP_ID register since the chip type information often is not accurate in ACPI tables. Tested-by: Nikita Travkin <nikita@trvn.ru> # BMC156 Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210802155657.102766-5-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
73d672e6 |
|
02-Aug-2021 |
Stephan Gerhold <stephan@gerhold.net> |
iio: accel: bmc150: Make it possible to configure INT2 instead of INT1 Some Bosch accelerometers have two interrupt pins (INT1 and INT2). At the moment, the driver uses only the first one, which is fine for most situations. However, some boards might only have INT2 connected for some reason. Add the necessary bits and configuration to set up INT2. Then try to detect this situation at least for device tree setups by checking if the first interrupt (the one picked by the I2C/SPI core) is actually named "INT2" using the interrupt-names property. of_irq_get_byname() returns either 0 or some error code in case the driver probed without device tree, so in all other cases we fall back to configuring INT1 as before. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210802155657.102766-4-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
e2a73c4e |
|
11-Jun-2021 |
Stephan Gerhold <stephan@gerhold.net> |
iio: accel: bmc150: Use more consistent and accurate scale values It is quite strange that BMA222 and BMA222E have very close, yet subtly different values in their scale tables. Comparing the datasheets this is simply because the "Resolution" for the different measurement ranges are documented with different precision. For example, for +-2g the BMA222 datasheet [1] suggests a resolution of 15.6 mg/LSB, while the BMA222E datasheet [2] suggests 15.63 mg/LSB. Actually, there is no need to rely on the resolution given by the Bosch datasheets. The resolution and scale can be calculated more consistently and accurately using the range (e.g. +-2g) and the channel size (e.g. 8 bits). Distributing 4g (-2g to 2g) over 8 bits results in an exact resolution of (4g / 2^8) = 15.625 mg/LSB which is the same value as in both datasheets, just slightly more accurate. Multiplying g = 9.80665 m/s^2 we get a more accurate value for the IIO scale table. Generalizing this we can calculate the scale tables more accurately using (range / 2^bits) * g * 10^6 (because of IIO_VAL_INT_PLUS_MICRO). Document this and make the scale tables more consistent and accurate for all the variants using that formula. Now the scale tables for BMA222 and BMA222E are consistent and probably slightly more accurate. [1]: https://media.digikey.com/pdf/Data%20Sheets/Bosch/BMA222.pdf [2]: https://www.mouser.com/datasheet/2/783/BST-BMA222E-DS004-06-1021076.pdf Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Andy Shevchenko <andy.shevchenko@gnail.com> Link: https://lore.kernel.org/r/20210611182442.1971-1-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
a7ba1c24 |
|
11-Jun-2021 |
Stephan Gerhold <stephan@gerhold.net> |
iio: accel: bma180/bmc150: Move BMA254 to bmc150-accel driver Commit c1d1c4a62db5 ("iio: accel: bma180: BMA254 support") added BMA254 support to the bma180 driver and changed some naming to BMA25x to make it easier to add support for BMA253 and BMA255. Unfortunately, there is quite some overlap between the bma180 driver and the bmc150-accel driver. Back when the commit was made, the bmc150-accel driver actually already had support for BMA255, and adding support for BMA254 would have been as simple as adding a new compatible to bmc150-accel. The bmc150-accel driver is a bit better for BMA254 since it also supports the motion trigger/interrupt functionality. Fortunately, moving BMA254 support over to bmc150-accel is fairly simple because the drivers have compatible device tree bindings. Revert most of the changes for BMA254 support in bma180 and move BMA254 over to bmc150-accel. This has the following advantages: - Support for motion trigger/interrupt - Fix incorrect scale values (BMA254 currently uses the same as BMA250 but actually they're different because of 10 vs 12 bits data size) - Less code than before :) BMA250 could be potentially also moved but it's more complicated because its chip_id conflicts with the one for BMA222 in bmc150-accel. Perhaps there are also other register differences, I did not investigate further yet (and I have no way to test it). Cc: Peter Meerwald <pmeerw@pmeerw.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-11-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
49e95c68 |
|
11-Jun-2021 |
Stephan Gerhold <stephan@gerhold.net> |
iio: accel: bmc150: Add device IDs for BMA253 BMA253 is mostly like BMA255 and has exactly the same register layout as used by the bmc150-accel driver as far I can tell. Making it work is as simple as adding new device IDs for it since it has the same chip_id = 0xFA (250) as BMA255 and others. 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-8-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
88e63ce6 |
|
11-Jun-2021 |
Stephan Gerhold <stephan@gerhold.net> |
iio: accel: bmc150: Sort all chip names alphabetically / by chip ID Right now all the device IDs are listed in seemingly random order, make this consistent by ordering those alphabetically. Also, order bmc150_accel_chip_info_tbl by chip ID for the same reason. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.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-6-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
54b61203 |
|
11-Jun-2021 |
Stephan Gerhold <stephan@gerhold.net> |
iio: accel: bmc150: Drop duplicated documentation of supported chips The chips supported by the bmc150-accel driver are clearly documented in Kconfig, in the bmc150_accel_chip_info_tbl as well as in all the device ID tables in the I2C/SPI drivers. It's easy to forget to update the lists in the file header. Drop those entirely to reduce the amount of changes required to add new chip variants. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-5-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
c06a6aba |
|
11-Jun-2021 |
Stephan Gerhold <stephan@gerhold.net> |
iio: accel: bmc150: Drop misleading/duplicate chip identifiers 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>
|
#
6e2a90af |
|
11-Jun-2021 |
Stephan Gerhold <stephan@gerhold.net> |
iio: accel: bmc150: Fix bma222 scale unit 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>
|
#
e6148fe7 |
|
23-May-2021 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Set label based on accel-location for ACPI DUAL250E fwnodes 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>
|
#
61ddd0a7 |
|
23-May-2021 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Refactor bmc150_apply_acpi_orientation() 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>
|
#
addab6fe |
|
23-May-2021 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Add support for DUAL250E ACPI DSM for setting the hinge 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>
|
#
35157f44 |
|
23-May-2021 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Remove bmc150_set/get_second_device() accessor functions 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>
|
#
ba8bd0b3 |
|
23-May-2021 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Move struct bmc150_accel_data definition to bmc150-accel.h 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>
|
#
f407e2dc |
|
23-May-2021 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Don't make the remove function of the second 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>
|
#
f2bf22dc |
|
23-May-2021 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Fix dereferencing the wrong pointer in 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>
|
#
b892770a |
|
18-May-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
iio: Drop Duplicated "mount-matrix" parameter All of the users of iio_read_mount_matrix() are using the very same property name. Moreover, the property name is hard coded in the API documentation. Make this clear and avoid duplication now and in the future. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Sean Nyekjaer <sean@geanix.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210518112546.44592-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
d3a8969d |
|
08-May-2021 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio: accel: bmc150-accel: Balanced runtime pm + use pm_runtime_resume_and_get() A call to pm_runtime_put_noidle() doesn't match any call that would result in a get(). It is safe because runtime pm core protects against the reference counter going 0, but it makes it harder to understand the code. Whilst here use pm_runtime_resume_and_get() to tidy things up. The Coccinelle script didn't get this one due to more complex code structure. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210509113354.660190-5-jic23@kernel.org
|
#
15ea2878 |
|
26-Apr-2021 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio: core: move @id from struct iio_dev to struct iio_dev_opaque Continuing from Alexandru Ardelean's introduction of the split between driver modifiable fields and those that should only be set by the core. This could have been done in two steps to make the actual move after introducing iio_device_id() but there seemed limited point to that given how mechanical the majority of the patch is. Includes fixup from Alex for missing mxs-lradc-adc conversion. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210426174911.397061-2-jic23@kernel.org
|
#
8a225220 |
|
09-Mar-2021 |
Gwendal Grignou <gwendal@chromium.org> |
iio: fix devm_iio_trigger_alloc with parent.cocci Use cocci semantic patch: @@ expression trigger, P; @@ trigger = devm_iio_trigger_alloc(P, ...); ... - trigger->dev.parent = P; To remove trigger->dev.parent, since it is set by default. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210309193620.2176163-3-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
788348a5 |
|
07-Feb-2021 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Set label based on accel-location on 2-accel yoga-style 2-in-1s Some 2-in-1 laptops / convertibles with 360° (yoga-style) hinges, use 2 bmc150 accelerometers, defined by a single BOSC0200 ACPI device node (1 in their base and 1 in their display). Since in this case we know the location of each accelerometer, set the label for the accelerometers to the standardized "accel-display" resp. "accel-base" labels. This way userspace can use the labels to get the location. This was tested on a Lenovo ThinkPad Yoga 11e 4th gen (N3450 CPU). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210207160901.110643-3-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
8a067200 |
|
30-Nov-2020 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Get mount-matrix from ACPI bmc150 accelerometers with an ACPI hardware-id of BOSC0200 have an ACPI method providing their mount-matrix, add support for retrieving this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201130141954.339805-3-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
5bfb3a4b |
|
30-Nov-2020 |
Jeremy Cline <jeremy@jcline.org> |
iio: accel: bmc150: Check for a second ACPI device for BOSC0200 Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI device. Normally we would handle this by letting the special drivers/platform/x86/i2c-multi-instantiate.c driver handle the BOSC0200 ACPI id and let it instantiate 2 bmc150_accel type i2c_client-s for us. But doing so changes the modalias for the first accelerometer (which is already supported and used on many devices) from acpi:BOSC0200 to i2c:bmc150_accel. The modalias is not only used to load the driver, but is also used by hwdb matches in /lib/udev/hwdb.d/60-sensor.hwdb which provide a mountmatrix to userspace by setting the ACCEL_MOUNT_MATRIX udev property. Switching the handling of the BOSC0200 over to i2c-multi-instantiate.c will break the hwdb matches causing the ACCEL_MOUNT_MATRIX udev prop to no longer be set. So switching over to i2c-multi-instantiate.c is not an option. Changes by Hans de Goede: -Add explanation to the commit message why i2c-multi-instantiate.c cannot be used -Also set the dev_name, fwnode and irq i2c_board_info struct members for the 2nd client Signed-off-by: Jeremy Cline <jeremy@jcline.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201130141954.339805-2-hdegoede@redhat.com BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198671 Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
e488fed0 |
|
30-Nov-2020 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Removed unused bmc150_accel_dat irq member The bmc150_accel_dat struct irq member is only ever used inside bmc150_accel_core_probe, drop it and just use the function argument directly. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201130141954.339805-1-hdegoede@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
eca8523a |
|
20-Sep-2020 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio:trigger: rename try_reenable() to reenable() plus return void As we no longer support a try again if we cannot reenable the trigger rename the function to reflect this. Also we don't do anything with the value returned so stop it returning anything. For the few drivers that didn't already print an error message in this patch, add such a print. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Christian Oder <me@myself5.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Nishant Malpani <nish.malpani25@gmail.com> Cc: Daniel Baluta <daniel.baluta@oss.nxp.com> Link: https://lore.kernel.org/r/20200920132548.196452-3-jic23@kernel.org
|
#
672f3022 |
|
15-Nov-2020 |
Linus Walleij <linus.walleij@linaro.org> |
iio: accel: bmc150-accel: Add rudimentary regulator support These Bosch accelerometers have two supplies, VDD and VDDIO. Add some rudimentary support to obtain and enable these regulators during probe() and disable them during remove() or on the errorpath. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201115205745.618455-3-linus.walleij@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
a1a210bf |
|
15-Nov-2020 |
Linus Walleij <linus.walleij@linaro.org> |
iio: accel: bmc150-accel: Add support for BMA222 This adds support for the BMA222 version of this sensor, found in for example the Samsung GT-I9070 mobile phone. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201115205745.618455-2-linus.walleij@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
1864c829 |
|
29-Sep-2020 |
Alexandru Ardelean <alexandru.ardelean@analog.com> |
iio: accel: bmc150: use iio_triggered_buffer_setup_ext() This change switches to the new iio_triggered_buffer_setup_ext() function and removes the iio_buffer_set_attrs() call, for assigning the HW FIFO attributes to the buffer. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200929125949.69934-6-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
a6f86f72 |
|
22-Jul-2020 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio:accel:bmc150-accel: Fix timestamp alignment and prevent data leak. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment ensured by use of an explicit c structure. This data is allocated with kzalloc so no data can leak appart from previous readings. Fixes tag is beyond some major refactoring so likely manual backporting would be needed to get that far back. Whilst the force alignment of the ts is not strictly necessary, it does make the code less fragile. Fixes: 3bbec9773389 ("iio: bmc150_accel: add support for hardware fifo") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: <Stable@vger.kernel.org>
|
#
f11d59d8 |
|
25-May-2020 |
Lars-Peter Clausen <lars@metafoo.de> |
iio: Move attach/detach of the poll func to the core All devices using a triggered buffer need to attach and detach the trigger to the device in order to properly work. Instead of doing this in each and every driver by hand move this into the core. At this point in time, all drivers should have been resolved to attach/detach the poll-function in the same order. This patch removes all explicit calls of iio_triggered_buffer_postenable() & iio_triggered_buffer_predisable() in all drivers, since the core handles now the pollfunc attach/detach. The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's not immediately obvious that removing the hooks doesn't break anything. Eugen was able to test on at91-sama5d2-adc driver, sama5d2-xplained board. All seems to be fine. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Tested-by: Eugen Hristev <eugen.hristev@microchip.com> #for at91-sama5d2-adc Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
d3be8324 |
|
22-May-2020 |
Alexandru Ardelean <alexandru.ardelean@analog.com> |
iio: remove explicit IIO device parent assignment This patch applies the semantic patch: @@ expression I, P, SP; @@ I = devm_iio_device_alloc(P, SP); ... - I->dev.parent = P; It updates 302 files and does 307 deletions. This semantic patch also removes some comments like '/* Establish that the iio_dev is a child of the i2c device */' But this is is only done in case where the block is left empty. The patch does not seem to cover all cases. It looks like in some cases a different variable is used in some cases to assign the parent, but it points to the same reference. In other cases, the block covered by ... may be just too big to be covered by the semantic patch. However, this looks pretty good as well, as it does cover a big bulk of the drivers that should remove the parent assignment. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
6c59a962 |
|
28-Aug-2019 |
Pascal Bouwmann <bouwmann@tau-tec.de> |
iio: fix center temperature of bmc150-accel-core The center temperature of the supported devices stored in the constant BMC150_ACCEL_TEMP_CENTER_VAL is not 24 degrees but 23 degrees. It seems that some datasheets were inconsistent on this value leading to the error. For most usecases will only make minor difference so not queued for stable. Signed-off-by: Pascal Bouwmann <bouwmann@tau-tec.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
2025cf9e |
|
29-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 288 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms and conditions of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 263 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.208660670@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ce7afa5c |
|
19-Apr-2019 |
Mohan Kumar <mohankumar718@gmail.com> |
iio:accel:Switch hardcoded function name with a reference to __func__ making the code more maintainable It fixes the following checkpatch.pl warning: WARNING: Prefer using '"%s...", __func__' to using function's name, in a string Signed-off-by: Mohan Kumar <mohankumar718@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
3c35e20a |
|
21-Feb-2019 |
H. Nikolaus Schaller <hns@goldelico.com> |
iio: accel: bmc150: add mount matrix support This patch allows to read a mount-matrix device tree property and report to user-space or in-kernel iio clients. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
5cb0789d |
|
24-Apr-2018 |
Charles Keepax <ckeepax@opensource.cirrus.com> |
iio: accel: bcm150: Remove handling for regmap raw_read_max The regmap core now handles splitting up transactions according to max_raw_read, so this code is no longer required in client drivers. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
1b3079a7 |
|
22-Feb-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
iio: accel: bmc150: Remove redundant __func__ in dev_dbg() Dynamic debug has a run time knob to enable function name printing. Remove this from dev_dbg() calls. Furthermore, functional tracing when enabled can show what function is called, therefore remove empty dev_dbg() calls. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
6c5bffa8 |
|
23-Jul-2017 |
Jonathan Cameron <jic23@kernel.org> |
iio:accel: drop assign iio_info.driver_module and iio_trigger_ops.owner The equivalent of both of these are now done via macro magic when the relevant register calls are made. The actual structure elements will shortly go away. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
#
e59e1898 |
|
13-Jul-2017 |
Hans de Goede <hdegoede@redhat.com> |
iio: accel: bmc150: Always restore device to normal mode after suspend-resume After probe we would put the device in normal mode, after a runtime suspend-resume we would put it back in normal mode. But for a regular suspend-resume we would only put it back in normal mode if triggers or events have been requested. This is not consistent and breaks reading raw values after a suspend-resume. This commit changes the regular resume path to also unconditionally put the device back in normal mode, fixing reading of raw values not working after a regular suspend-resume cycle. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
9f466777 |
|
02-Jan-2017 |
Jonathan Cameron <jic23@kernel.org> |
iio:buffer: Introduced a function to assign the buffer specific attrs. This is a necessary step in taking the buffer implementation opaque. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
#
1c500840 |
|
25-Aug-2016 |
Olof Johansson <olof@lixom.net> |
iio: accel: bmc150: reset chip at init time In at least one known setup, the chip comes up in a state where reading the chip ID returns garbage unless it's been reset, due to noise on the wires during system boot. All supported chips have the same reset method, and based on the datasheets they all need 1.3 or 1.8ms to recover after reset. So, do the conservative thing here and always reset the chip. Signed-off-by: Olof Johansson <olof@lixom.net> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
bc2b7dab |
|
09-Mar-2016 |
Gregor Boirie <gregor.boirie@parrot.com> |
iio:core: timestamping clock selection support Adds a new per-device sysfs attribute "current_timestamp_clock" to allow userspace to select a particular POSIX clock for buffered samples and events timestamping. Following clocks, as listed in clock_gettime(2), are supported: CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and CLOCK_TAI. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Acked-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
0ef4c311 |
|
10-Apr-2016 |
Alison Schofield <amsfield22@gmail.com> |
iio: accel: bmc150: use regmap to retrieve struct device Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Reviewed-by: Irina Tirdea <irina.tirdea@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
486294f1 |
|
29-Mar-2016 |
Irina Tirdea <irina.tirdea@intel.com> |
iio: accel: bmc150: use common definition for regmap conf bmc150_i2c_regmap_conf is defined three times (in bmc150-accel-core.c, bmc150-accel-i2c.c and and bmc150-accel-spi.c), although the definition is the same. Use one common definition for bmc150_i2c_regmap_conf in all included files. Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
2215f31d |
|
29-Mar-2016 |
Irina Tirdea <irina.tirdea@intel.com> |
iio: accel: bmc150: fix endianness when reading axes For big endian platforms, reading the axes will return invalid values. The device stores each axis value in a 16 bit little endian register. The driver uses regmap_read_bulk to get the axis value, resulting in a 16 bit little endian value. This needs to be converted to cpu endianness to work on big endian platforms. Fix endianness for big endian platforms by converting the values for the axes read from little endian to cpu. This is also partially fixed in commit b6fb9b6d6552 ("iio: accel: bmc150: optimize transfers in trigger handler"). Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
b1532909 |
|
24-Mar-2016 |
Irina Tirdea <irina.tirdea@intel.com> |
iio: remove unused gpio consumer.h include GPIO handling code has been removed from the drivers (since this is now handled by the ACPI core) in commit 0f0796509c07 ("iio: remove gpio interrupt probing from drivers that use a single interrupt"). Remove the include for linux/gpio/consumer.h since it is no longer used. Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
1715e0cc |
|
24-Mar-2016 |
Irina Tirdea <irina.tirdea@intel.com> |
iio: accel: bmc150: optimize transfers in trigger handler Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to enable/disable the bus at each i2c transfer and must wait for the enable/disable to happen before sending the data. When reading data in the trigger handler, the bmc150 accel driver does one bus transfer for each axis. This has an impact on the frequency of the accelerometer at high sample rates due to additional delays introduced by the bus at each transfer. Reading all axis values in one bus transfer reduces the delays introduced by the bus. Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
23e758b3 |
|
24-Mar-2016 |
Irina Tirdea <irina.tirdea@intel.com> |
iio: accel: bmc150: use available_scan_masks Use available_scan_masks to allow the iio core to select the data to send to userspace depending on which axes are enabled, instead of doing this in the driver's interrupt handler. Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
7d0ead5c |
|
05-Nov-2015 |
Adriana Reus <adi.reus@gmail.com> |
iio: Reconcile operation order between iio_register/unregister and pm functions At probe, runtime pm should be setup before registering the sysfs interface so that all the power attributes are accurate and functional when registering. Also, when removing the device we should unregister first to make sure that the interfaces that may result in wakeups are no longer available. Fix this behaviour for the following drivers: bmc150, bmg160, kmx61, kxcj-1013, mma9551, mma9553, rpr0521. Signed-off-by: Adriana Reus <adriana.reus@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
55637c38 |
|
20-Sep-2015 |
Markus Pargmann <mpa@pengutronix.de> |
iio: bmc150: Split the driver into core and i2c Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|