usb_read_port prepares a bulk in urb and calls usb_submit_urb to pass the
usb to the usb core. It seems wrong that usb_read_port returns success to
its caller if usb_submit_urb failed with -EPERM.
According to drivers/usb/core/urb.c, usb_submit_urb returns -EPERM when
an urb is resubmitted after being cancelled by usb_kill_urb etc.
The only caller who checks the return value of usb_read_port is
rtw_hal_inirp_init. This function submits the bulk in urbs for the first
time after the netdevice is opened. We'll not receive -EPERM from
usb_submit_urb in this case. The urbs are resubmitted by
read_port_complete, which does not check for errors from usb_read_port.
This driver may kill pending bulk in urbs when the netdevice is closed when
the driver is unloaded or the system goes to sleep. I don't think that this
will interrupt an ongoing netdev open.
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20210620174057.10201-1-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan writes:
Second set of Counter and IIO new device support, cleanups etc for 5.14
Counter
------
First part of general rework of counter subsystem to add a chrdev interface
for event drive data capture. Most of it will hopefully land next cycle.
* Consolidate documentation to avoid multiple copies of same docs in per
device files.
* Constify various arrays etc across subsystem.
* 104-quad-8:
- Annotate the module config parameter to avoid using it when kernel is
locked down.
- Spelling and trivial comment drops etc
* Intel QEP
- Follow up cleanups of trivial stuff from initial patch series.
IIO
---
Includes some cleanups as part of two ongoing audits
- runtime pm usage in IIO.
- Insufficient alignment on buffers passed to
iio_push_to_buffers_with_timstamp()
New device support
* bosch,bmc150
- Add ID for BMA253
Minor features / cleanups / minor fixes / late breaking fixes
* iio_push_to_buffers_with_timestamp() alignment fixes.
This set includes those where the best option is to mark the buffer as
__aligned(8). Normally this choice was made because there is too high a degree
of possible variation in number of channels enabled to be able to guarantee
the timestamp was always in the same location. This ruled out the more
obvious structure form used in other drivers. Only one small class of
related issues have patches under review and we can finally tighten up the
explicit rules to reflect the hidden requirement.
* dummy
- Kconfig build dependency fix.
* adi,ad_sigma_delta
- General devm related simplifications for these devices.
* adi,adf4350
- Fix some missing cleanup on error path.
* adi,adis, ADC drivers.
- Clean out unneeded spi_set_drvdata()
* ams-taos,tcs3472
- Fix a potential free of an irq that was never allocated.
* atlas,sensor
- Drop unbalanced runtime pm call and use pm_runtime_resume_and_get()
to reduce boilerplate.
* bosch,bma180
- Fix bandwidth register values used.
* bosch,bmc150
- Fix wrong pointer being dereferenced in remove.
- Stop device trying unregister itself rather than the second device.
- Refactor ACPI second device handing.
- Add support for DUAL250E ACPI HID.
- Move some stuff into the header to enable following patches to not
add additional accessor functions. Drop existing accessors.
- Add support for hinge angle setting with DUAL250E ACPI DSM to ensure
keyboard and touchpad enabled correctly when in laptop mode and disabled
otherwise.
- Add label attr for the multiple sensor locations with DUAL250E ACPI HID.
- Fix scale units for bma222
- Various reordering of devices supported lists to be alphabetical order.
- Drop unnecessary duplicated chip_info_tbl[] entries.
- Document that some devices have two interrupts, even if not currently
used by the driver.
- Move bma254 over to the bma255 driver.
- Move to more consistent scale values, based on assumption that some
datasheets use lower precision in their calculations in comparison
with others.
* hid-sensors
- Use namespaces for exported symbols.
- Update includes using manual inspection of output of the
include-what-you-use tool.
* invensense,icp10100
- Drop unbalanced runtime pm put. Use pm_runtime_resume_and_get() to cleanly
handle potential error.
* invensense,mpu6050
- Drop use of %hhx string formatting.
- runtime pm boilerplate removal and drop an unbalanced call in remove.
* liteon,ltr501
- Fix inaccurate volatile register list.
- Fix wrong mode bit.
- Add a missing leXX_to_cpu() conversion.
- Mark ltr501_chip_info structure as const.
* pulsed-light-lidar:
- Boilerplate removal using runtime_pm_resume_and_get()
* scmi-sensors
- Formatting of SPDX fix.
* silabs,si1133
- Fix a string format warning.
- Drop remaining uses of %hhx string formatting.
* silabs,si1145
- Drop use of %hhx string formatting.
* ti,ads1015
- Drop unbalanced runtime pm call in remove and reduce boilerplate.
* tag 'iio-for-5.14b' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (76 commits)
iio: light: tcs3472: do not free unallocated IRQ
iio: accel: bmc150: Use more consistent and accurate scale values
iio: hid-sensors: Update header includes
iio: pressure: icp10100: Balance runtime pm + use pm_runtime_resume_and_get()
iio: prox: pulsed-light-v2: Use pm_runtime_resume_and_get()
iio: chemical: atlas-sensor: Balance runtime pm + pm_runtime_resume_and_get()
iio: adc: ads1015: Balance runtime pm + pm_runtime_resume_and_get()
iio: imu: mpu6050: Balance runtime pm + use pm_runtime_resume_and_get()
iio: hid-sensors: lighten exported symbols by moving to IIO_HID namespace
iio: prox: isl29501: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
iio: light: vcnl4035: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
iio: light: vcnl4000: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
iio: magn: rm3100: Fix alignment of buffer in iio_push_to_buffers_with_timestamp()
iio: adc: ti-ads8688: Fix alignment of buffer in iio_push_to_buffers_with_timestamp()
iio: adc: mxs-lradc: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
iio: adc: hx711: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
iio: adc: at91-sama5d2: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
counter: interrupt-cnt: Add const qualifier for actions_list array
iio: ltr501: mark ltr501_chip_info as const
iio: ltr501: ltr501_read_ps(): add missing endianness conversion
...
Allocating an IRQ is conditional to the IRQ existence, but freeing it
was not. If no IRQ was allocate, the driver would still try to free
IRQ 0. Add the missing checks.
This fixes the following trace when the driver is removed:
[ 100.667788] Trying to free already-free IRQ 0
[ 100.667793] WARNING: CPU: 0 PID: 2315 at kernel/irq/manage.c:1826 free_irq+0x1fd/0x370
...
[ 100.667914] Call Trace:
[ 100.667920] tcs3472_remove+0x3a/0x90 [tcs3472]
[ 100.667927] i2c_device_remove+0x2b/0xa0
Signed-off-by: frank zago <frank@zago.net>
Link: https://lore.kernel.org/r/20210427022017.19314-2-frank@zago.net
Fixes: 9d2f715d59 ("iio: light: tcs3472: support out-of-threshold events")
Cc: <Stable@vger.kernel.org>
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>
The devm_ handled runtime pm disable calls pm_runtime_put_sync_suspend()
which isn't balancing a matching get call. It isn't a bug as such,
because the runtime pm core doesn't decrement the reference count below
zero, but it is missleading so let's drop it.
Using pm_runtime_resume_and_get() new call makes it easy to handle
failures in resume as it doesn't hold a reference count if it exits
with an error.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/20210516162103.1332291-7-jic23@kernel.org
Add __aligned(8) to ensure the buffer passed to
iio_push_to_buffers_with_timestamp() is suitable for the naturally
aligned timestamp that will be inserted.
Here an explicit structure is not used, because the holes would
necessitate the addition of an explict memset(), to avoid a kernel
data leak, making for a less minimal fix.
Fixes: 1c28799257 ("iio: light: isl29501: Add support for the ISL29501 ToF sensor.")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Mathieu Othacehe <m.othacehe@gmail.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-9-jic23@kernel.org
Add __aligned(8) to ensure the buffer passed to
iio_push_to_buffers_with_timestamp() is suitable for the naturally
aligned timestamp that will be inserted.
Here an explicit structure is not used, because the holes would
necessitate the addition of an explict memset(), to avoid a potential
kernel data leak, making for a less minimal fix.
Fixes: 55707294c4 ("iio: light: Add support for vishay vcnl4035")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Parthiban Nallathambi <pn@denx.de>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-8-jic23@kernel.org
