Staging: rtl8723bs: os_de: if-else coding style issue

Coding style issues:
This patch clears the checkpatch.pl "braces {} are not necessary for
single statement blocks" and "else_should_follow_close_brace"
warnings.

Signed-off-by: John Oldman <john.oldman@polehill.co.uk>
Link: https://lore.kernel.org/r/20200515165646.12867-1-john.oldman@polehill.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'iio-for-5.8b' of git://git./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.
  ...

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/

Fixes: 4bbc6a3e7ad0 ("staging: wfx: make warning about pending frame less scary")
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-20-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Add a trace for that purpose.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-19-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-18-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix error reporting in wfx_start_ap()

If AP did not start, the error was not reported to mac80211.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-17-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-16-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-15-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-14-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: merge wfx_stop_ap() with wfx_reset()

wfx_stop_ap() and wfx_reset() do the same thing. Merge them.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-13-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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).

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-11-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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).

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-10-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-9-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-8-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix indentation

Fix indention of wfx_skb_dtor().

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-7-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: check pointers returned by allocations

Until now, the driver did not always check if the allocations success.

The issue was discussed here:
   https://lore.kernel.org/netdev/2026476.QLiXXEGFCf@pc-42/

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-3-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: vt6656: vt6655: removing unused macros definition Makefiles

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.

Signed-off-by: Matej Dujava <mdujava@kocurkovo.cz>
Link: https://lore.kernel.org/r/1589397351-24655-2-git-send-email-mdujava@kocurkovo.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: fbtft: fb_st7789v: Initialize the Display

Set Gamma Values and Register Values for the HSD20_IPS Panel

Signed-off-by: Oliver Graute <oliver.graute@kococonnector.com>
Link: https://lore.kernel.org/r/1589380299-21871-1-git-send-email-oliver.graute@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: qlge: Remove unnecessary spaces in qlge_main.c

Fix checkpatch.pl check:

  CHECK: No space is necessary after a cast

Signed-off-by: Xiangyang Zhang <xyz.sun.ok@gmail.com>
Link: https://lore.kernel.org/r/20200513130042.13185-1-xyz.sun.ok@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: John Oldman <john.oldman@polehill.co.uk>
Link: https://lore.kernel.org/r/20200513125405.28242-1-john.oldman@polehill.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: greybus: uart: replace driver line-coding struct

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.

Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20200514070548.4423-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Documentation: ABI: correct sysfs attribute description of MOST driver

This patch fixes the ABI description file sysfs-bus-most.

Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
Link: https://lore.kernel.org/r/1589534465-7423-8-git-send-email-christian.gromm@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: most: usb: use macro ATTRIBUTE_GROUPS

This patch makes use of the macro ATTRIBUTE_GROUPS to create the groups
instead of defining them manually.

Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1589534465-7423-7-git-send-email-christian.gromm@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: most: fix typo in Kconfig

This patch corrects the typo in the Kconfig file where it says
tranceiver instead of transceiver.

Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/1589534465-7423-6-git-send-email-christian.gromm@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: most: usb: use dev_dbg function

This patch replaces the functions dev_notice with dev_dbg to silence
the driver during normal operation.

Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1589534465-7423-5-git-send-email-christian.gromm@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: most: usb: check number of reported endpoints

This patch checks the number of endpoints reported by the USB
interface descriptor and throws an error if the number exceeds
MAX_NUM_ENDPOINTS.

Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1589534465-7423-4-git-send-email-christian.gromm@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: most: usb: remove reference to USB error codes

This patch removes the reference to the driver API file for USB error
codes.

Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1589534465-7423-3-git-send-email-christian.gromm@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: most: usb: use dev_*() functions to print messages

This patch removes the pr_*() functions and uses dev_*() instead.

Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1589534465-7423-2-git-send-email-christian.gromm@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

staging: bcm2835-camera: insert emty line after declaration

Missing empty line after variable declaration

Signed-off-by: Houssem KADI <kadi.houssem.eddine@gmail.com>
Link: https://lore.kernel.org/r/20200509180849.GA30426@houssem-MS-7808
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: vt6656: remove difs / sifs adjustments.

Now mac89211 is doing frame timing in rxtx these vendor adjustments need
to be removed.

Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/034e445c-b245-52c4-c855-431b9783bcff@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/4c0fe356-7e08-bf66-58b7-5ab683ba9536@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: vt6656: Split RTS and CTS Duration functions

split vnt_get_rtscts_duration_le into vnt_get_rts_duration and
vnt_get_cts_duration.

