- 14 Jun, 2021 5 commits
-
-
Jonathan Cameron authored
Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Here an explicit structure is not used, because this buffer is used in a non-trivial way for data repacking. Fixes: 121354b2 ("iio: magnetometer: Add driver support for PNI RM3100") Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Song Qiang <songqiang1304521@gmail.com> Reviewed-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613152301.571002-6-jic23@kernel.org
-
Jonathan Cameron authored
Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Fixes: f214ff52 ("iio: ti-ads8688: Update buffer allocation for timestamps") Signed-off-by:
-
Jonathan Cameron authored
To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Add a comment on why the buffer is the size it is as not immediately obvious. Found during an audit of all calls of this function. Fixes: 6dd112b9 ("iio: adc: mxs-lradc: Add support for ADC driver") Signed-off-by:
-
Jonathan Cameron authored
To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: d3bf6045 ("iio: hx711: add triggered buffer support") Signed-off-by:
-
Jonathan Cameron authored
To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: 5e1a1da0 ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support") Signed-off-by:
-
- 13 Jun, 2021 31 commits
-
-
William Breathitt Gray authored
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch renames interrupt_cnt_synapse_actionss to interrupt_cnt_synapse_actions and adds a const qualifier to match actions_list. Cc: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Reviewed-by: <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20210610013642.149961-1-vilhelm.gray@gmail.comSigned-off-by:
-
Marc Kleine-Budde authored
This patch marks the struct ltr501_chip_info as constant. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-5-mkl@pengutronix.deSigned-off-by:
-
Oliver Lang authored
The PS ADC Channel data is spread over 2 registers in little-endian form. This patch adds the missing endianness conversion. Fixes: 2690be90 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver") Signed-off-by:
Oliver Lang <Oliver.Lang@gossenmetrawatt.com> Reviewed-by:
-
Oliver Lang authored
The ltr559 chip uses only the lowest bit of the ALS_CONTR register to configure between active and stand-by mode. In the original driver BIT(1) is used, which does a software reset instead. This patch fixes the problem by using BIT(0) as als_mode_active for the ltr559 chip. Fixes: 8592a7ee ("iio: ltr501: Add support for ltr559 chip") Signed-off-by:
-
Marc Kleine-Budde authored
The regmap is configured for 8 bit registers, uses a RB-Tree cache and marks several registers as volatile (i.e. do not cache). The ALS and PS data registers in the chip are 16 bit wide and spans two regmap registers. In the current driver only the base register is marked as volatile, resulting in the upper register only read once. Further the data sheet notes: | When the I2C read operation starts, all four ALS data registers are | locked until the I2C read operation of register 0x8B is completed. Which results in the registers never update after the 2nd read. This patch fixes the problem by marking the upper 8 bits of the ALS and PS registers as volatile, too. Fixes: 2f2c9633 ("iio: ltr501: Add regmap support.") Reported-by:
-
Tom Rix authored
checkpatch looks for SPDX-License-Identifier. Remove the extra spaces. Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20210610214438.3161140-7-trix@redhat.comSigned-off-by:
-
Stephan Gerhold authored
Commit c1d1c4a6 ("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:
Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-11-stephan@gerhold.netSigned-off-by:
-
Stephan Gerhold authored
BMA254 is very similar to BMA253/BMA255 which are both supported by the bmc150-accel driver. In general, there is quite some overlap between the bma180 and bmc150-accel driver, but the bmc150-accel driver has a few more features (e.g. motion trigger/interrupt). Let's move bma254 over to the bma255 schema (bmc150-accel driver). Reviewed-by:
-
Stephan Gerhold authored
BMA253 has two interrupt pins (INT1 and INT2) that can be configured independently. At the moment the bmc150-accel driver does not make use of them but it might be able to in the future, so it's useful to already specify all available interrupts in the device tree. Set maxItems: 2 for interrupts to allow specifying a second one. This is necessary as preparation to move the bosch,bma254 compatible from bosch,bma180.yaml to bosch,bma255.yaml since bma180 allows two interrupts, but BMA254 is better supported by the bmc150-accel driver. Reviewed-by:
-
Stephan Gerhold authored
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:
-
Stephan Gerhold authored
BMA253 is mostly like BMA255 that is already supported by the bmc150-accel driver. Document an extra bosch,bma253 compatible for it. Reviewed-by:
-
Stephan Gerhold authored
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:
-
Stephan Gerhold authored
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:
-
Stephan Gerhold authored
Commit 0ad4bf37 ("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:
-
Stephan Gerhold authored
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:
-
Stephan Gerhold authored
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: a1a210bf ("iio: accel: bmc150-accel: Add support for BMA222") Reviewed-by:
-
Wei Yongjun authored
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: 738f6ba1 ("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:
-
Yang Yingliang authored
Disable reg and clk when devm_gpiod_get_optional() fails in adf4350_probe(). Fixes:4a89d2f4 ("iio: adf4350: Convert to use GPIO descriptor") Reported-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
-
Stephan Gerhold authored
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: 2017cff2 ("iio:bma180: Add BMA250 chip support") Signed-off-by:
-
Jarkko Nikula authored
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:
-
Jarkko Nikula authored
Remove CONFIG_PM ifdef and mark PM callbacks with __maybe_unused. Suggested-by:
-
Alexandru Ardelean authored
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.comSigned-off-by:
-
Alexandru Ardelean authored
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 authored
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: -
Jonathan Cameron authored
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:
-
Alexandru Ardelean authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
- 09 Jun, 2021 4 commits
-
-
Hans de Goede authored
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 authored
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:
-
Hans de Goede authored
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 authored
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:
-
