summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)Author
2022-04-16iio: imu: inv_icm42600: Fix I2C init possible nackFawzi Khaber
This register write to REG_INTF_CONFIG6 enables a spike filter that is impacting the line and can prevent the I2C ACK to be seen by the controller. So we don't test the return value. Fixes: 7297ef1e261672b8 ("iio: imu: inv_icm42600: add I2C driver") Signed-off-by: Fawzi Khaber <fawzi.khaber@tdk.com> Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20220411111533.5826-1-jmaneyrol@invensense.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-16iio: dac: ltc2688: fix voltage scale readNuno Sá
Properly set *val2 (and not overwrite *val) to correctly return IIO_VAL_FRACTIONAL_LOG2. Fixes: 832cb9eeb9312 ("iio: dac: add support for ltc2688") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220412124916.61-1-nuno.sa@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio:dac:ad3552r: Fix an IS_ERR() vs NULL checkDan Carpenter
The fwnode_get_named_child_node() function does not return error pointers. It returns NULL. Update the check accordingly. Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220404114244.GA19201@kili Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: sx9324: Fix default precharge internal resistance registerGwendal Grignou
Fix the default value for the register that set the resistance: it has to be 0x10 per datasheet. Fixes: 4c18a890dff8d ("iio:proximity:sx9324: Add SX9324 support") Cc: stable@vger.kernel.org Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220406165011.10202-2-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: dac: ad5446: Fix read_raw not returning set valueMichael Hennerich
read_raw should return the un-scaled value. Fixes: 5e06bdfb46e8b ("staging:iio:dac:ad5446: Return cached value for 'raw' attribute") Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220406105620.1171340-1-michael.hennerich@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: magnetometer: ak8975: Fix the error handling in ak8975_power_on()Zheyu Ma
When the driver fails to enable the regulator 'vid', we will get the following splat: [ 79.955610] WARNING: CPU: 5 PID: 441 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0 [ 79.959641] RIP: 0010:_regulator_put+0x3ec/0x4e0 [ 79.967570] Call Trace: [ 79.967773] <TASK> [ 79.967951] regulator_put+0x1f/0x30 [ 79.968254] devres_release_group+0x319/0x3d0 [ 79.968608] i2c_device_probe+0x766/0x940 Fix this by disabling the 'vdd' regulator when failing to enable 'vid' regulator. Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Link: https://lore.kernel.org/r/20220409034849.3717231-2-zheyuma97@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: core: Simplify the registration of kfifo buffersMiquel Raynal
Among all the users of the kfifo buffers, no one uses the INDIO_BUFFER_HARDWARE mode. So let's take this as a general rule and simplify a little bit the internals - overall the documentation - by eliminating unused specific cases. Use the INDIO_BUFFER_SOFTWARE mode by default with kfifo buffers, which will basically mimic what all the "non direct" modes do. Cc: Benson Leung <bleung@chromium.org> Cc: Guenter Roeck <groeck@chromium.org> Cc: Jyoti Bhayana <jbhayana@google.com> Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-13-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: core: Move the currentmode entry to the opaque structureMiquel Raynal
This entry should, under no situation, be modified by device drivers. Now that we have limited its read access to device drivers really needing it and did so through a dedicated helper, we can easily move this variable to the opaque structure in order to prevent any further modification from non-authorized code (out of the core, basically). Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20220207143840.707510-12-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: core: Hide read accesses to iio_dev->currentmodeMiquel Raynal
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>
2022-04-10iio: Un-inline iio_buffer_enabled()Miquel Raynal
As we are going to hide the currentmode inside the opaque structure, this helper would soon need to call a non-inline function which would simply drop the benefit of having the helper defined inline in a header. One alternative is to move this helper in the core as there is no more interest in defining it inline in a header. We will pay the minor cost either way. Let's do like the iio_device_id() helper which also refers to the opaque structure and gets defined in the core. Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-10-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: st_sensors: Use iio_device_claim/release_direct_mode() when relevantMiquel Raynal
The st_sensors_core driver hardcodes the content of the iio_device_claim_direct_mode() and iio_device_release_direct_mode() helpers. Let's get rid of this handcrafted implementation and use the proper core helpers instead. Additionally, this lowers the tab level (which is always good) and prevents the use of the ->currentmode variable which is not supposed to be used like this anyway. Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-9-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: st_sensors: Stop abusing mlock to ensure internal coherencyMiquel Raynal
An odr_lock has been introduced to protect local accesses to the odr internal cache and ensure the cached value always reflected the actual value. Using the mlock() for this purpose is no longer needed, so let's drop these extra mutex_lock/unlock() calls. Suggested-by: Jonathan Cameron <jic23@kernel.org> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-8-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: st_sensors: Add a local lock for protecting odrMiquel Raynal
Right now the (framework) mlock lock is (ab)used for multiple purposes: 1- protecting concurrent accesses over the odr local cache 2- avoid changing samplig frequency whilst buffer is running Let's start by handling situation #1 with a local lock. Suggested-by: Jonathan Cameron <jic23@kernel.org> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-7-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: st_sensors: Drop the protection on _avail functionsMiquel Raynal
The use of a lock there seems pointless. Besides preventing to read these information from userspace while buffers are enabled (which is not supposed to happen), it only protect read accesses over static const values, which are never supposed to be written anyway. Drop these lock calls. Suggested-by: Jonathan Cameron <jic23@kernel.org> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-6-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: st_sensors: Return as early as possible from the _write_raw() callbacksMiquel Raynal
As there is no cleanup to do, let's return as early as possible in the various ST sensor drivers _write_raw() callback functions. There is no functional change. Suggested-by: Jonathan Cameron <jic23@kernel.org> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-5-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: adc: stm32-dfsdm: Avoid dereferencing ->currentmodeMiquel Raynal
This is an internal variable of the core, let's use the iio_buffer_enabled() helper which is exported for the following purpose: telling if the current mode is a buffered mode, which is precisely what this driver looks for. Cc: Olivier Moysan <olivier.moysan@foss.st.com> Cc: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20220207143840.707510-4-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-10iio: magnetometer: rm3100: Stop abusing the ->currentmodeMiquel Raynal
This is an internal variable for the core, here it is set to a "default" value by the driver in order to later be able to perform checks against it. None of this is needed because this check actually cares about the buffers being enabled or not. So it is an unproper side-channel access to the information "are the buffers enabled?", returned officially by the iio_buffer_enabled() helper. Use this helper instead. Cc: Song Qiang <songqiang1304521@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20220207143840.707510-3-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-05iio: chemical: scd30: Move symbol exports into IIO_SCD30 namespaceJonathan Cameron
Avoid unnecessary pollution of the global symbol namespace by moving library functions in to a specific namespace and import that into the drivers that make use of the functions. For more info: https://lwn.net/Articles/760045/ Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Tomasz Duszynski <tomasz.duszynski@octakon.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-04-05iio: chemical: scd30: Export dev_pm_ops instead of suspend() and resume()Jonathan Cameron
Whilst here move to the new infrastructure using pm_sleep_ptr() and EXPORT_DEV_PM_OPS() so as to let the compiler remove the unused code if CONFIG_SLEEP is not defined. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Tomasz Duszynski <tomasz.duszynski@octakon.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-04-04iio:proximity:sx9324: Fix hardware gain read/writeStephen Boyd
There are four possible gain values according to 'sx9324_gain_vals[]': 1, 2, 4, and 8 The values are off by one when writing and reading the register. The bits should be set according to this equation: ilog2(<gain>) + 1 so that a gain of 8 is 0x4 in the register field and a gain of 4 is 0x3 in the register field, etc. Note that a gain of 0 is reserved per the datasheet. The default gain (SX9324_REG_PROX_CTRL0_GAIN_1) is also wrong. It should be 0x1 << 3, i.e. 0x8, not 0x80 which is setting the reserved bit 7. Fix this all up to properly handle the hardware gain and return errors for invalid settings. Fixes: 4c18a890dff8 ("iio:proximity:sx9324: Add SX9324 support") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20220324222928.874522-1-swboyd@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio:proximity:sx_common: Fix device property parsing on DT systemsStephen Boyd
After commit 7a3605bef878 ("iio: sx9310: Support ACPI property") we started using the 'indio_dev->dev' to extract device properties for various register settings in sx9310_get_default_reg(). This broke DT based systems because dev_fwnode() used in the device_property*() APIs can't find an 'of_node'. That's because the 'indio_dev->dev.of_node' pointer isn't set until iio_device_register() is called. Set the pointer earlier, next to where the ACPI companion is set, so that the device property APIs work on DT systems. Cc: Gwendal Grignou <gwendal@chromium.org> Fixes: 7a3605bef878 ("iio: sx9310: Support ACPI property") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20220331210425.3908278-1-swboyd@chromium.org Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ad7280a: Fix wrong variable used when setting thresholds.Jonathan Cameron
Name of variable change missed in refactoring patch. Fixes: 112bf4aa4afb ("staging:iio:adc:ad7280a: Switch to standard event control") Reported-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Link: https://lore.kernel.org/r/20220226175604.662422-1-jic23@kernel.org
2022-04-04iio:filter:admv8818: select REGMAP_SPI for ADMV8818Wang ShaoBo
admv8818 driver needs __devm_regmap_init_spi() which is defined when CONFIG_REGMAP_SPI is set and struct regmap_config when CONFIG_REGMAP is set, so automatically select CONFIG_REGMAP_SPI which also sets CONFIG_REGMAP. Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818") Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220320055457.254983-1-bobo.shaobowang@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: dac: ad5592r: Fix the missing return value.Zizhuang Deng
The third call to `fwnode_property_read_u32` did not record the return value, resulting in `channel_offstate` possibly being assigned the wrong value. Fixes: 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs") Signed-off-by: Zizhuang Deng <sunsetdzz@gmail.com> Link: https://lore.kernel.org/r/20220310125450.4164164-1-sunsetdzz@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: dac: dac5571: Fix chip id detection for OF devicesJose Cazarin
When matching an OF device, the match mechanism tries all components of the compatible property. This can result with a device matched with a compatible string that isn't the first in the compatible list. For instance, with a compatible property set to compatible = "ti,dac081c081", "ti,dac5571"; the driver will match the second compatible string, as the first one isn't listed in the of_device_id table. The device will however be named "dac081c081" by the I2C core. This causes an issue when identifying the chip. The probe function receives a i2c_device_id that comes from the module's I2C device ID table. There is no entry in that table for "dac081c081", which results in a NULL pointer passed to the probe function. To fix this, add chip_id information in the data field of the OF device ID table, and retrieve it with device_get_match_data() for OF devices. Signed-off-by: Jose Cazarin <joseespiriki@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20220324234340.32402-1-laurent.pinchart@ideasonboard.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio:imu:bmi160: disable regulator in error pathTong Zhang
Regulator should be disabled in error path as mentioned in _regulator_put(). Also disable accel if gyro cannot be enabled. [ 16.233604] WARNING: CPU: 0 PID: 2177 at drivers/regulator/core.c:2257 _regulator_put [ 16.240453] Call Trace: [ 16.240572] <TASK> [ 16.240676] regulator_put+0x26/0x40 [ 16.240853] regulator_bulk_free+0x26/0x50 [ 16.241050] release_nodes+0x3f/0x70 [ 16.241225] devres_release_group+0x147/0x1c0 [ 16.241441] ? bmi160_core_probe+0x175/0x3a0 [bmi160_core] Fixes: 5dea3fb066f0 ("iio: imu: bmi160: added regulator support") Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Tong Zhang <ztong0001@gmail.com> Link: https://lore.kernel.org/r/20220327154005.806049-1-ztong0001@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: scd4x: check return of scd4x_write_and_fetchTom Rix
Clang static analysis reports this problem scd4x.c:474:10: warning: The left operand of '==' is a garbage value if (val == 0xff) { ~~~ ^ val is only set from a successful call to scd4x_write_and_fetch() So check it's return. Fixes: 49d22b695cbb ("drivers: iio: chemical: Add support for Sensirion SCD4x CO2 sensor") Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20220301025223.223223-1-trix@redhat.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: dac: ad3552r: fix signedness bug in ad3552r_reset()Dan Carpenter
The "val" variable is used to store either negative error codes from ad3552r_read_reg_wrapper() or positive u16 values on success. It needs to be signed for the error handling to work correctly. Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220316122354.GA16825@kili Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ti-ads1015: Switch to read_availMarek Vasut
Replace sysfs attributes with read_avail() callback. This also permits removal of ads1115_info, since the scale attribute tables are now part of chip data. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20220328194725.149150-10-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ti-ads1015: Replace data_rate with chip data struct ads1015_dataMarek Vasut
Instead of storing only data_rate in private data, store pointer to the whole chip data and use the data_rate from chip data throughout the driver. No functional change. This is done in preparation for switching to read_avail(). Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andy Shevchenko <andy@kernel.org> Cc: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20220328194725.149150-9-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ti-ads1015: Convert to OF match dataMarek Vasut
Replace chip type enumeration in match data with pointer to static constant structure which contains all the different chip properties in one place, and then replace handling of chip type in probe() with simple copy of fields in the new match data structure into struct iio_dev. This reduces code and increases static data. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andy Shevchenko <andy@kernel.org> Cc: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20220328194725.149150-8-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ti-ads1015: Add static assert to test if shifted realbits fit into ↵Marek Vasut
storagebits Add compile-time static_assert wrapper to verify that shifted realbits fit into storagebits. The macro is implemented in a more generic way so it can be used to verify other values if required. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andy Shevchenko <andy@kernel.org> Cc: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20220328194725.149150-7-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ti-ads1015: Add TLA2024 supportMarek Vasut
Add support for TI TLA2024 ADC. This chip is compatible with ADS1015 except it has no comparator in it, hence the comparator configuration bits are missing in Configuration Register and the Hi_Thresh/Lo_Thresh registers are missing as well and so is event support. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andy Shevchenko <andy@kernel.org> Cc: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20220328194725.149150-6-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ti-ads1015: Make channel event_spec optionalMarek Vasut
Pass event_spec and num_event_specs to ADS1015_V_CHAN and ADS1015_V_DIFF_CHAN macros, to make it possible to pass no event_spec at all for chips which have no comparator and thus no events. No functional change. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andy Shevchenko <andy@kernel.org> Cc: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20220328194725.149150-5-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ti-ads1015: Deduplicate channel macrosMarek Vasut
These macros differ only in the number of valid bits of each ADC sample and the shift of those bits, i.e. ADS1015 is 12bit ADC shifted by 4 left, ADS1115 is 16bit ADC shifted by 0. No functional change. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andy Shevchenko <andy@kernel.org> Cc: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20220328194725.149150-4-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ti-ads1015: Switch to static const writeable ranges tableMarek Vasut
Switch the driver from code implementing test whether a regmap register is writeable to static const tables describing the test. No functional change. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andy Shevchenko <andy@kernel.org> Cc: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20220328194725.149150-3-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: core: Print error and fail iio_device_register() in case sample bits do ↵Marek Vasut
not fit storage bits Add runtime check to verify whether storagebits are at least as big as shifted realbits. This should help spot broken drivers which may set realbits + shift above storagebits. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20220328195307.154422-1-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: accel: kxsd9-spi: changed leading spaces to tabsPaul Lemmermann
Changed the leading spaces to tabs, in accordance with kernel coding conventions, and removed trailing comma. Found with checkpatch. Signed-off-by: Paul Lemmermann <thepaulodoom@thepaulodoom.com> Link: https://lore.kernel.org/r/YkInN6SL7pP2f5Sf@hp-amd-paul Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: accel: dmard09: fixed code styling issuesPaul Lemmermann
Cleaning up code. Found with checkpatch. Signed-off-by: Paul Lemmermann <thepaulodoom@thepaulodoom.com> Link: https://lore.kernel.org/r/YkItIE5sp3P4sZdY@hp-amd-paul Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: sysfs-trigger: replace usage of found with dedicated list iterator variableJakob Koschel
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable instead of a found boolean [1]. This removes the need to use a found variable and simply checking if the variable was set, can determine if the break/goto was hit. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220331230632.957634-3-jakobkoschel@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: ssp_sensors: replace usage of found with dedicated list iterator variableJakob Koschel
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable instead of a found boolean [1]. This removes the need to use a found variable and simply checking if the variable was set, can determine if the break/goto was hit. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220331230632.957634-2-jakobkoschel@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: buffer: remove usage of list iterator variable for ↵Jakob Koschel
list_for_each_entry_continue_reverse() In preparation to limit the scope of the list iterator variable to the list traversal loop, use a dedicated pointer to iterate through the list [1]. Since that variable should not be used past the loop iteration, a separate variable is used to 'remember the current location within the loop'. To either continue iterating from that position or start a new iteration (if the previous iteration was complete) list_prepare_entry() is used. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220331230632.957634-1-jakobkoschel@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: palmas: shut up warning about calibration mismatch (due to noise)H. Nikolaus Schaller
Although technically checking for ADC values below 0 is correct, because they are outside of the calibration values, there is usually noise which spuriously fills the console log with error messages if calculated input voltage gets close to 0V. Ignore small negative calculated values, but clamp them to 0. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/1cee45bfc3fa2ab59dcc17242fb52468035360a1.1646743982.git.hns@goldelico.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ad7192: add sequencer supportAlexandru Tachici
Add sequencer support for AD7192. Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Link: https://lore.kernel.org/r/20220322105029.86389-7-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ad7124: add sequencer supportAlexandru Tachici
Add sequencer support for AD7124. Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Link: https://lore.kernel.org/r/20220322105029.86389-6-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ad_sigma_delta: Add sequencer supportLars-Peter Clausen
Some sigma-delta chips support sampling of multiple channels in continuous mode. When the operating with more than one channel enabled, the channel sequencer cycles through the enabled channels in sequential order, from first channel to the last one. If a channel is disabled, it is skipped by the sequencer. If more than one channel is used in continuous mode, instruct the device to append the status to the SPI transfer (1 extra byte) every time we receive a sample. All sigma-delta chips possessing a sampling sequencer have this ability. Inside the status register there will be the number of the converted channel. In this way, even if the CPU won't keep up with the sampling rate, it won't send to userspace wrong channel samples. When multiple channels are enabled in continuous mode, the device needs to perform a measurement on all slots before we can push to userspace the sample. If, during sequencing and data reading, a channel measurement is lost, a desync occurred. In this case, ad_sigma_delta drops the incomplete sample and waits for the device to send the measurement on the first active slot. Co-developed-by: Alexandru Tachici <alexandru.tachici@analog.com> Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20220322105029.86389-5-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ad7192: Add update_scan_modeAlexandru Tachici
The callback .set_channel cannot be used to enable multiple channels at once, only one is allowed simultaneously. By adding an update_scan_mode callback, every time the continuous mode is activated, channels will be enabled/disabled accordingly. Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Link: https://lore.kernel.org/r/20220322105029.86389-4-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ad7124: Add update_scan_modeAlexandru Tachici
The callback .set_channel cannot be used to enable and disable multiple channels at once as they are presented in the active_scan_mask. By adding an update_scan_mode callback, every time the continuous mode is activated, channels will be enabled/disabled accordingly. Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Link: https://lore.kernel.org/r/20220322105029.86389-3-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: adc: ad7124: Remove shift from scan_typeAlexandru Tachici
The 24 bits data is stored in 32 bits in BE. There is no need to shift it. This confuses user-space apps. Fixes: b3af341bbd966 ("iio: adc: Add ad7124 support") Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Link: https://lore.kernel.org/r/20220322105029.86389-2-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-04iio: imu: inv_mpu6050: Add support for ICM-20608-DMichael Srba
The difference between the ICM-20608-D and the other ICM-20608 variants is the addition of a DMP (Digital Motion Processor) core. This difference is deemed substantial enough to change the WHOAMI register value. Since this driver doesn't currently acknowledge the exisence of something like a DMP core, simply copy ICM-20608 except for the aforementioned WHOAMI register. Signed-off-by: Michael Srba <Michael.Srba@seznam.cz> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20220323121550.16096-3-michael.srba@seznam.cz Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit (git 2.34.1) at 2025-09-14 13:13:36 +0000