The duration's are all the same in vnt_rxtx_rts_g_head.

Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/d2983161-7935-48ce-c0ca-a26ebafa3997@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: vt6656: vnt_get_rtscts_duration_le use ieee80211_ctstoself_duration

use the mac80211 ieee80211_ctstoself_duration for CTS to self frames.

Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/f12b3d71-eb61-340b-e473-83509d9bc38a@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: vt6656: vnt_rxtx_rsvtime_le16 to use ieee80211_generic_frame_duration.

ieee80211_generic_frame_duration is the mac80211 equivalent to
vnt_get_rsvtime use this to get our frame time.

There is a change where there is rrv_time_a and rrv_time_b
the frame duration is always the same so both are equal.

Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/acff7fcc-0add-652b-7d07-22001b641257@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: vt6656: vnt_get_rtscts_duration_le use ieee80211_rts_duration

use the mac80211 ieee80211_rts_duration for RTS frames.

Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/377a4cc3-cfe3-91aa-cf71-1063f311426a@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

staging: most: usb: add PM functions

This patch adds the implementation of the PM functions resume and suspend.

Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
Link: https://lore.kernel.org/r/1588680892-9413-1-git-send-email-christian.gromm@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: update TODO

Update the TODO list associated to the wfx driver with the last
progresses.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-18-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-17-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-16-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-15-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-14-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-13-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix access to le32 attribute 'indication_type'

The attribute indication_type is little-endian. We have to take to the
endianness when we access it.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-11-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix access to le32 attribute 'event_id'

The attribute event_id is little-endian. We have to take to the
endianness when we access it.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-10-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix access to le32 attribute 'ps_mode_error'

The attribute ps_mode_error is little-endian. We have to take to the
endianness when we access it.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-9-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-8-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-7-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix output of rx_stats on big endian hosts

The struct hif_rx_stats contains only little endian values. Thus, it is
necessary to fix byte ordering before to use them.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-6-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix cast operator

Sparse detects that le16_to_cpup() expects a __le16 * as argument.

Change the cast operator to be compliant with sparse.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: take advantage of le32_to_cpup()

le32_to_cpu(*x) can be advantageously converted in le32_to_cpup(x).

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-3-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix use of cpu_to_le32 instead of le32_to_cpu

Sparse detected that le32_to_cpu should be used instead of cpu_to_le32.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: use kernel types instead of c99 ones

The kernel coding style promotes the use of kernel types (u8, u16, u32,
etc...) instead of the C99 ones.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-16-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: remove spaces after cast operator

The kernel coding style expects no space after cast operator. This patch
make the wfx driver compliant with this rule.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-15-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix alignements of function prototypes

Some function prototypes were not correctly aligned and/or exceed 80
columns.

In some other cases, the prototypes were written on more lines than
necessary.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-14-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: remove useless header inclusions

In order to keep the compilation times reasonable, we try to only
include the necessary headers (especially header included from other
headers).

This patch clean up unnecessary headers inclusions.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-13-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: prefer ARRAY_SIZE instead of a magic number

When possible, we prefer to use the macro ARRAY_SIZE rather than hard
coding the number of elements.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix missing 'static' keyword

Sparse tool noticed that wfx_enable_beacon() is never used outside of
sta.c. Therefore, it can be declared static.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-11-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix missing 'static' statement

The function get_firmware() is only used from fwio.c. It can be declared
static.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-10-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-9-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-8-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: use threaded IRQ with SPI

Currently, the SPI implementation use a workqueue to acknowledge IRQ
while the SDIO-OOB implementation use a threaded IRQ.

The threaded also offers the advantage to allow level triggered IRQs.

Uniformize the code and use threaded IRQ in both case. Therefore, prefer
level triggered IRQs if the user does not specify it in the DT.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-7-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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).

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-6-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: wfx: fix double free

In case of error in wfx_probe(), wdev->hw is freed. Since an error
occurred, wfx_free_common() is called, then wdev->hw is freed again.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Fixes: 4033714d6cbe ("staging: wfx: fix init/remove vs IRQ race")
Link: https://lore.kernel.org/r/20200505123757.39506-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-3-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

staging: iio: ad5933: attach life-cycle of kfifo buffer to parent device and use managed calls throughout

This change makes the use of devm_iio_kfifo_allocate() to attach the
life-cycle of the kfifo buffer to the parent (client->dev) object.

