Sergiu Cuciurean [Wed, 20 May 2020 12:02:01 +0000 (15:02 +0300)]
iio: dac: ad5592r-base: Replace indio_dev->mlock with own device lock
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
This also removes unused iio_dev pointers.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ivan Mikhaylov [Sun, 10 May 2020 18:45:37 +0000 (21:45 +0300)]
iio: proximity: Add driver support for vcnl3020 proximity sensor
Proximity sensor driver based on light/vcnl4000.c code.
For now supports only the single on-demand measurement.
The VCNL3020 is a fully integrated proximity sensor. Fully
integrated means that the infrared emitter is included in the
package. It has 16-bit resolution. It includes a signal
processing IC and features standard I2C communication
interface. It features an interrupt function.
Datasheet: http://www.vishay.com/docs/84150/vcnl3020.pdf Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ivan Mikhaylov [Sun, 10 May 2020 18:45:36 +0000 (21:45 +0300)]
dt-bindings: proximity: provide vcnl3020 device tree binding document
Mostly standard i2c driver with some additional led-current option
for vcnl3020.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Alexandru Ardelean [Mon, 11 May 2020 12:53:22 +0000 (15:53 +0300)]
iio: buffer: remove attrcount_orig var from sysfs creation
The variable no longer does anything.
It should have been removed with commit 2e036804d773e ("iio: buffer: remove
'scan_el_attrs' attribute group from buffer struct").
That was about the last time this was needed.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Matt Ranostay [Mon, 11 May 2020 02:32:14 +0000 (05:32 +0300)]
iio: chemical: add atlas-ezo-sensor initial support
Add driver for Atlas EZO line of sensors with initial support for
CO2 the sensor. This is effectively ASCII strings proxied over I2C
due to these series of sensors being by default UART.
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Krzysztof Kozlowski [Mon, 11 May 2020 08:33:48 +0000 (10:33 +0200)]
iio: adc: exynos: Simplify Exynos7-specific init
The Exynos7-specific code bits in ADC driver do not play with PHY:
the field exynos_adc_data.needs_adc_phy is not set in exynos7_adc_data
instance. Therefore the initialization code does not have to check if
it is true.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Tested-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Bakker [Fri, 8 May 2020 21:14:00 +0000 (14:14 -0700)]
iio: adc: Add scaling support to exynos adc driver
Currently the driver only exposes the raw counts. As we
have the regulator voltage and the maximum value (stored in
the data mask), we can trivially produce a scaling fraction
of voltage / max value.
This assumes that the regulator voltage is in fact the max
voltage, which appears to be the case for all mainline dts
and cross referenced with the public Exynos4412 and S5PV210
datasheets.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: __iio_update_buffers: Update mode before preenable/after postdisable
It is clear that we transition to INDIO_DIRECT_MODE when disabling the
buffer(s) and it is also clear that we transition from INDIO_DIRECT_MODE
when enabling the buffer(s). So leaving the currentmode field
INDIO_DIRECT_MODE until after the preenable() callback and updating it to
INDIO_DIRECT_MODE before the postdisable() callback doesn't add additional
value. On the other hand some drivers will need to perform different
actions depending on which mode the device is going to operate in/was
operating in.
Moving the update of currentmode before preenable() and after postdisable()
enables us to have drivers which perform mode dependent actions in those
callbacks.
Note, was originally not intended as such, but fixes an issue introduced
in the at91-sama5d2 adc driver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Fixes: 065056cb0d0a ("iio: at91-sama5d2_adc: split at91_adc_current_chan_is_touch() helper") Tested-by: Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sergiu Cuciurean [Thu, 14 May 2020 09:06:05 +0000 (12:06 +0300)]
iio: dac: ad5755: Replace indio_dev->mlock with own device lock
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
This also changes some internal functions to pass the pointer to the
state-struct vs a ref to indio_dev just to access the state-struct again.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sergiu Cuciurean [Thu, 14 May 2020 08:39:19 +0000 (11:39 +0300)]
iio: dac: ad5360: Replace indio_dev->mlock with own device lock
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock on the device's state structure.
This also changes some internal functions to pass the pointer to the
state-struct vs a ref to indio_dev just to access the state-struct again.
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Bakker [Thu, 14 May 2020 20:48:59 +0000 (13:48 -0700)]
iio: accel: bma180: Add support for bma023
The bma023 chip is similar enough to the bma180 and bma25x that the
same driver can support all of them. The biggest differences are
the lack of a temperature channel and no low power but still working
mode.
The bma150 is a close relative of the bma023, but it does have a
temperature channel so support is not added for it.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Bakker [Thu, 14 May 2020 20:48:56 +0000 (13:48 -0700)]
iio: accel: Make bma180 conflict with input's bma150
The bma180 IIO driver is being extended for support for the chips
support by input's bma150 driver (bma023, bma150, smb380). Don't
allow both drivers to be enabled simultaneously as they're for the
same hardware.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Bakker [Thu, 14 May 2020 20:48:55 +0000 (13:48 -0700)]
iio: accel: bma180: Prepare for different reset values
Some variants of the bma180 (eg bma023) have different reset
values. In preparation for adding support for them, factor
out the reset value into the chip specific data.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Greg Kroah-Hartman [Fri, 15 May 2020 14:03:28 +0000 (16:03 +0200)]
Merge tag 'iio-for-5.8b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Second set of new device support, cleanups and features for IIO in the 5.8 cycle
Usual mixed back but with a few subsystem wide or device type
wide cleanups.
New device support
* adis16475
- New driver supporting adis16470, adis16475, adis16477, adis16465,
adis16467, adis16500, adis16505 and adis16507.
Includes some rework of the adis library to simplify using it
for this new driver.
* ak8974
- Add support for Alps hscdt008a. ID only. Related patches add support
for scale.
* atlas-sensor
- Add support for RTD-SM OEM temperature sensor.
* cm32181
- Add support for CM3218 including support for SMBUS alert via
ACPI resources.
* ltc2632
- Add support for ltc2634-12/10/8 DACS including handling per
device type numbers of channels.
Major Features
* cm32181
- ACPI bindings including parsing CPM0 and CPM1 custom ACPI tables.
Includes minor tidy ups and fixes.
* vcnl4000
- Add event support
- Add buffered data capture support
- Add control of sampling frequency
Cleanups and minor fixes.
* core
- Trivial rework of iio_device_alloc to use an early return and
improve readability.
- Precursors to addition of multiple buffer support. So far
minor refactoring.
* subsystem wide
- Use get_unaligned_be24 slightly improve readability over open
coding it.
* adis drivers
- Use iio_get_debugfs_dentry access function.
* bh1780, cm32181, cm3232, gp2ap02a00f, opt3001, st_uvis25, vl6180,
dmard06, kxsd9
- Drop use of of_match_ptr to allow ACPI based probing via PRP0001.
Part of clear out of this to avoid cut and paste into new drivers.
* ad5592r, ad5593r
- Fix typos
* ad5933
- Use managed interfaces to automate error handling and remove.
* ak8974
- Fix wrong number of 'real bits' for buffered data.
- Refactor to pull measurement code out as separate function.
bmp280
- Fix lack of clamp on range during data capture.
* at91-sama5d2_adc
- Handle unfinished conversions correctly.
- Allow use of triggers other than it's own.
- Reorganize buffer setup and tear down as part of long running
subsystem wide rework.
* ccs811
- Add DT binding docs and match table.
- Support external reset and wakeup pins.
* hid-sensors
- Reorganize buffer setup and tear down as part of long running
subsystem wide rework.
* ltr501
- Constify some structs.
* vcnl4000
- Fix an endian issue by using explicit byte swapped i2c accessors.
* tag 'iio-for-5.8b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (74 commits)
iio: light: ltr501: Constify structs
staging: iio: ad5933: attach life-cycle of kfifo buffer to parent device and use managed calls throughout
iio: bmp280: fix compensation of humidity
iio: light: cm32181: Fix integartion time typo
iio: light: cm32181: Add support for parsing CPM0 and CPM1 ACPI tables
iio: light: cm32181: Make lux_per_bit and lux_per_bit_base_it runtime settings
iio: light: cm32181: Use units of 1/100000th for calibscale and lux_per_bit
iio: light: cm32181: Change reg_init to use a bitmap of which registers to init
iio: light: cm32181: Handle CM3218 ACPI devices with 2 I2C resources
iio: light: cm32181: Clean up the probe function a bit
iio: light: cm32181: Add support for the CM3218
iio: light: cm32181: Add some extra register defines
iio: light: cm32181: Add support for ACPI enumeration
iio: light: cm32181: Switch to new style i2c-driver probe function
iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger
iio: vcnl4000: Add buffer support for VCNL4010/20.
iio: vcnl4000: Add sampling frequency support for VCNL4010/20.
iio: vcnl4000: Add event support for VCNL4010/20.
iio: vcnl4000: Factorize data reading and writing.
iio: vcnl4000: Fix i2c swapped word reading.
...
Jérôme Pouiller [Fri, 15 May 2020 08:33:25 +0000 (10:33 +0200)]
staging: wfx: remove false positive warning
When a station is removed, the driver check that all the Tx frames were
correctly sent. However, the station can be removed before all the Tx
frames were acknowledged and a false positive warning can be emitted.
The previous commit has added a trace when driver received an
acknowledge for a non-existent station. It appear that these events
are perfectly correlated and there is no leak.
Now, the subject is perfectly understood. Remove the warning. Just keep
a debug trace in case we have any doubt in the future.
In the past, the subject has already been discussed here:
https://lore.kernel.org/driverdev-devel/6287924.ghGFUMk3OD@pc-42/
Jérôme Pouiller [Fri, 15 May 2020 08:33:24 +0000 (10:33 +0200)]
staging: wfx: trace acknowledges not linked to any stations
Some resources are associated to the outgoing of the stations. To avoid
any resource leaks. It is important to understand why an acknowledge is
not associated to any station.
Jérôme Pouiller [Fri, 15 May 2020 08:33:23 +0000 (10:33 +0200)]
staging: wfx: remove false-positive WARN()
The function wfx_tx_flush() wait for there is no more queued frames in
hardware queue. Then, for the sanity, it checks that there is no more
pending frame on any AC queue.
However, there is a race here. It may happens that hardware queues are
empty, but the counters of the AC queues are not yet updated. So, it may
produce false-positive warning.
The easiest way to solve the problem is just to remove the sanity check.
Jérôme Pouiller [Fri, 15 May 2020 08:33:21 +0000 (10:33 +0200)]
staging: wfx: drop unnecessary filter configuration when disabling filter
Currently, when mac80211 want to disable beacon filtering, the driver
reset the filter table and disable the beacon filtering. Only the latter
action is required.
Jérôme Pouiller [Fri, 15 May 2020 08:33:20 +0000 (10:33 +0200)]
staging: wfx: fix PS parameters when multiple vif are in use
When multiple vif are in use (= one access point and one station), and
when the channels are different, it is necessary to enable power save on
station.
The firmware check that steps are done in the correct order:
- AP can't start if PS is not enable on the station
- PS can't set on the station before the association has finished
(= before the call set_bss_params)
Obviously, in add, when one of the interface disappears, it is necessary to
restore the power save status.
wfx_update_pm() is able to set the correct PS configuration. But it has
to be called at the right time:
1. before hif_start(), but after the channel configuration is known
2. after hif_set_bss_params()
3. after hif_reset()
Therefore, the call to wfx_update_pm() from wfx_add_interface() is too
early to address 1.
The call after hif_set_bss_params() already exists.
For the symmetry, the call from wfx_remove_interface() (that handle 3.)
is also relocated.
Jérôme Pouiller [Fri, 15 May 2020 08:33:19 +0000 (10:33 +0200)]
staging: wfx: fix potential dead lock between join and scan
The device disallows to start a scan request between hif_join() and
hif_set_bss_params(). The driver is not protected against that. The
worst case happens when association is aborted and hif_set_bss_params()
never happens.
mac80211 would never ask for scan during the association process. So,
this patch just aborts the association in progress when scan is
requested.
Jérôme Pouiller [Fri, 15 May 2020 08:33:17 +0000 (10:33 +0200)]
staging: wfx: rename wfx_do_unjoin() into wfx_reset()
In fact, wfx_do_unjoin() resets the interface. This mechanism can be
used in more cases than just disassociating from a BSS. So, rename it to
reflect that fact.
Jérôme Pouiller [Fri, 15 May 2020 08:33:16 +0000 (10:33 +0200)]
staging: wfx: fix potential use-after-free
wfx_tx_policy_put() use data from the skb. However, the call to
skb_pull() has just discarded them (even if the memory is in fact not
really discarded).
Jérôme Pouiller [Fri, 15 May 2020 08:33:15 +0000 (10:33 +0200)]
staging: wfx: call wfx_tx_update_sta() before to destroy tx_priv
The function wfx_notify_buffered_tx() need to know if the frame was
associated to a station. This information is available in the Control
Buffer (CB) of the skb. However, when wfx_notify_buffered_tx() is
called, the CB is no more available. Thus, the caller has to take care
of this information.
wfx_notify_buffered_tx() is a specific case. All the other function are
called before the destruction of the CB. So, this patch align the API of
wfx_notify_buffered_tx() with the other functions. Call it before the CB
was destroyed and drop the extra argument 'has_sta'.
It is also the right time to rename it into wfx_tx_update_sta() (which
is closer to the behavior of the function).
Jérôme Pouiller [Fri, 15 May 2020 08:33:14 +0000 (10:33 +0200)]
staging: wfx: split out wfx_tx_fill_rates() from wfx_tx_confirm_cb()
wfx_tx_confirm_cb() is a big function. A big part of its body aims to
fill the rates list. So, create a new function wfx_tx_fill_rates() and
make wfx_tx_confirm_cb() smaller.
Jérôme Pouiller [Fri, 15 May 2020 08:33:13 +0000 (10:33 +0200)]
staging: wfx: fix status of dropped frames
When wfx_flush() is called, the status of pending frames are reported to
mac80211 with random status. mac80211 probably won't interpret this
status in this case, but it is cleaner to return a correctly initialized
status.
Jérôme Pouiller [Fri, 15 May 2020 08:33:10 +0000 (10:33 +0200)]
staging: wfx: fix value of scan timeout
Before to start the scan request, the firmware signals (with a null
frame) to the AP it won't be able to receive data. This frame can be
long to send: up to 512TU. The current calculus of the scan timeout does
not take into account this delay.
Jérôme Pouiller [Fri, 15 May 2020 08:33:08 +0000 (10:33 +0200)]
staging: wfx: apply 80-columns rule to strings
Strings are allowed to exceed 80 columns but, in this case, the format
arguments should be placed on a new line. Apply this rule to the whole
code of the driver.
Jérôme Pouiller [Fri, 15 May 2020 08:33:07 +0000 (10:33 +0200)]
staging: wfx: fix warning when unregister a frozen device
The device does not answer to the command hif_shutdown. Therefore,
hif_shutdown() is a bit special. It bypasses some of work normally made
by wfx_cmd_send(). In particularly, it unlock hif_cmd.lock and
hif_cmd.key_renew_lock.
However, if the driver notice that the device is frozen, wfx_cmd_send()
stops to send data and doesn't lock the mutexes. Then, it produced a
warning when hif_shutdown() tried to unlock these mutexes.
This patch is removing definition of CFLAGS in Makefile of vt6656 and
vt6655, as those are defining macros that are not used. This will remove
undef of one macro from vt6655/device_main.c, as it is only undef and it is
not used anywhere else, so it is safe to remove it.
Macros are removed from vt665x/Makefile and vt6655/device_main.c.
John Oldman [Wed, 13 May 2020 12:54:05 +0000 (13:54 +0100)]
staging: vc04_services: Block comment alignment
Coding style issue reported by checkpatch.pl
This patch clears the checkpatch.pl "Block comments should align
the * on each line" warning.
Also cleared /****** and blank line.
Drop the driver version of the line-coding request and use the protocol
definition directly as was originally intended instead.
This specifically avoids having the two versions of what is supposed to
be the same struct ever getting out of sync.
Note that this has in fact already happened once when the protocol
definition had its implicit padding removed while the driver struct
wasn't updated. The fact that we used the size of the then larger driver
struct when memcpying its content to the stack didn't exactly make
things better. A later addition of a flow-control field incidentally
made the structures match again.
Oscar Carter [Sun, 10 May 2020 09:09:50 +0000 (11:09 +0200)]
staging: vt6656: Remove logically dead code
In the start of the "vnt_rf_set_txpower" function the "power" variable
is set at most to VNT_RF_MAX_POWER (hex = 0x3f, dec = 63). Then, in the
switch statement there are four comparisons with the "power" variable
against AL7230_PWR_IDX_LEN (dec = 64), VT3226_PWR_IDX_LEN (dec = 64),
VT3342_PWR_IDX_LEN (dec = 64). Due to all the commented comparisons are
to check if the "power" variable is "greater than or equal" to 64, this
never happens. So, remove the logically dead code.
Also, remove all the defines that are no longer required.
Addresses-Coverity-ID: 1230228 ("Logically dead code") Fixes: f53d9f12c51a ("staging: vt6656: rf.c additional power.") Signed-off-by: Oscar Carter <oscar.carter@gmx.com> Link: https://lore.kernel.org/r/20200510090950.7633-1-oscar.carter@gmx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Tue, 5 May 2020 21:19:45 +0000 (22:19 +0100)]
staging: vt6656: vnt_get_rtscts_rsvtime_le replace with rts/cts duration.
rsvtime is the time needed in firmware to process the received
frame time in firmware so they can be the same as vnt_get_rts_duration
or vnt_get_cts_duration where appropriate.
The rts_rrv_time are now all the same timing in vnt_rxtx_rts.
So vnt_get_rtscts_rsvtime_le and and vnt_get_frame_time are no longer
required.
Colin Ian King [Thu, 7 May 2020 15:06:52 +0000 (16:06 +0100)]
staging: most: usb: sanity check channel before using it as an index into arrays
Currently channel is being sanity checked after it has been used as
an index into some arrays. Fix this by moving the sanity check of
channel before the arrays are indexed with it.
Addresses-Coverity: ("Negative array index read") Fixes: 59ed0480b950 ("Staging: most: replace pr_*() functions by dev_*()") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200507150652.52238-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jérôme Pouiller [Tue, 12 May 2020 15:04:13 +0000 (17:04 +0200)]
staging: wfx: fix endianness of the field 'channel_number'
The field 'channel_number' from the structs hif_ind_rx and hif_req_start
is a __le32. Sparse complains this field is not always correctly
accessed:
drivers/staging/wfx/data_rx.c:95:55: warning: incorrect type in argument 1 (different base types)
drivers/staging/wfx/data_rx.c:95:55: expected int chan
drivers/staging/wfx/data_rx.c:95:55: got restricted __le16 const [usertype] channel_number
However, the value of channel_number cannot be greater than 14 (this
device only support 2.4Ghz band). So, we only have to access to the
least significant byte. It is finally easier to declare it as an array
of bytes and only access to the first one.
Jérôme Pouiller [Tue, 12 May 2020 15:04:12 +0000 (17:04 +0200)]
staging: wfx: fix endianness of the field 'num_tx_confs'
The field 'num_tx_confs' from the struct hif_cnf_multi_transmit is a
__le32. Sparse complains this field is not always correctly accessed:
drivers/staging/wfx/hif_rx.c:82:9: warning: restricted __le32 degrades to integer
drivers/staging/wfx/hif_rx.c:87:29: warning: restricted __le32 degrades to integer
However, the value of num_tx_confs cannot be greater than 15. So, we
only have to access to the least significant byte. It is finally easier
to declare it as an array of bytes and only access to the first one.
Jérôme Pouiller [Tue, 12 May 2020 15:04:11 +0000 (17:04 +0200)]
staging: wfx: fix endianness of the field 'status'
The field 'status' appears in most of structs returned by the hardware.
This field is encoded as little endian. Sparse complains this field is
not always correctly accessed:
drivers/staging/wfx/data_rx.c:53:16: warning: restricted __le32 degrades to integer
drivers/staging/wfx/data_rx.c:84:16: warning: restricted __le32 degrades to integer
drivers/staging/wfx/data_tx.c:526:24: warning: restricted __le32 degrades to integer
drivers/staging/wfx/data_tx.c:569:23: warning: restricted __le32 degrades to integer
drivers/staging/wfx/hif_rx.c:128:33: warning: restricted __le32 degrades to integer
drivers/staging/wfx/./traces.h:401:1: warning: restricted __le32 degrades to integer
drivers/staging/wfx/./traces.h:401:1: warning: restricted __le32 degrades to integer
In most of cases, this field is only compared with HIF_STATUS values.
Finally, it is more convenient to solve the problem by defining the
HIF_STATUS values directly in little endian.
It is also the right time to make some clean up in the HIF_STATUS names.
Jérôme Pouiller [Tue, 12 May 2020 15:04:10 +0000 (17:04 +0200)]
staging: wfx: fix access to le32 attribute 'len'
Sparse complains about the accesses to the field 'len' from struct hif_msg:
drivers/staging/wfx/bh.c:88:32: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:88:32: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:93:32: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:93:32: warning: cast to restricted __le16
drivers/staging/wfx/bh.c:93:32: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:121:25: warning: incorrect type in argument 2 (different base types)
drivers/staging/wfx/bh.c:121:25: expected unsigned int len
drivers/staging/wfx/bh.c:121:25: got restricted __le16 [usertype] len
drivers/staging/wfx/hif_rx.c:27:22: warning: restricted __le16 degrades to integer
drivers/staging/wfx/hif_rx.c:347:39: warning: incorrect type in argument 7 (different base types)
drivers/staging/wfx/hif_rx.c:347:39: expected unsigned int [usertype] len
drivers/staging/wfx/hif_rx.c:347:39: got restricted __le16 const [usertype] len
drivers/staging/wfx/hif_rx.c:365:39: warning: incorrect type in argument 7 (different base types)
drivers/staging/wfx/hif_rx.c:365:39: expected unsigned int [usertype] len
drivers/staging/wfx/hif_rx.c:365:39: got restricted __le16 const [usertype] len
drivers/staging/wfx/./traces.h:195:1: warning: incorrect type in assignment (different base types)
drivers/staging/wfx/./traces.h:195:1: expected int msg_len
drivers/staging/wfx/./traces.h:195:1: got restricted __le16 const [usertype] len
drivers/staging/wfx/./traces.h:195:1: warning: incorrect type in assignment (different base types)
drivers/staging/wfx/./traces.h:195:1: expected int msg_len
drivers/staging/wfx/./traces.h:195:1: got restricted __le16 const [usertype] len
drivers/staging/wfx/debug.c:319:20: warning: restricted __le16 degrades to integer
drivers/staging/wfx/secure_link.c:85:27: warning: restricted __le16 degrades to integer
drivers/staging/wfx/secure_link.c:85:27: warning: restricted __le16 degrades to integer
Indeed, the attribute len is little-endian. We have to take to the
endianness when we access it.
Jérôme Pouiller [Tue, 12 May 2020 15:04:09 +0000 (17:04 +0200)]
staging: wfx: fix endianness of the struct hif_ind_startup
The struct hif_ind_startup is received from the hardware. So it is
declared as little endian. However, it is also stored in the main driver
structure and used on different places in the driver. Sparse complains
about that:
drivers/staging/wfx/data_tx.c:388:43: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:199:9: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:221:62: warning: restricted __le16 degrades to integer
In order to make Sparse happy and to keep access from the driver easy,
this patch declare hif_ind_startup with native endianness.
On reception of this struct, this patch takes care to do byte-swap and
keep Sparse happy.
Jérôme Pouiller [Tue, 12 May 2020 15:04:08 +0000 (17:04 +0200)]
staging: wfx: declare the field 'packet_id' with native byte order
The field packet_id is not interpreted by the device. It is only used as
identifier for the device answer. So it is not necessary to declare it
little endian. It fixes some warnings raised by Sparse without
complexifying the code.
Jérôme Pouiller [Tue, 12 May 2020 15:04:04 +0000 (17:04 +0200)]
staging: wfx: fix endianness of hif_req_read_mib fields
The structs hif_{req,cnf}_read_mib contain only little endian values.
Thus, it is necessary to fix byte ordering before to use them.
Especially, sparse detected wrong accesses to fields mib_id and length.
Jérôme Pouiller [Tue, 12 May 2020 15:04:03 +0000 (17:04 +0200)]
staging: wfx: fix endianness of fields media_delay and tx_queue_delay
The struct hif_cnf_tx contains only little endian values. Thus, it is
necessary to fix byte ordering before to use them. Especially, sparse
detected wrong access to fields media_delay and tx_queue_delay.
Jérôme Pouiller [Tue, 12 May 2020 15:04:01 +0000 (17:04 +0200)]
staging: wfx: fix wrong bytes order
The field wakeup_period_max from struct hif_mib_beacon_wake_up_period is
a u8. So, assigning it a __le16 produces a nasty bug on big-endian
architectures.
Jérôme Pouiller [Tue, 5 May 2020 12:37:50 +0000 (14:37 +0200)]
staging: wfx: poll IRQ during init
When the chip starts in SDIO mode, the external IRQ (aka Out-Of-Band
IRQ) cannot be used before to configure it. Therefore, the first
exchanges with the chip have to be done without the OOB IRQ.
This patch allow to poll the data until the OOB IRQ is correctly setup.
In order to keep the code simpler, this patch also poll data even if OOB
IRQ is not used.
Jérôme Pouiller [Tue, 5 May 2020 12:37:49 +0000 (14:37 +0200)]
staging: wfx: introduce a way to poll IRQ
It is possible to check if an IRQ is ending by polling the control
register. This function must used with care: if an IRQ fires while the
host reads control register, the IRQ can be lost. However, it could be
useful in some cases.
Jérôme Pouiller [Tue, 5 May 2020 12:37:47 +0000 (14:37 +0200)]
staging: wfx: repair external IRQ for SDIO
When used over SDIO bus, device is able to use an external line to
signal IRQs (also called Out-Of-Band IRQ). The current code have several
problems:
1. The ISR cannot directly acknowledge IRQ since access to the bus is
not atomic. This patch use a threaded IRQ to solve that issue.
2. On certain platforms, it is necessary to keep SDIO interruption
enabled (with register SDIO_CCCR_IENx) (this part has inspired from
the brcmfmac driver).
Jérôme Pouiller [Tue, 5 May 2020 12:37:46 +0000 (14:37 +0200)]
staging: wfx: drop useless check
Currently, the ISR check if bus->core is not NULL. But, it is a useless
check. bus->core is initialiased before to request IRQ and it is not
assigned to NULL when it is released.
Jérôme Pouiller [Tue, 5 May 2020 12:37:44 +0000 (14:37 +0200)]
staging: wfx: reduce timeout for chip initial start up
The device take a few hundreds of milliseconds to start. However, the
current code wait up to 10 second for the chip. We can safely reduce
this value to 1 second. Thanks to that change, it is no more necessary
to use an interruptible timeout.
Jérôme Pouiller [Tue, 5 May 2020 12:37:43 +0000 (14:37 +0200)]
staging: wfx: add support for hardware revision 2 and further
Currently, the driver explicitly exclude support for chip with version
number it does not know. However, it unlikely that any futur hardware
change would break the driver. Therefore, we prefer to invert the test
and only exclude the versions we know the driver does not support.
Rikard Falkeborn [Sat, 2 May 2020 09:52:37 +0000 (11:52 +0200)]
iio: light: ltr501: Constify structs
Constify some data structs that are never changed. In order to do so,
also update a couple of functions that now need to accept pointers to
const struct instead of struct. While at it, update a few more functions
to accept pointers to const struct instead of pointers.
This allows the compiler to put more data in the code segment instead of
the data segment, as seen by the output of the file command:
Before:
text data bss dec hex filename
27080 8144 192 35416 8a58 drivers/iio/light/ltr501.o
After:
text data bss dec hex filename
27688 7536 192 35416 8a58 drivers/iio/light/ltr501.o Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
projects / users / jedix / linux-maple.git / log