Jonathan Cameron [Sun, 30 Jan 2022 19:31:46 +0000 (19:31 +0000)]
iio:light:rpr0521: Switch from CONFIG_PM guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:45 +0000 (19:31 +0000)]
iio:chemical:atlas: Switch from CONFIG_PM guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:44 +0000 (19:31 +0000)]
iio:proximity:pulsedlight: Switch from CONFIG_PM guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:43 +0000 (19:31 +0000)]
iio:light:bh1780: Switch from CONFIG_PM guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Use the new DEFINE_RUNTIME_DEV_PM_OPS to reduce boilerplate.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:42 +0000 (19:31 +0000)]
iio:adc:rcar: Switch from CONFIG_PM guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:41 +0000 (19:31 +0000)]
iio:adc:stm32:Switch from CONFIG_PM guards to pm_ptr()
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
The new DEFINE_RUNTIME_DEV_PM_OPS() macro reduces boilerplate.
Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20220130193147.279148-45-jic23@kernel.org
Jonathan Cameron [Sun, 30 Jan 2022 19:31:40 +0000 (19:31 +0000)]
iio:adc:ab8500: Switch from CONFIG_PM guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
This case uses the new DEFINE_RUNTIME_DEV_PM_OPS() to reduce
boilerplate.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:39 +0000 (19:31 +0000)]
iio:temperature:mlx90614: Switch from CONFIG_PM* guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without one or more of CONFIG_PM/CONFIG_PM_SLEEP support is simpler and
less error prone than the use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:38 +0000 (19:31 +0000)]
iio:imu:kmx61: Switch from CONFIG_PM* guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without one or more of CONFIG_PM/CONFIG_PM_SLEEP support is simpler and
less error prone than the use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:37 +0000 (19:31 +0000)]
iio:dac:m62332: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Note that in this case the storage for saving state was protected
by CONFIG_PM guards. The storage is very small and unlikely to make
any real difference to the space allocated for state so just drop
those guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:36 +0000 (19:31 +0000)]
iio:accel:bma180: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:35 +0000 (19:31 +0000)]
iio:accel:stk8312: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:34 +0000 (19:31 +0000)]
iio:temperature:tmp007: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:33 +0000 (19:31 +0000)]
iio:temperature:tmp006: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:32 +0000 (19:31 +0000)]
iio:proximity:sx9500: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:31 +0000 (19:31 +0000)]
iio:proximity:rfd77492: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:30 +0000 (19:31 +0000)]
iio:proximity:as3935: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20220130193147.279148-34-jic23@kernel.org
Jonathan Cameron [Sun, 30 Jan 2022 19:31:29 +0000 (19:31 +0000)]
iio:pressure:mpl3115: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:28 +0000 (19:31 +0000)]
iio:magn:mmc35240: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards. Also use SIMPLE_DEV_PM_OPS instead
of open-coding the equivalent.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:27 +0000 (19:31 +0000)]
iio:magn:mag3110: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:26 +0000 (19:31 +0000)]
iio:magn:ak8975: Switch from CONFIG_PM guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Use the new DEFINE_RUNTIME_DEV_PM_OPS() macro to reduce boilerplate.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Jonathan Albrieux <jonathan.albrieux@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20220130193147.279148-30-jic23@kernel.org
Jonathan Cameron [Sun, 30 Jan 2022 19:31:25 +0000 (19:31 +0000)]
iio:light:tsl4531: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:24 +0000 (19:31 +0000)]
iio:light:tsl2563: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:23 +0000 (19:31 +0000)]
iio:light:tcs3472: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:22 +0000 (19:31 +0000)]
iio:light:tcs3414: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:21 +0000 (19:31 +0000)]
iio:light:stk3310: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:20 +0000 (19:31 +0000)]
iio:light:ltr501: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:19 +0000 (19:31 +0000)]
iio:light:jsa1212: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:18 +0000 (19:31 +0000)]
iio:light:isl29125: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:17 +0000 (19:31 +0000)]
iio:light:isl29018: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr()
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:16 +0000 (19:31 +0000)]
iio:light:cm3232: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards. Also switch to SIMPLE_DEV_PM_OPS rather
than opencoding the same.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:15 +0000 (19:31 +0000)]
iio:light:apds9300: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:14 +0000 (19:31 +0000)]
iio:dac:vf610: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:13 +0000 (19:31 +0000)]
iio:common:ssp: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of ifdef based config guards. Also switch to SIMPLE_DEV_PM_OPS
rather than open coding the structure.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:12 +0000 (19:31 +0000)]
iio:adc:vf610: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:11 +0000 (19:31 +0000)]
iio:adc:twl6030: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:10 +0000 (19:31 +0000)]
iio:adc:rockchip: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:09 +0000 (19:31 +0000)]
iio:adc:palmas_gpadc: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr()
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
In this case SIMPLE_DEV_PM_OPS() could have been used previously.
Now we have DEFINE_SIMPLE_DEV_PM_OPS() which also deals with letting
the compiler remove the structure and functions so use that instead.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:08 +0000 (19:31 +0000)]
iio:adc:exynos_adc: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr()
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:07 +0000 (19:31 +0000)]
iio:adc:at91-adc: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20220130193147.279148-11-jic23@kernel.org
Jonathan Cameron [Sun, 30 Jan 2022 19:31:06 +0000 (19:31 +0000)]
iio:accel:stk8ba50: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:05 +0000 (19:31 +0000)]
iio:accel:mma9553: Switch from CONFIG_PM guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:04 +0000 (19:31 +0000)]
iio:accel:mma9551: Switch from CONFIG_PM guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:03 +0000 (19:31 +0000)]
iio:accel:mma7660: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr()
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:02 +0000 (19:31 +0000)]
iio:accel:mc3230: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:01 +0000 (19:31 +0000)]
iio:accel:dmard10: Switch from CONFIG_PM guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:31:00 +0000 (19:31 +0000)]
iio:accel:dmard06: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:30:59 +0000 (19:30 +0000)]
iio:accel:da280: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 19:30:58 +0000 (19:30 +0000)]
iio:accel:da311: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Jonathan Cameron [Sun, 30 Jan 2022 20:57:01 +0000 (20:57 +0000)]
iio:chemical:bme680: Move exports to IIO_BME680 namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the bus specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 30 Jan 2022 20:57:00 +0000 (20:57 +0000)]
iio:light:st_uvis25: Move exports to IIO_UVIS25 namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the bus specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 30 Jan 2022 20:56:59 +0000 (20:56 +0000)]
iio:magnetometer:hmc5843: Move exports to IIO_HMC5843 namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the bus specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 30 Jan 2022 20:56:58 +0000 (20:56 +0000)]
iio:magnetometer:bmc150: Move exports to IIO_BMC150_MAGN namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the bus specific device drivers that use them.
Note the MAGN postfix here is reflecting that this driver is only
responsible for part of the BMC150 device.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 30 Jan 2022 20:56:57 +0000 (20:56 +0000)]
iio:magnetometer:rm3100: Move exports to IIO_RM3100 namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the bus specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 30 Jan 2022 20:56:56 +0000 (20:56 +0000)]
iio:pressure:mpl115: Move exports into IIO_MPL115 namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the bus specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 30 Jan 2022 20:56:55 +0000 (20:56 +0000)]
iio:pressure:ms5611: Move exports into IIO_MS5611 namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the bus specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 30 Jan 2022 20:56:54 +0000 (20:56 +0000)]
iio:pressure:zpa2326: Move exports into IIO_ZPA2326 namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the bus specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 30 Jan 2022 20:56:53 +0000 (20:56 +0000)]
iio:imu:adis: Move exports into IIO_ADISLIB namespace
In order to avoid unneessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the various specific device drivers that use them.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220130205701.334592-9-jic23@kernel.org
Jonathan Cameron [Sun, 30 Jan 2022 20:56:52 +0000 (20:56 +0000)]
iio:dac:ad5686: Move exports into IIO_AD5686 namespace
Note these are used in the related ad5696-i2c drivers as well as the
more obviously connected ad5686-spi driver.
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the various specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 30 Jan 2022 20:56:51 +0000 (20:56 +0000)]
iio:dac:ad5592r: Move exports into IIO_AD5592R namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the various specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220130205701.334592-7-jic23@kernel.org
Jonathan Cameron [Sun, 30 Jan 2022 20:56:50 +0000 (20:56 +0000)]
iio:common:ssp_sensors: Move exports into IIO_SSP_SENSORS namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the various specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Both the exports used between the two common modules and the individual
drivers are moved to a single namespace as greater granularity does
not feel useful.
Jonathan Cameron [Sun, 30 Jan 2022 20:56:49 +0000 (20:56 +0000)]
iio:common:meas-spec: Move exports into IIO_MEAS_SPEC_SENSORS
The obvious choice of ms_sensors felt rather too likely to clash with other
namespaces introduced in future, hence the longer abbreviation.
In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the various specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: William Markezana <william.markezana@meas-spec.com> Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220130205701.334592-5-jic23@kernel.org
Jonathan Cameron [Sun, 30 Jan 2022 20:56:48 +0000 (20:56 +0000)]
iio:adc:ad76060: Move exports into IIO_AD7606 namespace.
In order to avoid unnecessary pollution of the global symbol namespace
move the core/library functions into a specific namespace and import
that into the various bus specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 30 Jan 2022 20:56:47 +0000 (20:56 +0000)]
iio:adc:ad7091r: Move exports into IIO_AD7091R namespace.
In order to avoid unnecessary pollution of the global symbol namespace
move the core/library functions into a specific namespace and import
that into the various specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
An alternative here would be to conclude that we are unlikely to see
support for the other ad7091r parts in the near future and just merge
the two modules into one supporting just the i2c -5 variant.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220130205701.334592-3-jic23@kernel.org
Jonathan Cameron [Sun, 30 Jan 2022 20:56:46 +0000 (20:56 +0000)]
iio:adc:ad_sigma_delta: Move exports into IIO_AD_SIGMA_DELTA namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the core/library functions into a specific namespace and import
that into the various specific device drivers that use them.
For more information see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Renato Lui Geh <renatogeh@gmail.com> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220130205701.334592-2-jic23@kernel.org
Jonathan Cameron [Sun, 16 Jan 2022 18:05:35 +0000 (18:05 +0000)]
iio:st-sensors: Move exports into IIO_ST_SENSORS namespace
To avoid unnecessary pollution of the global symbol namespace move the
driver core and type specific core exports into their a new namespace
and import that where needed.
For more info see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 16 Jan 2022 18:05:34 +0000 (18:05 +0000)]
iio:st-sensors: Remove duplicate MODULE_*
The core module and type specific core modules are made up of
several files. There is no benefit in duplicating the MODULE_* macros
in each file so remove them.
Noticed whilst adding MODULE_IMPORT_NS() as I missed some files and
it still worked, making it clear not all of these blocks were needed.
Jonathan Cameron [Sun, 16 Jan 2022 18:05:33 +0000 (18:05 +0000)]
iio:accel:fxl8962af: Move exports into IIO_FXL8962AF namespace
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 16 Jan 2022 18:05:32 +0000 (18:05 +0000)]
iio:accel:bmi088: Move exports into IIO_BMI088 namespace
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 16 Jan 2022 18:05:31 +0000 (18:05 +0000)]
iio:accel:bmc150: Move exports into IIO_BMC150 namespace
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 16 Jan 2022 18:05:30 +0000 (18:05 +0000)]
iio:accel:adxl372: Move exports into IIO_ADXL372 namespace
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 16 Jan 2022 18:05:29 +0000 (18:05 +0000)]
iio:accel:adxl355: Move exports into IIO_ADXL355 namespace
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 16 Jan 2022 18:05:28 +0000 (18:05 +0000)]
iio:accel:adxl345: Move exports into IIO_ADXL345 namespace
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
Jonathan Cameron [Sun, 16 Jan 2022 18:05:27 +0000 (18:05 +0000)]
iio:accel:adxl313: Move exports into IIO_ADXL313 namespace
In order 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.
Jonathan Cameron [Sun, 16 Jan 2022 18:05:26 +0000 (18:05 +0000)]
iio:accel:bma400: Move exports into IIO_BMA400 namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the core bma400 functions into a bma400 specific namespace
and import that into the two bus modules.
Jonathan Cameron [Sun, 16 Jan 2022 18:05:25 +0000 (18:05 +0000)]
iio:accel:kxsd9: Move exports into IIO_KDSD9 namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the core kxsd9 functions into a kxsd9 specific namespace and import
that into the two bus modules.
For more information see https://lwn.net/Articles/760045/
Jonathan Cameron [Sun, 16 Jan 2022 18:05:24 +0000 (18:05 +0000)]
iio:accel:mma7455_core: Move exports into IIO_MMA7455 namespace
In order to avoid unnecessary pollution of the global symbol namespace
move the core mma7455 functions into an mma7455 specific namespace and
import that into the two bus modules.
For more information see https://lwn.net/Articles/760045/
This chip is not an ST part, but it appears to be register-compatible
with the LIS2DH, so it can use the same binding.
Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220202235049.8051-3-samuel@sholland.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Hangzhou Silan Microelectronics Co., Ltd. (http://www.silan.com.cn/) is
a manufacturer of ICs, including MEMS sensors.
Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220202235049.8051-2-samuel@sholland.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Hans de Goede [Tue, 8 Feb 2022 12:43:35 +0000 (13:43 +0100)]
iio: mma8452: Fix probe failing when an i2c_device_id is used
The mma8452_driver declares both of_match_table and i2c_driver.id_table
match-tables, but its probe() function only checked for of matches.
Add support for i2c_device_id matches. This fixes the driver not loading
on some x86 tablets (e.g. the Nextbook Ares 8) where the i2c_client is
instantiated by platform code using an i2c_device_id.
Drop of_match_ptr() protection to avoid unused warning.
Colin Ian King [Mon, 7 Feb 2022 13:59:43 +0000 (13:59 +0000)]
iio: adc: cpcap-adc: remove redundant assignment to variable cal_data_diff
The variable cal_data_diff is being assigned a value that is never read,
it is being re-assigned later on with a new value in both paths of an
if statement. The assignment is redundant, so remove it.
Update the maintainers entry to match the changes made back in
mid-2020 with 853fa48717c2 ("MAINTAINERS: adc: at91-sama5d2_adc:
remove myself as co-maintainer").
projects / users / jedix / linux-maple.git / log