This removes the need to explicitly free 'indio_dev->buffer' via
iio_kfifo_free(), which is the main intent.

Having done this, it is straight forward to move to devm_ calls throughout
and drop the remove function.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: bmp280: fix compensation of humidity

Limit the output of humidity compensation to the range between 0 and 100
percent.

Depending on the calibration parameters of the individual sensor it
happens, that a humidity above 100 percent or below 0 percent is
calculated, which don't make sense in terms of relative humidity.

Add a clamp to the compensation formula as described in the datasheet of
the sensor in chapter 4.2.3.

Although this clamp is documented, it was never in the driver of the
kernel.

It depends on the circumstances (calibration parameters, temperature,
humidity) if one can see a value above 100 percent without the clamp.
The writer of this patch was working with this type of sensor without
noting this error. So it seems to be a rare event when this bug occures.

Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: cm32181: Fix integartion time typo

Fix integartion time typo and while at it improve the comment with
the typo a bit in general.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: cm32181: Add support for parsing CPM0 and CPM1 ACPI tables

On ACPI based systems the CPLM3218 ACPI device node describing the
CM3218[1] sensor typically will have some extra tables with register
init values for initializing the sensor and calibration info.

This is based on a newer version of cm32181.c, with a copyright of:

 * Copyright (C) 2014 Capella Microsystems Inc.
 * Author: Kevin Tsai <ktsai@capellamicro.com>
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2, as published
 * by the Free Software Foundation.

Which is floating around on the net in various places, but the changes
from this newer version never made it upstream.

This was tested on the following models: Acer Switch 10 SW5-012 (CM32181)
Asus T100TA (CM3218), Asus T100CHI (CM3218) and HP X2 10-n000nd (CM32181).

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Merge 5.7-rc5 into staging-next

We need the staging fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 5.7-rc5

Merge tag 'x86-urgent-2020-05-10' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Thomas Gleixner:
 "A set of fixes for x86:

   - Ensure that direct mapping alias is always flushed when changing
     page attributes. The optimization for small ranges failed to do so
     when the virtual address was in the vmalloc or module space.

   - Unbreak the trace event registration for syscalls without arguments
     caused by the refactoring of the SYSCALL_DEFINE0() macro.

   - Move the printk in the TSC deadline timer code to a place where it
     is guaranteed to only be called once during boot and cannot be
     rearmed by clearing warn_once after boot. If it's invoked post boot
     then lockdep rightfully complains about a potential deadlock as the
     calling context is different.

   - A series of fixes for objtool and the ORC unwinder addressing
     variety of small issues:

       - Stack offset tracking for indirect CFAs in objtool ignored
         subsequent pushs and pops

       - Repair the unwind hints in the register clearing entry ASM code

       - Make the unwinding in the low level exit to usermode code stop
         after switching to the trampoline stack. The unwind hint is no
         longer valid and the ORC unwinder emits a warning as it can't
         find the registers anymore.

       - Fix unwind hints in switch_to_asm() and rewind_stack_do_exit()
         which caused objtool to generate bogus ORC data.

       - Prevent unwinder warnings when dumping the stack of a
         non-current task as there is no way to be sure about the
         validity because the dumped stack can be a moving target.

       - Make the ORC unwinder behave the same way as the frame pointer
         unwinder when dumping an inactive tasks stack and do not skip
         the first frame.

       - Prevent ORC unwinding before ORC data has been initialized

       - Immediately terminate unwinding when a unknown ORC entry type
         is found.

       - Prevent premature stop of the unwinder caused by IRET frames.

       - Fix another infinite loop in objtool caused by a negative
         offset which was not catched.

       - Address a few build warnings in the ORC unwinder and add
         missing static/ro_after_init annotations"

* tag 'x86-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/unwind/orc: Move ORC sorting variables under !CONFIG_MODULES
  x86/apic: Move TSC deadline timer debug printk
  ftrace/x86: Fix trace event registration for syscalls without arguments
  x86/mm/cpa: Flush direct map alias during cpa
  objtool: Fix infinite loop in for_offset_range()
  x86/unwind/orc: Fix premature unwind stoppage due to IRET frames
  x86/unwind/orc: Fix error path for bad ORC entry type
  x86/unwind/orc: Prevent unwinding before ORC initialization
  x86/unwind/orc: Don't skip the first frame for inactive tasks
  x86/unwind: Prevent false warnings for non-current tasks
  x86/unwind/orc: Convert global variables to static
  x86/entry/64: Fix unwind hints in rewind_stack_do_exit()
  x86/entry/64: Fix unwind hints in __switch_to_asm()
  x86/entry/64: Fix unwind hints in kernel exit path
  x86/entry/64: Fix unwind hints in register clearing code
  objtool: Fix stack offset tracking for indirect CFAs

