linux.git/drivers/iio, branch v5.11-rc1

Merge tag 'staging-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

2020-12-15T22:18:40+00:00

Pull staging / IIO driver updates from Greg KH:
 "Here is the big staging and IIO driver pull request for 5.11-rc1

  Lots of different things in here:

   - loads of driver updates

   - so many coding style cleanups

   - new IIO drivers

   - Android ION code is finally removed from the tree

   - wimax drivers are moved to staging on their way out of the kernel

  Nothing really exciting, just the constant grind of kernel development :)

  All have been in linux-next for a while with no reported issues"

* tag 'staging-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (341 commits)
  staging: olpc_dcon: Do not call platform_device_unregister() in dcon_probe()
  staging: most: Fix spelling mistake "tranceiver" -> "transceiver"
  staging: qlge: remove duplicate word in comment
  staging: comedi: mf6x4: Fix AI end-of-conversion detection
  staging: greybus: Add TODO item about modernizing the pwm code
  pinctrl: ralink: add a pinctrl driver for the rt2880 family
  dt-bindings: pinctrl: rt2880: add binding document
  staging: rtl8723bs: remove ELEMENT_ID enum
  staging: rtl8723bs: remove unused macros
  staging: rtl8723bs: replace EID_EXTCapability
  staging: rtl8723bs: replace EID_BSSIntolerantChlReport
  staging: rtl8723bs: replace EID_BSSCoexistence
  staging: rtl8723bs: replace _MME_IE_
  staging: rtl8723bs: replace _WAPI_IE_
  staging: rtl8723bs: replace _EXT_SUPPORTEDRATES_IE_
  staging: rtl8723bs: replace _ERPINFO_IE_
  staging: rtl8723bs: replace _CHLGETXT_IE_
  staging: rtl8723bs: replace _COUNTRY_IE_
  staging: rtl8723bs: replace _IBSS_PARA_IE_
  staging: rtl8723bs: replace _TIM_IE_
  ...

iio: adc: rockchip_saradc: fix missing clk_disable_unprepare() on error in rockchip_saradc_resume

2020-12-03T19:40:31+00:00

Fix the missing clk_disable_unprepare() of info->pclk
before return from rockchip_saradc_resume in the error
handling case when fails to prepare and enable info->clk.

Suggested-by: Robin Murphy 
Fixes: 44d6f2ef94f9 ("iio: adc: add driver for Rockchip saradc")
Signed-off-by: Qinglang Miao 
Cc: 
Link: https://lore.kernel.org/r/20201103120743.110662-1-miaoqinglang@huawei.com
Signed-off-by: Jonathan Cameron

iio: imu: st_lsm6dsx: fix edge-trigger interrupts

2020-12-03T19:40:31+00:00

If we are using edge IRQs, new samples can arrive while processing
current interrupt since there are no hw guarantees the irq line
stays "low" long enough to properly detect the new interrupt.
In this case the new sample will be missed.
Polling FIFO status register in st_lsm6dsx_handler_thread routine
allow us to read new samples even if the interrupt arrives while
processing previous data and the timeslot where the line is "low"
is too short to be properly detected.

Fixes: 89ca88a7cdf2 ("iio: imu: st_lsm6dsx: support active-low interrupts")
Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver")
Signed-off-by: Lorenzo Bianconi 
Link: https://lore.kernel.org/r/5e93cda7dc1e665f5685c53ad8e9ea71dbae782d.1605378871.git.lorenzo@kernel.org
Cc: 
Signed-off-by: Jonathan Cameron

iio: sysfs-trigger: Mark irq_work to expire in hardirq context

2020-12-03T19:40:30+00:00

Mark the IIO sysfs-trigger irq_work with IRQ_WORK_HARD_IRQ to ensure that
it is always executed in hard interrupt context, even with PREEMPT_RT=y.

The IIO sysfs-trigger irq_work needs to run in hard interrupt context since
it will end up calling generic_handle_irq() which has the requirement to
run in hard interrupt context.

Note that the IRQ_WORK_HARD_IRQ flag, while it exists, does not seem to do
anything in the mainline kernel yet. It does have an effect in the RT
patchset though and presumably this is sooner or later going to be added to
mainline as well.

Reported-by: Christian Eggers 
Signed-off-by: Lars-Peter Clausen 
Acked-by: Sebastian Andrzej Siewior 
Link: https://lore.kernel.org/r/20201117103751.16131-2-lars@metafoo.de
Signed-off-by: Jonathan Cameron

iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt context

2020-12-03T19:40:30+00:00

On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft
interrupt expiry mode by default.

The IIO hrtimer-trigger needs to run in hard interrupt context since it
will end up calling generic_handle_irq() which has the requirement to run
in hard interrupt context.

Explicitly specify that the timer needs to run in hard interrupt context by
using the HRTIMER_MODE_REL_HARD flag.

Fixes: f5c2f0215e36 ("hrtimer: Move unmarked hrtimers to soft interrupt expiry on RT")
Reported-by: Christian Eggers 
Signed-off-by: Lars-Peter Clausen 
Acked-by: Sebastian Andrzej Siewior 
Link: https://lore.kernel.org/r/20201117103751.16131-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron

iio: accel: bmc150: Get mount-matrix from ACPI

2020-12-03T19:40:30+00:00

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 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20201130141954.339805-3-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron

iio: accel: bmc150: Check for a second ACPI device for BOSC0200

2020-12-03T19:40:30+00:00

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 
Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
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

iio: accel: bmc150: Removed unused bmc150_accel_dat irq member

2020-12-03T19:40:29+00:00

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 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20201130141954.339805-1-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron

iio:gyro:mpu3050 Treat otp value as a __le64 and use FIELD_GET() to break up

2020-12-03T19:40:29+00:00

Inspired by Andy Shevchenko's proposal to use get_unaligned_leXX().

The whole one time programable memory is treated as a single 64bit
little endian value.  Thus we can avoid a lot of messy handling
of fields overlapping byte boundaries by just loading and manipulating
it as an __le64 converted to a u64.  That lets us just use FIELD_GET()
and GENMASK() to extract the values desired.

Note only build tested. We need to use GENMASK_ULL and %llX formatters
to account for the larger types used in computing the various fields.

Signed-off-by: Jonathan Cameron 
Tested-by: Linus Walleij 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Linus Walleij 
Cc: Andy Shevchenko 
Cc: Linus Walleij 
Link: https://lore.kernel.org/r/20201128185156.428327-1-jic23@kernel.org
Link: https://lore.kernel.org/r/20201129184459.647538-1-jic23@kernel.org

iio:adc:ti-ads124s08: Fix alignment and data leak issues.

2020-12-03T19:40:29+00:00

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 an 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
explicitly requested.  This data is allocated with kzalloc() so no
data can leak apart from previous readings.

In this driver the timestamp can end up in various different locations
depending on what other channels are enabled.  As a result, we don't
use a structure to specify it's position as that would be misleading.

Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
Reported-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Reviewed-by: Alexandru Ardelean 
Cc: Dan Murphy 
Cc: 
Link: https://lore.kernel.org/r/20200920112742.170751-9-jic23@kernel.org