The RTL8822BE, an 802.11ac wireless network card, is now appearing in
new computers. Its driver is being placed in staging to reduce the time
that users of this new card will have access to in-kernel drivers.

This commit adds the code for the new r8822be driver.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The RTL8822BE, an 802.11ac wireless network card, is now appearing in
new computers. Its driver is being placed in staging to reduce the time
that users of this new card will have access to in-kernel drivers.

New Realtek wireless devices have a new method for PHY control and
dynamic management. The RTL8822BE is the first of these devices, thus
there is additional code required.

In the final version, this code will be a separate module; however,
it is combined with the r8822be driver to minimize the interference
with the drivers in the wireless tree.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The RTL8822BE, an 802.11ac wireless network card, is now appearing in
new computers. Its driver is being placed in staging to reduce the time
that users of this new card will have access to in-kernel drivers.

New Realtek devices implement a common sub-driver to control the MAC
layer. The RTL8822BE is the first of these devices, thus its introduction
involves some extra code. In the wireless tree, this will be a separate
module; however, it is compiled into the 8822be driver here.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The RTL8822BE, an 802.11ac wireless network card, is now appearing in
new computers. Its driver is being placed in staging to reduce the time
that users of this new card will have access to in-kernel drivers.

This commit adds the routines needed for BT coexistence with the
new driver.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The RTL8822BE, an 802.11ac wireless network card, is now appearing in
new computers. Its driver is being placed in staging to reduce the time
that users of this new card will have access to in-kernel drivers.

This commit copies the existing routines from .../rtlwifi/btcoexist/
into staging. There are no changes other than removing all EXPORT
statements, and the fixing of checkpatch messages. The latter will
be backported to the wireless tree.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The RTL8822BE, an 802.11ac wireless network card, is now appearing in
new computers. Its driver is being placed in staging to reduce the time
that users of this new card will have access to in-kernel drivers.

This commit copies the code that currently constitutes the rtlwifi and
rtl_pci mini drivers. This material is copied into staging to prevent
any undo interaction between the existing drivers and this new one.
The only changes in this code are the removal of all export statements,
and the fixing of some checkpatch messages. The latter will be backported
into the wireless tree.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Refactor code to be more readable and eliminate the checkpatch
warning
Signed-off-by: NAlex Briskin <br.shurik@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed alignment so that it matched open parenthesis
Signed-off-by: NSrishti Sharma <srishtishar@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make this const as it is only stored in the type field of a device
structure, which is const.
Done using Coccinelle.
Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The mask of sns_key_info1 suggests the upper nybble is being extracted
however the following shift of 8 bits is too large and always results in
0.  Fix this by shifting only by 4 bits to correctly get the upper nybble.

Detected by CoverityScan, CID#142891 ("Operands don't affect result")

Fixes: fa590c22 ("staging: rts5208: add support for rts5208 and rts5288")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

space required before the open parenthesis, open brace should be
on previous line.
Signed-off-by: NXiangyang Zhang <xyz.sun.ok@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

checkpatch.pl gave
ERROR: open brace '{' following function definitions go on the next line.
Signed-off-by: NJamie Huang <jamienstar@163.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We want to concatonate join string one, a '/' character, string two and
then a NUL terminator.  The destination buffer holds ori_gf->gf_pathlen
characters.  The strlen() function returns the number of characters not
counting the NUL terminator.  So we should be adding two extra spaces,
one for the foward slash and one for the NUL.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: Nfrank zago <fzago@cray.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'iio-for-4.14b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next

Jonathan writes:

Second set of IIO new device support, features and cleanup for the 4.14 cycle.

New device support:
* ak8974
  - support the AMI306.
* st_magnetometer
  - add support for the LIS2MDL with bindings.
* rockchip-saradc
  - add binding for rv1108 SoC (no driver change).
* srf08
  - add srf02 (i2c only) and srf10 support.
* stm32-timer
  - support for the STM32H7 to existing driver.

Features:
* tools
  - move over to the tools buildsystem rather than hand rolling.
  - add an install section to the build.
* ak8974
  - use serial number to add device randomness.
  - add AMI306 calibration data output.
* ccs811
  - triggered buffer support.
* srf08
  - add a device tree table as the old style i2c probing is going away,
  - add triggered buffer support
* st32-adc
  - add optional st,min-sample-time-nsecs binding to allow control of
    sampling against analog circuitry.
* stm32-timer
  - add output compare triggers.
* ti-ads1015
  - add threshold event support.