Merge tag 'objtool-urgent-2020-05-10' of git://git./linux/kernel/git/tip/tip

Pull objtool fix from Thomas Gleixner:
 "A single fix for objtool to prevent an infinite loop in the
  jump table search which can be triggered when building the
  kernel with '-ffunction-sections'"

* tag 'objtool-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  objtool: Fix infinite loop in find_jump_table()

Merge tag 'locking-urgent-2020-05-10' of git://git./linux/kernel/git/tip/tip

Pull locking fix from Thomas Gleixner:
 "A single fix for the fallout of the recent futex uacess rework.

  With those changes GCC9 fails to analyze arch_futex_atomic_op_inuser()
  correctly and emits a 'maybe unitialized' warning. While we usually
  ignore compiler stupidity the conditional store is pointless anyway
  because the correct case has to store. For the fault case the extra
  store does no harm"

* tag 'locking-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  ARM: futex: Address build warning

Merge tag 'iommu-fixes-v5.7-rc4' of git://git./linux/kernel/git/joro/iommu

Pull iommu fixes from Joerg Roedel:

 - Race condition fixes for the AMD IOMMU driver.

   These are five patches fixing two race conditions around
   increase_address_space(). The first race condition was around the
   non-atomic update of the domain page-table root pointer and the
   variable containing the page-table depth (called mode). This is fixed
   now be merging page-table root and mode into one 64-bit field which
   is read/written atomically.

   The second race condition was around updating the page-table root
   pointer and making it public before the hardware caches were flushed.
   This could cause addresses to be mapped and returned to drivers which
   are not reachable by IOMMU hardware yet, causing IO page-faults. This
   is fixed too by adding the necessary flushes before a new page-table
   root is published.

   Related to the race condition fixes these patches also add a missing
   domain_flush_complete() barrier to update_domain() and a fix to bail
   out of the loop which tries to increase the address space when the
   call to increase_address_space() fails.

   Qian was able to trigger the race conditions under high load and
   memory pressure within a few days of testing. He confirmed that he
   has seen no issues anymore with the fixes included here.

 - Fix for a list-handling bug in the VirtIO IOMMU driver.

* tag 'iommu-fixes-v5.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/virtio: Reverse arguments to list_add
  iommu/amd: Do not flush Device Table in iommu_map_page()
  iommu/amd: Update Device Table in increase_address_space()
  iommu/amd: Call domain_flush_complete() in update_domain()
  iommu/amd: Do not loop forever when trying to increase address space
  iommu/amd: Fix race in increase_address_space()/fetch_pte()

Merge tag 'block-5.7-2020-05-09' of git://git.kernel.dk/linux-block

Pull block fixes from Jens Axboe:

 - a small series fixing a use-after-free of bdi name (Christoph,Yufen)

 - NVMe fix for a regression with the smaller CQ update (Alexey)

 - NVMe fix for a hang at namespace scanning error recovery (Sagi)

 - fix race with blk-iocost iocg->abs_vdebt updates (Tejun)

* tag 'block-5.7-2020-05-09' of git://git.kernel.dk/linux-block:
  nvme: fix possible hang when ns scanning fails during error recovery
  nvme-pci: fix "slimmer CQ head update"
  bdi: add a ->dev_name field to struct backing_dev_info
  bdi: use bdi_dev_name() to get device name
  bdi: move bdi_dev_name out of line
  vboxsf: don't use the source name in the bdi name
  iocost: protect iocg->abs_vdebt with iocg->waitq.lock

iio: light: cm32181: Make lux_per_bit and lux_per_bit_base_it runtime settings

Make lux_per_bit and lux_per_bit_base_it settings stored in struct
cm32181_chip instead of a hardcoded (defined) values.

This is a preparation patch for reading some ACPI tables which specify
a device specific lux_per_bit value.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: cm32181: Use units of 1/100000th for calibscale and lux_per_bit

Use units of 1/100000th for calibscale and lux_per_bit. The similar
cm3232 driver already uses 1/100000th as unit for calibscale.

This allows for higher-accuracy and makes it easier to add support
for getting device-specific calibscale and lux_per_bit values from
a device's ACPI tables, as the values in the ACPI tables also use
1/100000th units.

