The iio_triggered_buffer_setup_ext() and the
devm_iio_kfifo_buffer_setup_ext() were changed by
commit 15097c7a1a ("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>
The iio_triggered_buffer_setup_ext() was changed by
commit 15097c7a1a ("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: 15097c7a1a ("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>
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>
This cycle we had quite a few series that applied similar changes
to lots of drivers. To keep this description manageable I have
called those out in their own section rather than per driver.
Particularly pleased to see the long running AFE precision series
going in this cycle.
Series includes some late breaking fixes.
New device support
* adi,ada4250 amplifier
- New driver and dt bindings for this programmable gain amplifier.
* adi,admv1014 microwave down-converter
- New driver, dt bindings and some device specific ABI that
may be generalized as more drivers for devices similar to this
are added.
* adi,admv4420 K Band down-converter.
- New driver and dt bindings.
* adi,adxl367 accelerometer driver.
- New driver, dt-bindings + some new IIO ABI definitions to support
reference magnitude events where an estimate of the acceleration
due to gravity has been removed.
- A few fixes as follow up patches.
* adi,ltc2688 DAC with toggle and dither modes.
- New driver and bindings. Includes some new driver specific (for now)
ABI for handling toggle mode and the addition of a dither waveform to
the DAC output.
* AFE (analog front end) add support for additional types of analog device
in front of an ADC.
- RTD temperature sensors with dt bindings.
- Temperature transducers wit dt bindings.
- Related cleanup and features listed in other sections below.
* maxim,ds3502 potentiometer.
- Add support to ds1803 driver which required significant rework.
* mediatek,mt2701-auxadc driver
- Add mediatek,mt8186-auxadc - id table and chip specific info only.
* semtech,sx9324, semtech,ax9360
- Substantial refactoring of sx9310 to extract core logic for reuse
into a separate module
- New driver using this supporting sx9324 proximity sensors.
- New driver using this supporting sx9360 proximity sensors.
* silan,sc7a20
- Compatible with the st,lis2dh (or nearly anyway) so add ID and
chip specific info to enable support. Also silan vendor ID added
for dt-bindings.
Staging graduation
* adi,ad7280a monitoring ADC for stacked lithium-ion batteries in
electric cars and similar.
- Substantial rework of driver required to bring inline with current
IIO best practice. An unusual device in IIO so some interesting features
we may see more of in future.
Multiple driver/core cleanup
- Use sysfs_emit() in simple locations where there is no path to change
to various core created attributes.
- Trivial white space fixes around inconsistency between space after { and
before } in id tables.
- Introduce new handling for fractional types to avoid repeated similar
implementations. Use this in 3 drivers. Note this is also targeted
at future use in the AFE driver and was motivated by discussions
around the precision related work on that driver.
- of related header cleanups - drop of*.h and add mod_devicetable.h as
appropriate.
- Move a number of symbol exports into IIO_* namespaces. Two categories,
1) Library used by multiple drivers e.g. st_sensors
2) Core driver module exporting functions used by bus specific modules.
A few related cleanups in this set.
- Switch from CONFIG_PM_* guards to new DEFINE_SIMPLE_DEV_PM_OPS() and
similar to simplify drivers and take advantage of these new macros
allowing the compiler to do the job or removing unused code without
the need for __maybe_unused markings. Conversion of other drivers to
these new macros ongoing.
Features
* adi,adf4350
- Switch from of specific to generic device properties enabling use with
other firmware types.
* adi,adx345
- Switch from of specific to generic device properties.
- Add ACPI ID ADS0345
- Related driver cleanup.
* adi,hmc425a
- Switch from of specific to generic device properties.
* afe analog rescaler driver
- Wider range of types supported for scale.
- Support offset.
- Kunit tests.
* atlas,ezo-sensor
- Convert from of to device properties.
* fsl,mma8452
- Support mount matrix.
* infineon,dps310:
- Add ACPI ID IFX3100.
* invensense,mpu6050
- Convert to generic device properties.
* maxim,ds1803
- Add out_raw_available before supporting more devices.
- Convert from of specific to device properties.
* samsung,ssp_sensors
- Convert from of specific to device properties.
* st,stm32-timer trigger
- Convert from of specific to device properties.
* ti,hdc101x
- Add ACPI ID TXNW1010.
* ti,tsc2046:
- Add read_raw support to enable use of iio_hwmon and similar.
Fixes / cleanup.
* mailmap
- Update for Cai Huoqing
* MAINTAINERS
- Fix Analog Devices related links.
- Add entry for ADRF6780
- Add entry for ADMV1013
- Add entry for AD7293
- Add entry for ADMV8818
- Update files listed for adis-lib
* iio core:
- Fix wrong comment about current_mode being something a driver should
ever access.
- Use struct_size() rather than open coding in industrialio-hw-consumer
* adi,axl355
- Use units.h definitions instead of local versions.
* adi,adis-lib
- Simplify *updated_bits() macro
- Whitespace cleanup.
* afe - Note many of these fixes only apply to particular configurations
so the problems have probably not been seen in the wild, but will be
visible with new usecases enabled this cycle.
- Fix application of consumer scale for IIO_VAL_INT.
- Apply a scale of 1 when no scale is provided.
- Make best effort to establish a valid offset value for fractional
cases.
- Use s64 for scale calculations where parameters may be signed.
- Tidy up include order.
- Improve accuracy for small fractional sales
- Reduce risk of integer overflow.
* ams,as3935
- Use devm_delayed_work_autocancel() to replace open coded equivalent.
* aspeed,adc
- Fix wrong use of divider flag.
* atmel,sama5d2-adc
- Relax atmel,trigger-edge-type to optional.
- Drop Ludovic Desroches from listed maintainers of the dt-binding
inline with previous MAINTAINERS entry update.
* fsl,mma8452
- Fix probing when i2c_device_id used.
- dev_get_drvdata() on the iio_dev->dev, no longer returns iio_dev.
Use dev_to_iio_dev() instead. Note the original path in here
worked more by luck than design.
* invensense,mpu6050
- Drop ACPI_PTR() protection to avoid an unused warning.
- Use fact ACPI_COMPANION() returns null when ACPI_HANDLE() does to
simplify handling.
* motorola,cpcap-adc
- Drop unused assignment.
* qcom,spmi-adc
- Fix wrong example of 'reg' in binding document.
* renesas,rzg2l-adc
- Trivial typo fix.
* semtech,sx9360
- Fix wrong register handling for event generation.
* st_sensors
- Allow manual disabling of I2C or SPI module if not needed for a particular
board. Default is still to enable the bus specific module if
appropriate bus is supported.
* st,lsm6dsx
- dev_get_drvdata() on the iio_dev->dev, no longer returns iio_dev.
Use dev_to_iio_dev() instead.
* ti,palmas-gpadc
- Split the interrupt fields in the dt-binding example
* ti,tsc2046
- Rework state machine to improve readability after recent debugging of
an issue fixed elsewhere.
- Add a sanity check to avoid very large memory allocations if a crazy
delay is specified.
* ti,twl6030
- Add error handling if devm_request_threaded_irq() fails.
* xilinx,ams
- Use devm_delayed_work_autocancel() instead of open coding equivalent.
- Fix missing required clock entry in dt-binding.
- Fix miss counting of channels resulting in ps channels not
being enabled.
- Fix incorrect values written to sequencer registers.
- Fix sequence for single channel reading.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAmIfdM8RHGppYzIzQGtl
cm5lbC5vcmcACgkQVIU0mcT0FoiGlQ//UyRpMX9Bv97LAbMDnqIHLYroTLJA3WFQ
AaL/DKB1cVjBCoHlp24qaQrmncvifPF7sKJGKWf7yCHL5fraAYL/kHsCo/jECTho
QOk9QaPAMP9ChOoVoP8iz5qrdF2qyoFUG69bX+QYeKhSKzcK1QPRTQ13LIL43d9p
OJX47Cu7FfFwuAs5VKSVgpcII0tctv+Fdo6BkkeI+6w/vx2sFSzRaqRtc1ZU4Uav
s51dM9JMos52e/G8yQAEOC24QUId4EHxo7QR8WjzZ47yIHRulpYwM6pWAtvOqEy9
eV++yz581+Uqs/qaDDk8nJdpa8aEv/NvfAK6gufB9UOWziMoR3G1pPFWoOLbcyIt
IcUG+QyyEiIlmlwDE/m2OcSMzsxgrkEHNb3SE7ZkWZKP8OasGdVMHa7yEKCgLmzM
S8EY9TsNA50A2VtowAPrdk74TVG2WeIDvEH2MMAUMjgW2DzsW9cmwFrziyj7ZPLX
onoEjd/kpL2zzAArEadvzD1z1lLJcOUWn8ST2kbPQG8n/rp5y2u5PvgWRoO9zJlD
ztX614XYRgRUhMrgb0q0nCTi07mnBZrR3P8Hnx1HOoZon/DIqPSL7NumITG09cQc
fHqewQOU/WqoTH4tNvfywnBL/VAcxKFlc0B2rWIvp6dD5b0TU34ZdebcjLT1zYeC
6YQKbRaRjVg=
=UnWv
-----END PGP SIGNATURE-----
Merge tag 'iio-for-5.18a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next
Jonathan writes:
First set of new device support, fixes, cleanups and features for IIO in 5.18
This cycle we had quite a few series that applied similar changes
to lots of drivers. To keep this description manageable I have
called those out in their own section rather than per driver.
Particularly pleased to see the long running AFE precision series
going in this cycle.
Series includes some late breaking fixes.
New device support
* adi,ada4250 amplifier
- New driver and dt bindings for this programmable gain amplifier.
* adi,admv1014 microwave down-converter
- New driver, dt bindings and some device specific ABI that
may be generalized as more drivers for devices similar to this
are added.
* adi,admv4420 K Band down-converter.
- New driver and dt bindings.
* adi,adxl367 accelerometer driver.
- New driver, dt-bindings + some new IIO ABI definitions to support
reference magnitude events where an estimate of the acceleration
due to gravity has been removed.
- A few fixes as follow up patches.
* adi,ltc2688 DAC with toggle and dither modes.
- New driver and bindings. Includes some new driver specific (for now)
ABI for handling toggle mode and the addition of a dither waveform to
the DAC output.
* AFE (analog front end) add support for additional types of analog device
in front of an ADC.
- RTD temperature sensors with dt bindings.
- Temperature transducers wit dt bindings.
- Related cleanup and features listed in other sections below.
* maxim,ds3502 potentiometer.
- Add support to ds1803 driver which required significant rework.
* mediatek,mt2701-auxadc driver
- Add mediatek,mt8186-auxadc - id table and chip specific info only.
* semtech,sx9324, semtech,ax9360
- Substantial refactoring of sx9310 to extract core logic for reuse
into a separate module
- New driver using this supporting sx9324 proximity sensors.
- New driver using this supporting sx9360 proximity sensors.
* silan,sc7a20
- Compatible with the st,lis2dh (or nearly anyway) so add ID and
chip specific info to enable support. Also silan vendor ID added
for dt-bindings.
Staging graduation
* adi,ad7280a monitoring ADC for stacked lithium-ion batteries in
electric cars and similar.
- Substantial rework of driver required to bring inline with current
IIO best practice. An unusual device in IIO so some interesting features
we may see more of in future.
Multiple driver/core cleanup
- Use sysfs_emit() in simple locations where there is no path to change
to various core created attributes.
- Trivial white space fixes around inconsistency between space after { and
before } in id tables.
- Introduce new handling for fractional types to avoid repeated similar
implementations. Use this in 3 drivers. Note this is also targeted
at future use in the AFE driver and was motivated by discussions
around the precision related work on that driver.
- of related header cleanups - drop of*.h and add mod_devicetable.h as
appropriate.
- Move a number of symbol exports into IIO_* namespaces. Two categories,
1) Library used by multiple drivers e.g. st_sensors
2) Core driver module exporting functions used by bus specific modules.
A few related cleanups in this set.
- Switch from CONFIG_PM_* guards to new DEFINE_SIMPLE_DEV_PM_OPS() and
similar to simplify drivers and take advantage of these new macros
allowing the compiler to do the job or removing unused code without
the need for __maybe_unused markings. Conversion of other drivers to
these new macros ongoing.
Features
* adi,adf4350
- Switch from of specific to generic device properties enabling use with
other firmware types.
* adi,adx345
- Switch from of specific to generic device properties.
- Add ACPI ID ADS0345
- Related driver cleanup.
* adi,hmc425a
- Switch from of specific to generic device properties.
* afe analog rescaler driver
- Wider range of types supported for scale.
- Support offset.
- Kunit tests.
* atlas,ezo-sensor
- Convert from of to device properties.
* fsl,mma8452
- Support mount matrix.
* infineon,dps310:
- Add ACPI ID IFX3100.
* invensense,mpu6050
- Convert to generic device properties.
* maxim,ds1803
- Add out_raw_available before supporting more devices.
- Convert from of specific to device properties.
* samsung,ssp_sensors
- Convert from of specific to device properties.
* st,stm32-timer trigger
- Convert from of specific to device properties.
* ti,hdc101x
- Add ACPI ID TXNW1010.
* ti,tsc2046:
- Add read_raw support to enable use of iio_hwmon and similar.
Fixes / cleanup.
* mailmap
- Update for Cai Huoqing
* MAINTAINERS
- Fix Analog Devices related links.
- Add entry for ADRF6780
- Add entry for ADMV1013
- Add entry for AD7293
- Add entry for ADMV8818
- Update files listed for adis-lib
* iio core:
- Fix wrong comment about current_mode being something a driver should
ever access.
- Use struct_size() rather than open coding in industrialio-hw-consumer
* adi,axl355
- Use units.h definitions instead of local versions.
* adi,adis-lib
- Simplify *updated_bits() macro
- Whitespace cleanup.
* afe - Note many of these fixes only apply to particular configurations
so the problems have probably not been seen in the wild, but will be
visible with new usecases enabled this cycle.
- Fix application of consumer scale for IIO_VAL_INT.
- Apply a scale of 1 when no scale is provided.
- Make best effort to establish a valid offset value for fractional
cases.
- Use s64 for scale calculations where parameters may be signed.
- Tidy up include order.
- Improve accuracy for small fractional sales
- Reduce risk of integer overflow.
* ams,as3935
- Use devm_delayed_work_autocancel() to replace open coded equivalent.
* aspeed,adc
- Fix wrong use of divider flag.
* atmel,sama5d2-adc
- Relax atmel,trigger-edge-type to optional.
- Drop Ludovic Desroches from listed maintainers of the dt-binding
inline with previous MAINTAINERS entry update.
* fsl,mma8452
- Fix probing when i2c_device_id used.
- dev_get_drvdata() on the iio_dev->dev, no longer returns iio_dev.
Use dev_to_iio_dev() instead. Note the original path in here
worked more by luck than design.
* invensense,mpu6050
- Drop ACPI_PTR() protection to avoid an unused warning.
- Use fact ACPI_COMPANION() returns null when ACPI_HANDLE() does to
simplify handling.
* motorola,cpcap-adc
- Drop unused assignment.
* qcom,spmi-adc
- Fix wrong example of 'reg' in binding document.
* renesas,rzg2l-adc
- Trivial typo fix.
* semtech,sx9360
- Fix wrong register handling for event generation.
* st_sensors
- Allow manual disabling of I2C or SPI module if not needed for a particular
board. Default is still to enable the bus specific module if
appropriate bus is supported.
* st,lsm6dsx
- dev_get_drvdata() on the iio_dev->dev, no longer returns iio_dev.
Use dev_to_iio_dev() instead.
* ti,palmas-gpadc
- Split the interrupt fields in the dt-binding example
* ti,tsc2046
- Rework state machine to improve readability after recent debugging of
an issue fixed elsewhere.
- Add a sanity check to avoid very large memory allocations if a crazy
delay is specified.
* ti,twl6030
- Add error handling if devm_request_threaded_irq() fails.
* xilinx,ams
- Use devm_delayed_work_autocancel() instead of open coding equivalent.
- Fix missing required clock entry in dt-binding.
- Fix miss counting of channels resulting in ps channels not
being enabled.
- Fix incorrect values written to sequencer registers.
- Fix sequence for single channel reading.
* tag 'iio-for-5.18a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (245 commits)
iio: adc: xilinx-ams: Fix single channel switching sequence
iio: adc: xilinx-ams: Fixed wrong sequencer register settings
iio: adc: xilinx-ams: Fixed missing PS channels
dt-bindings: iio: adc: zynqmp_ams: Add clock entry
iio: accel: mma8452: use the correct logic to get mma8452_data
iio: adc: aspeed: Add divider flag to fix incorrect voltage reading.
iio: imu: st_lsm6dsx: use dev_to_iio_dev() to get iio_dev struct
dt-bindings: iio: Add ltc2688 documentation
iio: ABI: add ABI file for the LTC2688 DAC
iio: dac: add support for ltc2688
dt-bindings: iio: afe: add bindings for temperature transducers
dt-bindings: iio: afe: add bindings for temperature-sense-rtd
iio: afe: rescale: add temperature transducers
iio: afe: rescale: add RTD temperature sensor support
iio: test: add basic tests for the iio-rescale driver
iio: afe: rescale: reduce risk of integer overflow
iio: afe: rescale: fix accuracy for small fractional scales
iio: afe: rescale: add offset support
iio: afe: rescale: add INT_PLUS_{MICRO,NANO} support
iio: afe: rescale: expose scale processing function
...
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
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: 7d0ead5c3f ("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>
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
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>
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>
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 c06a6aba68
("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>
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>
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>
Commit c1d1c4a62d ("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>
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>
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>
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>
Commit 0ad4bf3701 ("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>
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: a1a210bf29 ("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>
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>
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>
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>
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>
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>
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: 5bfb3a4bd8 ("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>
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: 5bfb3a4bd8 ("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>
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>
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
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
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>
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>
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>
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>
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>
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
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>
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>
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>
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: 3bbec97733 ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
