- 17 May, 2021 40 commits
-
-
Jonathan Cameron authored
Found using coccicheck script under review at: https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/ This is a prequel to taking a closer look at the runtime pm in IIO drivers in general. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Reviewed-by:
Fabrice Gasnier <fabrice.gasnier@foss.st.com> Reviewed-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210509113354.660190-15-jic23@kernel.org
-
Jonathan Cameron authored
No point in calling pm_runtime_put_noidle() that isn't balancing a get. Note no actual impact because the runtime pm core protects against a negative reference counter. For the pm_runtime_resume_and_get() main interest is in clearing out this old pattern to avoid it getting coppied into new submissions. Signed-off-by:
-
Jonathan Cameron authored
This driver alls pm_runtime_put_noidle() in it's remove function, but there is no matching get call. This isn't a bug as runtime pm will not allow the reference counter to go negative, but it is missleading so lets remove it. Whilst here use pm_runtime_resume_and_get() to tidy up some boilerplate. The coccicheck script didn't get this one due to the less obvious structure. Found by inspection. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Jonathan Cameron authored
Both these drivers call pm_runtime_put_no_idle() when the reference count should already be zero as there is no matching get() Whilst here use pm_runtime_resume_and_get() rather than open coding. Signed-off-by:
-
Jonathan Cameron authored
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 authored
Error paths in read_raw() and write_raw() callbacks failed to perform and type of runtime pm put(). Remove called pm_runtime_put_noidle() but there is no equivalent get (this is safe because the reference count is protected against going below zero, but it is misleading. Whilst here use pm_runtime_resume_and_get() to replace boilerplate. Signed-off-by:
Brian Masney <masneyb@onstation.org> Reviewed-by:
-
Jonathan Cameron authored
In remove this driver called pm_runtime_put_noidle() but there is no matching get operation. This does not cause any problems because the reference counter will not change if already zero, but it does make the code harder to reason about so should be dropped. Whilst we are here, use pm_runtime_resume_and_get() to replace open coded version. Found using coccicheck script under review at: https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/Signed-off-by:
-
Jonathan Cameron authored
In both the probe() error path and remove() pm_runtime_put_noidle() is called which will decrement the runtime pm reference count. However, there is no matching function to have raised the reference count. Not this isn't a fix as the runtime pm core will stop the reference count going negative anyway. An alternative would have been to raise the count in these paths, but it is not clear why that would be necessary. Whilst we are here replace some boilerplate with pm_runtime_resume_and_get() Found using coccicheck script under review at: https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/Signed-off-by:
Rui Miguel Silva <rui.silva@linaro.org> Reviewed-by:
-
Stephan Gerhold authored
The KX023-1025 accelerometer [1] seems to be some mixture of KXCJK and KXTF9. It has the motion interrupt functionality from KXCJK but also the tap detection from KXTF9, and a lot more functionality. The configuration register map seems fairly different at first, but actually all register bits used by the kxcjk-1013 driver are available at the same bit positions on KX023-1025. It's just quite misleading because: 1. The registers have entirely different names and are at different addresses, but the bits are mostly named the same (and mean the same). 2. There are many more registers and bits used that are reserved on KXCJK to enable additional functionality. Ignoring all additionally available functionality for now, the KX023 works just fine after setting up the struct with the correct register addresses. The only difference that needs to be handled additionally is that the KX023 supports two configurable interrupt lines (INT1/2). For now only INT1 is supported so we route all interrupts used by the driver there. [1]: https://kionixfs.azureedge.net/en/datasheet/KX023-1025%20Specifications%20Rev%2012.0.pdf Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by:Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
-
Stephan Gerhold authored
Most Kionix accelerometers seem to use fairly consistent register bits, but the register addresses are not necessarily the same. This is already partially the case for the KXTF9 (added in commit 1540d010 ("iio: accel: kxcjk1013: add support for KXTF9")), which has some registers at different addresses. However, it's even much worse for the KX023-1025. All register bits used by the kxcjk-1013 driver seem to be fully compatible with KX023, but it has most registers at totally different addresses. In preparation to add support for KX023-1025, move the fixed register addresses into a struct so we can change them for KX023 more easily. Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by:
-
Stephan Gerhold authored
The KX023-1025 accelerometer uses similar register bits as kxcjk1023, so it can make use of the same driver. Document the new kionix,kx023-1025 compatible that is also supported by the kxcjk-1013 driver now. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Chunyan Zhang authored
MODULE_DEVICE_TABLE is used to extract the device information out of the driver and builds a table when being compiled. If using this macro, kernel can find the driver if available when the device is plugged in, and then loads that driver and initializes the device. Signed-off-by:
Chunyan Zhang <chunyan.zhang@unisoc.com> Signed-off-by:
-
Krzysztof Kozlowski authored
The current-sense-shunt is an IIO provider thus can be referenced by IIO consumers (via "io-channels" property in consumer device node). Such provider is required to describe number of cells used in phandle lookup with "io-channel-cells" property. This also fixes dtbs_check warnings like: arch/arm/boot/dts/s5pv210-fascinate4g.dt.yaml: current-sense-shunt: '#io-channel-cells' does not match any of the regexes: 'pinctrl-[0-9]+' Fixes: ce66e52b ("dt-bindings:iio:afe:current-sense-shunt: txt to yaml conversion.") Signed-off-by:Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by:
-
Zhen Lei authored
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by:
-
Sean Nyekjaer authored
When flushing the hw fifo there is a bug in the I2C that prevents burst reads of more than one sample pair. Signed-off-by:
Sean Nyekjaer <sean@geanix.com> Signed-off-by:
-
Sean Nyekjaer authored
When buffered sampling is enabled, the accelerometer will dump data into the internal fifo and interrupt at watermark. Then the driver flushes all data to the iio buffer. As the accelerometer doesn't have internal timestamps, they are approximated between the current and last interrupt. Signed-off-by:
-
Sean Nyekjaer authored
Preparation commit for the next that adds hw buffered sampling. Adds the interrupt function and reads the devicetree for which interrupt pin that is used. Signed-off-by:
-
Sean Nyekjaer authored
This adds support for setting de accelerometers output data rate. Primarily used for hardware buffered reads. Signed-off-by:
-
Sean Nyekjaer authored
Add devicetree binding for the NXP FXLS8962AF/FXLS8964AF accelerometer sensor. Signed-off-by:
-
Sean Nyekjaer authored
Add basic support for NXP FXLS8962AF/FXLS8964AF Automotive accelerometers. It will allow setting up scale/gain and reading x,y,z axis. Datasheet: https://www.nxp.com/docs/en/data-sheet/FXLS8962AF.pdf Datasheet: https://www.nxp.com/docs/en/data-sheet/FXLS8964AF.pdfSigned-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Sean Nyekjaer authored
Fix wrongly stated 13 Hz ODR for accelerometers, the correct ODR is 12.5 Hz Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Guenter Roeck authored
With CONFIG_ACPI=n and -Werror, 0-day reports: drivers/iio/chemical/bme680_i2c.c:46:36: error: 'bme680_acpi_match' defined but not used Apparently BME0680 is not a valid ACPI ID. Remove the ID. Note the driver will still work with ACPI bindings that use the PRP0001 mechanism as that uses the of_device_id table instead. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
-
Guenter Roeck authored
BME0680 is not an official ACPI ID, so let's remove it before someone starts using it. Note that ACPI can still be used with this driver via the PRP0001 method which will use the of_device_id table to match. Signed-off-by:
-
Guenter Roeck authored
With CONFIG_ACPI=n, W=1 and -Werror, 0-day reports: drivers/iio/accel/stk8312.c:644:36: error: 'stk8312_acpi_id' defined but not used Apparently STK8312 is not a valid ACPI ID. Remove the ID table as this is the only entry. If ACPI support is desired an explicit of_device_id table should be added (rather than relying on the fallback to the existing ID table). Reported-by:
-
Guenter Roeck authored
With CONFIG_ACPI=n and -Werror, 0-day reports: drivers/iio/humidity/am2315.c:259:36: error: 'am2315_acpi_id' defined but not used According to Andy Shevchenko, the ACPI ID used in this driver is fake and does not really exist. Remove it and with it ACPI support from the driver. Note that, if an explicit of_device_id table is added to the driver it could support the PRP0001 based ACPI approach. Reported-by:
-
Jonathan Cameron authored
Straight forward conversion. Only fiddly bit is the XOR of spi-cpol and spi-cpha. Signed-off-by:
-
Andy Shevchenko authored
Enumerate LSM9DS0 (accelerometer and magnetometer parts) via 'st,lsm9ds0-imu' compatible string. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
-
Andy Shevchenko authored
We can utilize separate drivers for accelerometer and magnetometer, so here is the glue driver to enable LSM9DS0 IMU support. The idea was suggested by Crestez Dan Leonard in [1]. The proposed change was sent as RFC due to race condition concerns, which are indeed possible. In order to amend the initial change, I went further by providing a specific multi-instantiate probe driver that reuses existing accelerometer and magnetometer. [1]: https://lore.kernel.org/patchwork/patch/670353/Suggested-by:
Crestez Dan Leonard <leonard.crestez@intel.com> Cc: mr.lahorde@laposte.net Cc: Matija Podravec <matija_podravec@fastmail.fm> Cc: Sergey Borishchenko <borischenko.sergey@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
Some IMUs may utilize existing library code for STMicro accelerometer, gyroscope, magnetometer and pressure. Let's share them via st_sensors.h. Signed-off-by:
-
Andy Shevchenko authored
In case we would initialize two IIO devices from one physical device, we shouldn't have a clash on regulators. That's why move st_sensors_power_enable() call from core to bus drivers. Signed-off-by:
-
Andy Shevchenko authored
Provide default platform data for magnetometer in case it supports DRDY. One case is LSM9DS0 IMU, on which it is the case. Since accelerometer is using INT1, default magnetometer to INT2. While at it, update description of the drdy_int_pin field. Signed-off-by:
-
Andy Shevchenko authored
Platform data is solely used by one file. Don't share it with others. While at it, drop unneeded anymore __maybe_unused and fix kernel doc to avoid warning: st_gyro_core.c:366: error: Cannot parse struct or union! by converting to a simple comment. It is described at the declaration. Signed-off-by:
-
Andy Shevchenko authored
Platform data is solely used by one file. Don't share it with others. While at it, drop unneeded anymore __maybe_unused and fix kernel doc to avoid warning: st_accel_core.c:1079: error: Cannot parse struct or union! by converting to a simple comment. It is described at the declaration. Signed-off-by:
-
Jonathan Cameron authored
There is already an acessor function used to access it, making this move straight forward. Signed-off-by:
Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210426174911.397061-10-jic23@kernel.org
-
Jonathan Cameron authored
No reason any driver should ever need access to this field, so hide it. Signed-off-by:
-
Jonathan Cameron authored
No reason for this to be exposed to the drivers, so lets move it to the opaque structure. Signed-off-by:
-
Jonathan Cameron authored
This lock is only of interest to the IIO core, so make it only visible there. Signed-off-by:
-
Jonathan Cameron authored
No reason for this cached value to be exposed to drivers so move it to the opaque structure. Signed-off-by:
-
Jonathan Cameron authored
This is only set via the iio_trig_set_immutable() call and later used by the IIO core so there is no benefit in drivers being able to access it. Signed-off-by:
-
Jonathan Cameron authored
Continuing move to hide internal elements from drivers, move this structure element over. It's only accessed from iio core files so this one was straight forward and no accessor functions are needed. Signed-off-by:
-