This units change means that our intermediate values in cm32181_get_lux()
may get quite big, change the type of the lux variable to a u64 to
deal with this.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: cm32181: Change reg_init to use a bitmap of which registers to init

This is a preparation patch for reading some ACPI tables which give
init values for multiple registers.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: cm32181: Handle CM3218 ACPI devices with 2 I2C resources

Some ACPI systems list 2 I2C resources for the CM3218 sensor. On these
systems the first I2cSerialBus ACPI-resource points to the SMBus Alert
Response Address (ARA, 0x0c) and the second I2cSerialBus ACPI-resource
points to the actual CM3218 sensor address:

 Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
 {
     Name (SBUF, ResourceTemplate ()
     {
         I2cSerialBusV2 (0x000C, ControllerInitiated, 0x00061A80,
             AddressingMode7Bit, "\\_SB.I2C3",
             0x00, ResourceConsumer, , Exclusive,
             )
         I2cSerialBusV2 (0x0048, ControllerInitiated, 0x00061A80,
             AddressingMode7Bit, "\\_SB.I2C3",
             0x00, ResourceConsumer, , Exclusive,
             )
         Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, )
         {
             0x00000033,
         }
     })
     Return (SBUF) /* \_SB_.I2C3.ALSD._CRS.SBUF */
 }

Detect this and take the following step to deal with it:

1. When a SMBus Alert capable sensor has an Alert asserted, it will
   not respond on its actual I2C address. Read a byte from the ARA
   to clear any pending Alerts.

2. Create a "dummy" client for the actual I2C address and
   use that client to communicate with the sensor.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: cm32181: Clean up the probe function a bit

3 small cleanups to cm32181_probe():

1. Do not log an error when we fail to allocate memory (as a general
rule drivers do not log errors for this as the kernel will already
have complained loudly that it could not alloc the mem).

2. Remove the i2c_set_clientdata() call, we never use i2c_get_clientdata()
or dev_get_drvdata() anywhere.

3. Add a dev helper variable and use it in various places instead of
&client->dev.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: cm32181: Add support for the CM3218

Add support for the CM3218 which is an older version of the
CM32181.

This is based on a newer version of cm32181.c, with a copyright of:

 * Copyright (C) 2014 Capella Microsystems Inc.
 * Author: Kevin Tsai <ktsai@capellamicro.com>
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2, as published
 * by the Free Software Foundation.

Which is floating around on the net in various places, but the changes
from this newer version never made it upstream.

This was tested on an Asus T100TA and an Asus T100CHI, which both come
with the CM3218 variant of the light sensor.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: cm32181: Add some extra register defines

These come from a newer version of cm32181.c, which is floating around
the net, with a copyright of:

 * Copyright (C) 2014 Capella Microsystems Inc.
 * Author: Kevin Tsai <ktsai@capellamicro.com>
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2, as published
 * by the Free Software Foundation.

Note that this removes the bogus CM32181_CMD_ALS_ENABLE define, there
is no enable bit, only a disable bit and enabled is the absence of
being disabled.

This is a preparation patch for adding support for the older
CM3218 model of the light sensor.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: cm32181: Add support for ACPI enumeration

Add support for ACPI enumeration, this has been tested on a HP
HP Pavilion x2 Detachable 10 (Bay Trail model).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: cm32181: Switch to new style i2c-driver probe function

Switch to the new style i2c-driver probe_new probe function and drop the
unnecessary i2c_device_id table (we do not have any old style board files
using this).

This is a preparation patch for adding ACPI binding support.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger

The main intent here is to get rid of the iio_buffer_set_attrs() helper, or
at least rework it's usage a bit.
The problem with that helper is that it needs a pointer to the buffer,
which makes supporting multiple buffers per IIO device a bit more
cumbersome.

The hid_sensor_setup_trigger() is pretty much used in the same way:
- iio_triggered_buffer_setup() gets called before
- then hid_sensor_setup_trigger() and hid_sensor_setup_batch_mode() gets
  called which may attach some fifo attributes

This change merges the 2 together under the hid_sensor_setup_trigger()
function. Only the &iio_pollfunc_store_time is passed to all devices, so
it's not even required to pass it explicitly outside of the common
hid_sensor_setup_trigger() function.

Moving the devm_iio_triggered_buffer_setup/cleanup() calls into the common
place code can help the rework of the buffer code, since it is in one
place.

