Fix all the brace code style warnings found by the checkpatch tool at the following lines:
rtw_ioctl_set.c:178: WARNING: braces {} are not necessary for any arm of this statement
rtw_ioctl_set.c:219: WARNING: braces {} are not necessary for any arm of this statement
rtw_ioctl_set.c:255: WARNING: braces {} are not necessary for any arm of this statement
rtw_ioctl_set.c:324: WARNING: braces {} are not necessary for any arm of this statement
rtw_ioctl_set.c:372: WARNING: braces {} are not necessary for any arm of this statement
rtw_ioctl_set.c:396: WARNING: braces {} are not necessary for any arm of this statement
rtw_ioctl_set.c:441: WARNING: braces {} are not necessary for single statement blocks
rtw_ioctl_set.c:527: WARNING: braces {} are not necessary for any arm of this statement
Signed-off-by: Brother Matthew De Angelis <matthew.v.deangelis@gmail.com>
Link: https://lore.kernel.org/r/20201203025836.GA420974@a
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan writes:
2nd set of IIO device support, features, cleanups and yaml conversions for 5.11
v2: Fix some missing Sign offs from me that Greg found in v1.
Includes low priority/late breaking/long standing bug fixes.
Note this includes the last few patches that were listed in the description
for the previous pull request but weren't actually in the PULL.
New devices support
* bosch,bmc150-accel
- Support for BMA222, including adding binding doc that was previously
missing.
* st,lsm6dsx
- Support LSM6DSOP accelerometer + gyroscope sensor.
yaml-conversions by manufacturer
* core
- adc
- iio-binding (drop as now in dt-schema)
- temperature (drop as not clear it is generic)
* generic (no specific manufacturer)
- dpot-dac
- current-sense-amplifier
- current-sense-shunt
- envelope-detector
- voltage-divider
* adi,ad5592r adi,ad7124 adi,ad7292 adi,adf4350
* atmel,sama9260-adc
* bosch,bma180 bosch,bmg180
* brcm,iproc-static-adc
* capella,cm3605
* fsl,mma8452
* kionix,kxcjk1013
* maxim,max1027 (from trivial)
* mediatek,mt2701-auxdac
* microchip,mcp4531 (from trivial)
* qcom,pm8018-adc qcom,spi-iadc
* st,st-sensors
* ti,ads124s08 ti,afe4403 ti,afe4404 ti,lmp91000 ti,palmas-gpadc
Features
* bosch,bmc150
- Handle unusual ACPI binding where two devices are provided in a single
ACPI device (BOSC0200).
- ACPI based mount matrix handling
* st,hts221
- regulator control
* st,lsm6dsx
- regulator control
Cleanup + minor fixes
* core
- Reduce duplication in iio_format_avail_{list,range}() and iio_format_list()
- Fix an issue in the demux update code that could lead to misaligned data.
Possible no existing driver hits this. Been there a very long time with
no bug reports.
- Improve iio_map_array_register() error handling.
- Avoid polling driver again if try_reenable() callback returns non 0.
Only users of this were bugs so also drop the return value.
* core/cb_buffer
- Return an error if no callback provided (include adding a dummy for one
unusual case where no callback is valid).
* trigger/hrtimer-trig, sysfs-trig
- Fix an issue seen with PREEMPT_RT by marking irq_work as expiring in hard
interrupt context.
* adi,ad_sigma_delta library
- Avoid putting SPI transfer buffers on stack for DMA safety reasons
* adi,ad5272
- Fix discrepancy in polarity of reset line between binding documentation
(which was right) and driver.
* adi,ad7298
- Use devm for all of probe
* atmel,at91_adc
- Drop at91_adc_ids as only support DT probe
- Simplify resolution selection and bindings
- Drop binding for triggers and move into driver based on compatible.
- Merge at91_adc_probe_dt() into main at91_adc_probe()
* bosch,bmc150
- Drop unused structure member.
* bosch,bmi160
- Fix overly long buffer due to wrong channel count.
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* fsl,mag3110
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* fsl,mpl3115
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* invn,mpu3050
- Use 64 bit local variable and FIELD_GET to simplify code that extracts
values from OTP.
* qcom,spmi-vadc
- Drop wrong use of io-channel-ranges in binding doc.
* rockchip,saradc
- Fix a missing clk_disable_unprepare() in an error path.
* rohm,rpr0521
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* samsung,exynos-adc
- Drop wrong use of io-channel-ranges in binding doc.
* st,lsm6dsx
- Reduce duplication in the chip model specific tables.
- Fix an issue with missed edge-interrupts that can occur when using
the FIFO.
* st,uvis21
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
* ti,adc084s021
- Tidy up endian types to clear a warning.
* ti,ads124s08
- Fix too long a buffer.
- Fix potential buffer alignment into iio_push_to_buffers_with_timestamp()
Counter
* microchip,tcb-counter
- Add Kamel Bouhara to MAINTAINERS
- Fix CMR value check
* tag 'iio-for-5.11b-take2' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (80 commits)
iio: adc: rockchip_saradc: fix missing clk_disable_unprepare() on error in rockchip_saradc_resume
iio: imu: st_lsm6dsx: fix edge-trigger interrupts
counter: microchip-tcb-capture: Fix CMR value check
iio: sysfs-trigger: Mark irq_work to expire in hardirq context
iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt context
iio: accel: bmc150: Get mount-matrix from ACPI
iio: accel: bmc150: Check for a second ACPI device for BOSC0200
iio: accel: bmc150: Removed unused bmc150_accel_dat irq member
iio:gyro:mpu3050 Treat otp value as a __le64 and use FIELD_GET() to break up
iio:adc:ti-ads124s08: Fix alignment and data leak issues.
iio:adc:ti-ads124s08: Fix buffer being too long.
iio:pressure:mpl3115: Force alignment of buffer
iio:imu:bmi160: Fix alignment and data leak issues
iio:imu:bmi160: Fix too large a buffer.
iio:magnetometer:mag3110: Fix alignment and data leak issues.
iio:light:st_uvis25: Fix timestamp alignment and prevent data leak.
iio:light:rpr0521: Fix timestamp alignment and prevent data leak.
iio:adc:ti-adc084s021 Tidy up endian types
iio:trigger: rename try_reenable() to reenable() plus return void
iio: Fix: Do not poll the driver again if try_reenable() callback returns non 0.
...
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: 89ca88a7cd ("iio: imu: st_lsm6dsx: support active-low interrupts")
Fixes: 290a6ce11d ("iio: imu: add support to lsm6dsx driver")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/5e93cda7dc1e665f5685c53ad8e9ea71dbae782d.1605378871.git.lorenzo@kernel.org
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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 <ceggers@arri.de>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20201117103751.16131-2-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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: f5c2f0215e ("hrtimer: Move unmarked hrtimers to soft interrupt expiry on RT")
Reported-by: Christian Eggers <ceggers@arri.de>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20201117103751.16131-1-lars@metafoo.de
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>
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: e717f8c6df ("iio: adc: Add the TI ads124s08 ADC code")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-9-jic23@kernel.org
Whilst this is another case of the issue Lars reported with
an array of elements of smaller than 8 bytes being passed
to iio_push_to_buffers_with_timestamp(), the solution here is
a bit different from the other cases and relies on __aligned
working on the stack (true since 4.6?)
This one is unusual. We have to do an explicit memset() each time
as we are reading 3 bytes into a potential 4 byte channel which
may sometimes be a 2 byte channel depending on what is enabled.
As such, moving the buffer to the heap in the iio_priv structure
doesn't save us much. We can't use a nice explicit structure
on the stack either as the data channels have different storage
sizes and are all separately controlled.
Fixes: cc26ad455f ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-7-jic23@kernel.org
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 array 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, depending on which channels are enabled, the timestamp
can be in a number of locations. Hence we cannot use a structure
to specify the data layout without it being misleading.
Fixes: 77c4ad2d6a ("iio: imu: Add initial support for Bosch BMI160")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Daniel Baluta <daniel.baluta@oss.nxp.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org
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.
This data is allocated with kzalloc() so no data can leak apart from
previous readings.
The explicit alignment of ts is not necessary in this case but
does make the code slightly less fragile so I have included it.
Fixes: 39631b5f95 ("iio: Add Freescale mag3110 magnetometer driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org
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()
This data is allocated with kzalloc() so no data can leak apart
from previous readings.
A local unsigned int variable is used for the regmap call so it
is clear there is no potential issue with writing into the padding
of the structure.
Fixes: 3025c8688c ("iio: light: add support for UVIS25 sensor")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-3-jic23@kernel.org
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().
This data is allocated with kzalloc() so no data can leak apart
from previous readings and in this case the status byte from the device.
The forced alignment of ts is not necessary in this case but it
potentially makes the code less fragile.
>From personal communications with Mikko:
We could probably split the reading of the int register, but it
would mean a significant performance cost of 20 i2c clock cycles.
Fixes: e12ffd241c ("iio: light: rpr0521 triggered buffer")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Mikko Koivunen <mikko.koivunen@fi.rohmeurope.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-2-jic23@kernel.org
By adding a few local variables and avoiding a void * for
a parameter we can easily make all the endian types explicit and
get rid of the warnings from sparse:
CHECK drivers/iio/adc/ti-adc084s021.c
drivers/iio/adc/ti-adc084s021.c:84:26: warning: incorrect type in assignment (different base types)
drivers/iio/adc/ti-adc084s021.c:84:26: expected unsigned short [usertype]
drivers/iio/adc/ti-adc084s021.c:84:26: got restricted __be16
drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16
drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16
drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16
drivers/iio/adc/ti-adc084s021.c:115:24: warning: cast to restricted __be16
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200722155103.979802-23-jic23@kernel.org
The original reason for this behaviour is long gone and no current
drivers are making use of this function correctly. Note however, that
you would be very unlucky to actually hit the problem as it would
require a bus comms failure in the callback.
This dates back a long way. The original board on which I did a lot
of early IIO development only supported edge interrupts, but some of the
sensors were level interrupt based. As such, the lis3l02dq driver did
a dance with checking a GPIO to identify if it should retrigger.
That was an unsustainable hack so we later just stopped supporting interrupts
for that particular combination.
There are a number of drivers where a fault on a bus read in the
try_reenable() callback will result in them returning non 0 and
incorrectly then causing iio_trigger_poll() to be called.
Anyhow, this handling is unused and causing issues so let us rip it out.
Link: https://lore.kernel.org/linux-iio/20200813075358.13310-1-lars@metafoo.de/
After this the try_reenable() naming makes no sense, so as a follow up
patch I'll rename it to simply reenable(). I haven't done that here
as it will add noise to the fix for backporting.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Christian Eggers <ceggers@arri.de>
Link: https://lore.kernel.org/r/20200920132548.196452-2-jic23@kernel.org
There are a few things we would do differently in an ADC binding if we
were starting from scratch but we are stuck with what we have (which
made sense back when this was written!)
We may be able to tighten up some elements of this binding in the future
by careful checking of what values properties can actually take.
Note the unusual sign off chain is representative of the path this patch
took.
Jonathan wrote the patch, which was then included in a series by
Alexandre and ultimately applied by Jonathan.
[Alexandre Belloni: add sama5d3, remove atmel,adc-res and atmel,adc-res-names]
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-5-alexandre.belloni@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Move the possible resolution values back to the driver. This removes the
atmel,adc-res and atmel,adc-res-names properties, leaving only
atmel,adc-use-res. As atmel,adc-res-names had to contain "lowres" and
"highres", those where already the only allowed values for
atmel,adc-use-res.
Also introduce a new compatible string for the sama5d3 as this is the only
one with a different resolution. Also it doesn't even have the LOWRES
bit.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-3-alexandre.belloni@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We use this part in an example for the envelope detector. That showed
that we need to allow for the #io-channel-cells property which
trivial-devices.yaml does not.
It doesn't make sense to add that property to trivial-devices as
it only applies for those devices that can provide some sort of
DAC or ADC service to another device driver. Hence solution will
be to pull some IIO devices out to have their own file on a case
by case basis.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-4-jic23@kernel.org
