linux-dev/drivers/iio/common, branch linus/master

iio: Replace strtobool() with kstrtobool()

2022-04-28T18:22:54Z

strtobool() is deprecated and just a wrapper around kstrtobool().Replace it with kstrtobool() so the deprecated function can be removed eventually. Suggested-by: Andy Shevchenko Signed-off-by: Lars-Peter Clausen Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220409105812.2113895-1-lars@metafoo.de Signed-off-by: Jonathan Cameron

iio: core: Simplify the registration of kfifo buffers

2022-04-10T15:25:46Z

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 Cc: Guenter Roeck Cc: Jyoti Bhayana Cc: Jean-Baptiste Maneyrol Cc: Lorenzo Bianconi Cc: Michael Hennerich Cc: Greg Kroah-Hartman Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20220207143840.707510-13-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron

iio: st_sensors: Use iio_device_claim/release_direct_mode() when relevant

2022-04-10T15:21:45Z

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 Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20220207143840.707510-9-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron

iio: st_sensors: Add a local lock for protecting odr

2022-04-10T15:21:45Z

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 Cc: Denis Ciocca Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20220207143840.707510-7-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron

iio: st_sensors: Drop the protection on _avail functions

2022-04-10T15:15:02Z

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 Cc: Denis Ciocca Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20220207143840.707510-6-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron

iio: ssp_sensors: replace usage of found with dedicated list iterator variable

2022-04-04T08:11:25Z

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 Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20220331230632.957634-2-jakobkoschel@gmail.com Signed-off-by: Jonathan Cameron

Merge tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2022-03-28T19:27:35Z

Pull char/misc and other driver updates from Greg KH: "Here is the big set of char/misc and other small driver subsystem updates for 5.18-rc1. Included in here are merges from driver subsystems which contain: - iio driver updates and new drivers - fsi driver updates - fpga driver updates - habanalabs driver updates and support for new hardware - soundwire driver updates and new drivers - phy driver updates and new drivers - coresight driver updates - icc driver updates Individual changes include: - mei driver updates - interconnect driver updates - new PECI driver subsystem added - vmci driver updates - lots of tiny misc/char driver updates All of these have been in linux-next for a while with no reported problems" * tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (556 commits) firmware: google: Properly state IOMEM dependency kgdbts: fix return value of __setup handler firmware: sysfb: fix platform-device leak in error path firmware: stratix10-svc: add missing callback parameter on RSU arm64: dts: qcom: add non-secure domain property to fastrpc nodes misc: fastrpc: Add dma handle implementation misc: fastrpc: Add fdlist implementation misc: fastrpc: Add helper function to get list and page misc: fastrpc: Add support to secure memory map dt-bindings: misc: add fastrpc domain vmid property misc: fastrpc: check before loading process to the DSP misc: fastrpc: add secure domain support dt-bindings: misc: add property to support non-secure DSP misc: fastrpc: Add support to get DSP capabilities misc: fastrpc: add support for FASTRPC_IOCTL_MEM_MAP/UNMAP misc: fastrpc: separate fastrpc device from channel context dt-bindings: nvmem: brcm,nvram: add basic NVMEM cells dt-bindings: nvmem: make "reg" property optional nvmem: brcm_nvram: parse NVRAM content into NVMEM cells nvmem: dt-bindings: Fix the error of dt-bindings check ...

iio:common:ssp: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc

2022-02-18T11:45:29Z

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. Signed-off-by: Jonathan Cameron Reviewed-by: Paul Cercueil Link: https://lore.kernel.org/r/20220130193147.279148-17-jic23@kernel.org

iio:common:ssp_sensors: Move exports into IIO_SSP_SENSORS namespace

2022-02-18T11:42:26Z

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. Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220130205701.334592-6-jic23@kernel.org

iio:common:meas-spec: Move exports into IIO_MEAS_SPEC_SENSORS

2022-02-18T11:42:26Z

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 Cc: Alexandre Belloni Cc: William Markezana Cc: Ludovic Tancerel Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220130205701.334592-5-jic23@kernel.org