One detail of the change is that there are 2 drivers that use
devm_iio_triggered_buffer_setup(). That function gets implicitly
replaced with iio_triggered_buffer_setup()/cleanup(), but since all drivers
call both hid_sensor_setup_trigger9) & hid_sensor_remove_trigger() trigger,
the iio_triggered_buffer_cleanup() piggy backs on the
hid_sensor_remove_trigger() call, which should cover the cleanup.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

gcc-10: mark more functions __init to avoid section mismatch warnings

It seems that for whatever reason, gcc-10 ends up not inlining a couple
of functions that used to be inlined before.  Even if they only have one
single callsite - it looks like gcc may have decided that the code was
unlikely, and not worth inlining.

The code generation difference is harmless, but caused a few new section
mismatch errors, since the (now no longer inlined) function wasn't in
the __init section, but called other init functions:

   Section mismatch in reference from the function kexec_free_initrd() to the function .init.text:free_initrd_mem()
   Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memremap()
   Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memunmap()

So add the appropriate __init annotation to make modpost not complain.
In both cases there were trivially just a single callsite from another
__init function.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'riscv-for-linus-5.7-rc5' of git://git./linux/kernel/git/riscv/linux

Pull RISC-V fixes from Palmer Dabbelt:
 "A smattering of fixes and cleanups:

   - Dead code removal.

   - Exporting riscv_cpuid_to_hartid_mask for modules.

   - Per-CPU tracking of ISA features.

   - Setting max_pfn correctly when probing memory.

   - Adding a note to the VDSO so glibc can check the kernel's version
     without a uname().

   - A fix to force the bootloader to initialize the boot spin tables,
     which still get used as a fallback when SBI-0.1 is enabled"

* tag 'riscv-for-linus-5.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  RISC-V: Remove unused code from STRICT_KERNEL_RWX
  riscv: force __cpu_up_ variables to put in data section
  riscv: add Linux note to vdso
  riscv: set max_pfn to the PFN of the last page
  RISC-V: Remove N-extension related defines
  RISC-V: Add bitmap reprensenting ISA features common across CPUs
  RISC-V: Export riscv_cpuid_to_hartid_mask() API

gcc-10: avoid shadowing standard library 'free()' in crypto

gcc-10 has started warning about conflicting types for a few new
built-in functions, particularly 'free()'.

This results in warnings like:

   crypto/xts.c:325:13: warning: conflicting types for built-in function ‘free’; expected ‘void(void *)’ [-Wbuiltin-declaration-mismatch]

because the crypto layer had its local freeing functions called
'free()'.

Gcc-10 is in the wrong here, since that function is marked 'static', and
thus there is no chance of confusion with any standard library function
namespace.

But the simplest thing to do is to just use a different name here, and
avoid this gcc mis-feature.

[ Side note: gcc knowing about 'free()' is in itself not the
  mis-feature: the semantics of 'free()' are special enough that a
  compiler can validly do special things when seeing it.

  So the mis-feature here is that gcc thinks that 'free()' is some
  restricted name, and you can't shadow it as a local static function.

  Making the special 'free()' semantics be a function attribute rather
  than tied to the name would be the much better model ]

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

gcc-10: disable 'restrict' warning for now

gcc-10 now warns about passing aliasing pointers to functions that take
restricted pointers.

That's actually a great warning, and if we ever start using 'restrict'
in the kernel, it might be quite useful.  But right now we don't, and it
turns out that the only thing this warns about is an idiom where we have
declared a few functions to be "printf-like" (which seems to make gcc
pick up the restricted pointer thing), and then we print to the same
buffer that we also use as an input.

And people do that as an odd concatenation pattern, with code like this:

    #define sysfs_show_gen_prop(buffer, fmt, ...) \
        snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__)

where we have 'buffer' as both the destination of the final result, and
as the initial argument.

Yes, it's a bit questionable.  And outside of the kernel, people do have
standard declarations like

    int snprintf( char *restrict buffer, size_t bufsz,
                  const char *restrict format, ... );

where that output buffer is marked as a restrict pointer that cannot
alias with any other arguments.

But in the context of the kernel, that 'use snprintf() to concatenate to
the end result' does work, and the pattern shows up in multiple places.
And we have not marked our own version of snprintf() as taking restrict
pointers, so the warning is incorrect for now, and gcc picks it up on
its own.

If we do start using 'restrict' in the kernel (and it might be a good
idea if people find places where it matters), we'll need to figure out
how to avoid this issue for snprintf and friends.  But in the meantime,
this warning is not useful.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>