* ti-ads7950
  - Allow use on ACPI platforms including providing a default reference
    voltage as there is no way to obtain this on ACPI currently.

Cleanup and fixes:
* ad7606
  - fix an error return code in probe.
* ads1015
  - fix incorrect data rate setting update when capture in progress,
  - fix wrong scale information for the ADS1115,
  - make conversions work when CONFIG_PM is not set,
  - make sure we don't get a stale result after a runtime resume by
    ensuring we wait long enough,
  - avoid returning a false error form the buffer setup callbacks,
  - add enough wait time to get the correct conversion,
  - remove an unnecessary config register update,
  - add a helper to set conversion mode reducing repeated boilerplate,
  - use devm_iio_triggered_buffer_setup to simplify error and remove
    paths,
  - use iio_device_claim_direct_mode instead of opencoding the same.
* ak8974
  - mark the INT_CLEAR register as precious to prevent debugfs access.
* apds9300
  - constify the i2c_device_id.
* at91-sama5 adc
  - add missing Kconfig dependency.
* bma180 accel
  - constify the i2c_device_id.
* rockchip_saradc
  - explicitly request exclusive reset control as part of the reset rework
    on going throughout the kernel.
* st_accel
  - fix drdy configuration for a load of accelerometers that only have
    the int1 line.  Fix is unimportant as presumably no deviec tree actually
    used the non existent hardware line.
* st_pressure
  - fix drdy configuration for LPS22HB and LPS25H by dropping int2 support
    as they don't have this. Fix is unimportant as presumably no device tree
    actually used the non existent hardware line.
* stm32-dac
  - explicitly request exclusive reset control (part of reset being reworked).
* tsl2583
  - constify the i2c_device_id.
* xadc
  - coding style fixes.

Commit a53e35db ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.

No functional changes.

Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: linux-iio@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Commit a53e35db ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.

No functional changes.

Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The ADS1015 device provides programmable comparator that can issue an
interrupt on the ALERT pin.  This change adds the iio threshold event
support for that feature.

The ADS1015 device only have a single config register which contains an
input multiplexer selection, comparator settings, and etc.  So only a
single event channel can be enabled at a time.  Also enabling both buffer
and event are prohibited for simplicity.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

While the iio buffer for the ti-ads1015 driver is enabled, reading the
raw ADC channel data is restricted.  We usually use the
iio_device_claim_direct_mode()/iio_device_release_direct_mode() pair for
that.

This change consequently reverses the locking order for the driver's
private lock and indio_dev->mlock which acquired by
iio_device_claim_direct_mode() internally. But it's safe because there is
no other dependency between these locks.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Use devm_iio_triggered_buffer_setup to simplify the error path in the
probe() and remove() function.

This changes the remove order, but the end result of remove function
actually does the reverse of probe.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

This adds a helper function to set conversion mode as there are a fair
number of users.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The ti-ads1015 driver has eight iio voltage channels and each iio channel
can hold own scale information.

The ADS1015 device only have a single config register which contains an
input multiplexer selection, PGA and data rate settings.  So the driver
should load the correct settings when the input multiplexer selection is
changed.

However, regardless of which channlel is currently selected, changing any
iio channel's scale information immediately overwrites the current PGA
setting in the config register.

It is harmless because the correct PGA settings are reloaded just before
getting adc result anyway.  But it is unnecessary register update and
should be removed.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

This driver assumes that the device is operating in the continuous
conversion mode which performs the conversion continuously.  So this driver
inserts a wait time before reading the conversion register if the
configuration is changed from a previous request.

Currently, the wait time is only the period required for a single
conversion that is calculated as the reciprocal of the sampling frequency.
However we also need to wait for the the previous conversion to complete.
Otherwise we probably get the conversion result for the previous
configuration when the sampling frequency is lower.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

pm_runtime_get_sync() and pm_runtime_put_autosuspend() return 0 on
success, 1 if the device's runtime PM status was already requested status
or error code on failure.  So a positive return value doesn't indicate an
error condition.

However, any non-zero return values from buffer preenable and postdisable
callbacks are recognized as an error and this driver reuses the return
value from pm_runtime_get_sync() and pm_runtime_put_autosuspend() in
these callbacks.  This change fixes the false error detections.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

This driver assumes that the device is operating in the continuous
conversion mode which performs the conversion continuously.  So this driver
doesn't insert a wait time before reading the conversion register if the
configuration is not changed from a previous request.

This assumption is broken if the device is runtime suspended and entered
a power-down state.  The forthcoming request causes reading a stale result
from the conversion register as the device is runtime resumed just before.

Fix it by adding a flag to detect that condition and insert a necessary
wait time.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The ADS1015 device have two operating modes, continuous conversion mode
and single-shot mode.  This driver assumes that the continuous conversion
mode is selected by runtime resume callback when the ADC result is
requested.

If CONFIG_PM is disabled, the device is always in the default single-shot
mode and no one begins a single conversion.  So the conversion register
doesn't contain valid ADC result.  Fix it by changing the continuous mode
in probe function.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The ti-ads1015 driver supports ADS1015 and ADS1115 devices.  The same
scale information is used for both devices in this driver, however they
have actually different values and the ADS1115's one is not correct.

These devices have the same full-scale input voltage range for each PGA
selection.  So instead of adding another hardcoded scale information,
compute a correct scale on demand from each device's resolution.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The ti-ads1015 driver has eight iio voltage channels and each iio channel
can hold own sampling frequency information.

The ADS1015 device only have a single config register which contains an
input multiplexer selection, PGA and data rate settings.  So the driver
should load the correct settings when the input multiplexer selection is
changed.

However, regardless of which channlel is currently selected, changing any
iio channel's sampling frequency information immediately overwrites the
current data rate setting in the config register.

It breaks the current data rate setting if the different channel's sampling
frequency information is changed because the data rate setting is not
reloaded when the input multiplexer is switched.

This removes the unexpected config register update and correctly load the
data rate setting before getting adc result.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

ACPI enabled platforms do not have a mean of regulators. Instead we use
hard coded voltage value for reference pin. When value is 0 (default) we
fall back to request a regulator.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Use AMI306 calibration data for randomness and debugging.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Reading INT_CLEAR has side effects - disallow reading it via debugfs.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Mix device-specific data into randomness pool.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add support for AMI306 magnetometer - very similar to AMI305.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by <linux/i2c.h> work with
const i2c_device_id. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by <linux/i2c.h> work with
const i2c_device_id. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by <linux/i2c.h> work with
const i2c_device_id. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The config_log_add() function first calls config_log_put() with the
variable 'cld' and then jumps to label 'out_cld', which will call
the same function with the same 'cld' variable. However, at this
point, 'cld' might have been already freed by the first invocation
of config_log_put(). Even if we remove the invocation at that point,
we will still get into trouble. This is because, in the error path,
just below the label 'out_cld', we try to put 'params_cls' and
'sptlrpc_cld', which might also have been freed by config_log_put().

The point is that, config_llog_data::cld_sptlrpc and
config_llog_data::cld_params members are assigned at the beginning
of this function.

To avoid this, do not call config_log_put() inside the else block,
immediately jump to 'out_cld' instead. Moreover, remove assignments
to config_llog_data::cld_sptlrpc and config_llog_data::cld_params at
the beginning, since we already assign them below in the function
with 'cld_lock' held.

As an additional benefit, code size gets smaller.

before:
text    data     bss     dec     hex filename
26188   2256    4208   32652    7f8c drivers/staging/lustre/lustre/mgc/mgc_request.o

after:
text    data     bss     dec     hex filename
26092   2256    4208   32556    7f2c drivers/staging/lustre/lustre/mgc/mgc_request.o
Signed-off-by: NCihangir Akturk <cakturk@gmail.com>
Reviewed-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Declare echo_lock_ops object of type cl_lock_operations as const as it
is only passed to the function cl_lock_slice_add. The corresponding
argument is of type const, so make the object const.
Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
Acked-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Declare fiemap_for_stripe as static to fix sparse warnings:

> warning: symbol 'fiemap_for_stripe' was not declared. Should it be
> static?
Signed-off-by: NDavid Wittman <dwittman@gmail.com>
Acked-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix minor typos in comments.
Signed-off-by: NNeilBrown <neilb@suse.com>
Acked-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

While in SNK_READY state, the explicit_contract seems to be
set to true irrespective of whether an explicit contract
was established for the current connection. TCPM also seems
to report the pwr_opmode as TYPEC_PWR_MODE_PD always once
the port gets into SNK_READY state. This isn't completely
true as port gets into the SNK_READY state for non-pd
type-c ports as well.

This patch sets the explicit_contract flag only when
the PS_READY message is received and the vbus has been
detected by the port controller.
Signed-off-by: NBadhri Jagan Sridharan <Badhri@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>