Rename field of struct rt_pmkid_list to avoid camel case.

bUsed -> used
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20200929062847.23985-5-straube.linux@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use ETH_ALEN instead of hard coded array size.
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20200929062847.23985-4-straube.linux@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Rename field of struct rt_pmkid_list to avoid camel case.

Bssid -> bssid
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20200929062847.23985-3-straube.linux@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Clean up remaining comparsions to NULL reported by checkpatch.
x == NULL -> !x
x != NULL -> x
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20200929062847.23985-2-straube.linux@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Removep unused macros and definitions from rtw_security.h leftover
from previous cleanup patches.
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20200929062847.23985-1-straube.linux@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Smatch complains that "userdata" can be passed to vchiq_bulk_transfer()
without being initialized.  This leads to a potential information leak
later on.

Fixes: a4367cd2 ("staging: vchiq: convert compat bulk transfer")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200930123036.GC4282@kadamSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The logic of this function was accidentally broken by a checkpatch
inspired cleanup.  I've modified the code to restore the original
behavior and also make checkpatch happy.

Fixes: 98fe05e2 ("staging: rtl8712: Remove unnecesary else after return statement.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200929103548.GA493135@mwandaSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix a comment typo.
Signed-off-by: Ryan Kosta <ryanpkosta@gmail.com>
Link: https://lore.kernel.org/r/20200927172855.9813-1-ryanpkosta@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

Jonathan writes:

3rd set of new device support features and cleanup for IIO in the 5.10 cycle.

A late set given it seems the 5.10 cycle is going to start a bit later
than expected and quite a bit came in.  Includes some late breaking
fixes that can wait for the merge window.

New device support
* ad9467
  - ad9434 support including dt bindings update
  - ad9265 support including dt bindings update

Yaml conversion
* amlogic,meson-saradc

Core rework (heading towards multiple buffer support)
* refactor iio_device_register_eventset
* Null-ify IIO device's event_interface during unregister.

Features
* ad7291
  - convert from platform_data to devicetree including bindings doc.
* core
  - Add titles to a few IIO config symbols to allow simpler out of tree
    building.  It does little harm so why not enable it.

Fixes
* ad7292
  - Fix missing of_node_put()
* at91-sama5d2
  - Fix a crash due to missordering of dma enabling as a result of recent
    IIO wide rework.
* gyro-adc
  - Fix missing of_node_put()
* ltc2983
  - Fix missing of_node_put()
* stm32-adc
  - Fix an issue with runtime autosuspend related to parent autosuspending.

Cleanups
* counter/ti-eqep
  - Tidy up a , instead of ;
* buffer-dmaengine
  - Drop the unmanaged allocator functions as no one is using them.
* at91-sama5d2
  - devm_platform_get_and_ioremap_resouce() replacing boilerplate.
* cros_ec
  - move the hw fifo attributes setup into the cros_ec core.
* gp2ap002
  - comment typo
* microchip-tcb-capture:
  - consitifcation
* ssp
  - Use PLATFORM_DEVID_NONE instead of -1 to convey true meaning.
* stm32-dfsdm
  - devm_platform_get_and_ioremap_resouce() replacing boilerplate.

* tag 'iio-for-5.10c' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (25 commits)
  iio: adc: gyroadc: fix leak of device node iterator
  iio: adc: stm32-adc: fix runtime autosuspend delay when slow polling
  iio: adc: at91-sama5d2_adc: fix DMA conversion crash
  iio: ad7292: Fix of_node refcounting
  iio: ltc2983: Fix of_node refcounting
  counter: use semicolons rather than commas to separate statements
  iio: buffer: Kconfig: add title for IIO_TRIGGERED_BUFFER symbol
  iio: Kconfig: Provide title for IIO_TRIGGERED_EVENT symbol
  iio: dma-buffer: Kconfig: Provide titles for IIO DMA Kconfig symbols
  iio: cros_ec: unify hw fifo attributes into the core file
  dt-bindings: iio: ad9467: add entries for for AD9434 & AD9265 ADCs
  iio: adc: ad9467: add support for AD9265 high-speed ADC
  iio: adc: ad9467: add support for AD9434 high-speed ADC
  iio: adc: ad9467: wrap a axi-adc chip-info into a ad9467_chip_info type
  iio: buffer-dmaengine: remove non managed alloc/free
  iio: adc: stm32-dfsdm: Use devm_platform_get_and_ioremap_resource()
  iio: adc: at91-sama5d2_adc: Use devm_platform_get_and_ioremap_resource()
  iio: ssp: use PLATFORM_DEVID_NONE
  dt-bindings: iio: adc: ad7291: add binding
  iio: adc: ad7291: convert to device tree
  ...

Add missing of_node_put calls when exiting the for_each_child_of_node
loop in rcar_gyroadc_parse_subdevs early.

Also add goto-exception handling for the error paths in that loop.

Fixes: 059c53b3 ("iio: adc: Add Renesas GyroADC driver")
Signed-off-by: Tobias Jordan <kernel@cdqe.de>
Link: https://lore.kernel.org/r/20200926161946.GA10240@agrajag.zerfleddert.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

When the ADC is runtime suspended and starting a conversion, the stm32-adc
driver calls pm_runtime_get_sync() that gets cascaded to the parent
(e.g. runtime resume of stm32-adc-core driver). This also kicks the
autosuspend delay (e.g. 2s) of the parent.
Once the ADC is active, calling pm_runtime_get_sync() again (upon a new
capture) won't kick the autosuspend delay for the parent (stm32-adc-core
driver) as already active.

Currently, this makes the stm32-adc-core driver go in suspend state
every 2s when doing slow polling. As an example, doing a capture, e.g.
cat in_voltageY_raw at a 0.2s rate, the auto suspend delay for the parent
isn't refreshed. Once it expires, the parent immediately falls into
runtime suspended state, in between two captures, as soon as the child
driver falls into runtime suspend state:
- e.g. after 2s, + child calls pm_runtime_put_autosuspend() + 100ms
  autosuspend delay of the child.
- stm32-adc-core switches off regulators, clocks and so on.
- They get switched on back again 100ms later in this example (at 2.2s).

So, use runtime_idle() callback in stm32-adc-core driver to call
pm_runtime_mark_last_busy() for the parent driver (stm32-adc-core),
to avoid this.

Fixes: 9bdbb113 ("iio: adc: stm32-adc: add power management support")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/1593615328-5180-1-git-send-email-fabrice.gasnier@st.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

After the move of the postenable code to preenable, the DMA start was
done before the DMA init, which is not correct.
The DMA is initialized in set_watermark. Because of this, we need to call
the DMA start functions in set_watermark, after the DMA init, instead of
preenable hook, when the DMA is not properly setup yet.

Fixes: f3c034f6 ("iio: at91-sama5d2_adc: adjust iio_triggered_buffer_{predisable,postenable} positions")
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Link: https://lore.kernel.org/r/20200923121748.49384-1-eugen.hristev@microchip.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

When returning or breaking early from a
`for_each_available_child_of_node()` loop, we need to explicitly call
`of_node_put()` on the child node to possibly release the node.

Fixes: 506d2e31 ("iio: adc: Add driver support for AD7292")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200925091045.302-2-nuno.sa@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

When returning or breaking early from a
`for_each_available_child_of_node()` loop, we need to explicitly call
`of_node_put()` on the child node to possibly release the node.

Fixes: f110f318 ("iio: temperature: Add support for LTC2983")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200925091045.302-1-nuno.sa@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Replace commas with semicolons.  What is done is essentially described by
the following Coccinelle semantic patch (http://coccinelle.lip6.fr/):

// <smpl>
@@ expression e1,e2; @@
e1
-,
+;
e2
... when any
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Reviewed-by: David Lechner <david@lechnology.com>
Link: https://lore.kernel.org/r/1601233948-11629-16-git-send-email-Julia.Lawall@inria.frSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

For some embedded systems, a workflow involving external kernel modules
that implement IIO devices is more practical than working with in-tree
sources.

Kconfig symbols without any titles do not show up in menuconfig, and as
such are more difficult to configure granularly, as they need to be
selected by potentially unused/un-needed drivers.

This change adds a title to the IIO_TRIGGERED_BUFFER Kconfig symbol.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200924111758.196367-4-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

For some embedded systems, a workflow involving external kernel modules
that implement IIO devices is more practical than working with in-tree
sources.

Kconfig symbols without any titles do not show up in menuconfig, and as
such are more difficult to configure granularly, as they need to be
selected by potentially unused/un-needed drivers.

Albeit, the IIO_TRIGGERED_EVENT is used by a single mainline driver, this
could allow for some out-of-tree drivers to use this kmod.

This change adds a title to the IIO_TRIGGERED_EVENT Kconfig symbol.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200924111758.196367-3-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

For some embedded systems, a workflow involving external kernel modules
that implement IIO devices is more practical than working with in-tree
sources.

Kconfig symbols without any titles do not show up in menuconfig, and as
such are more difficult to configure granularly, as they need to be
selected by potentially unused/un-needed drivers.

This change adds titles to the IIO DMA Kconfig symbols to address this.

This change also updates DMAengine -> DMAEngine, which is the
correct/nitpick-y name of the framework.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200924111758.196367-2-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The intent here is to minimize the use of iio_buffer_set_attrs(). Since we
are planning to add support for multiple IIO buffers per IIO device, the
issue has to do with:
1. Accessing 'indio_dev->buffer' directly (as is done with
   'iio_buffer_set_attrs(indio_dev->buffer, <attrs>)').
2. The way that the buffer attributes would get handled or expanded when
   there are more buffers per IIO device. Current a sysfs kobj_type expands
   into a 'device' object that expands into an 'iio_dev' object.
   We will need to change this, so that the sysfs attributes for IIO
   buffers expand into IIO buffers at some point.

Right now, the current IIO framework works fine for the
'1 IIO device == 1 IIO buffer' case (that is now).
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Link: https://lore.kernel.org/r/20200923130339.997902-1-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Add entries for the AD9434 & AD9265 high-speed ADCs which are supported by
the 'ad9467' driver.
Better describe the family of ADCs similar to AD9467 in the description.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200924080518.96410-5-alexandru.ardelean@analog.com

The AD9265 is a 16-bit, 125 MSPS analog-to-digital converter (ADC). The
AD9265 is designed to support communications applications where high
performance combined with low cost, small size, and versatility is
desired.

The ADC core features a multistage, differential pipelined architecture
with integrated output error correction logic to provide 16-bit accuracy at
125 MSPS data rates and guarantees no missing codes over the full operating
temperature range.

The ADC features a wide bandwidth differential sample-and-hold analog input
amplifier supporting a variety of user-selectable input ranges. It is
suitable for multiplexed systems that switch full-scale voltage levels in
successive channels and for sampling single-channel inputs at frequencies
well beyond the Nyquist rate. Combined with power and cost savings over
previously available ADCs, the AD9265 is suitable for applications in
communications, instrumentation and medical imaging.

Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD9434.pdf

The driver supports the same register set as the AD9467, so the support for
this chip is added to the 'ad9467' driver.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200924080518.96410-4-alexandru.ardelean@analog.com

The AD9434 is a 12-bit monolithic sampling analog-to-digital converter
(ADC) optimized for high performance, low power, and ease of use. The part
operates at up to a 500 MSPS conversion rate and is optimized for
outstanding dynamic performance in wideband carrier and broadband systems.

All necessary functions, including a sample-and-hold and voltage reference,
are included on the chip to provide a complete signal conversion solution.
The VREF pin can be used to monitor the internal reference or provide an
external voltage reference (external reference mode must be enabled through
the SPI port).

The ADC requires a 1.8 V analog voltage supply and a differential clock
for full performance operation. The digital outputs are LVDS (ANSI-644)
compatible and support twos complement, offset binary format, or Gray code.
A data clock output is available for proper output data timing.

Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD9434.pdf

The driver supports the same register set as the AD9467, so the support for
this chip is added to the 'ad9467' driver.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200924080518.96410-3-alexandru.ardelean@analog.com

There are 2 chip constants that can be added to the chip-info part. The
default output-mode and the VREF mask.

When adding new chips to this driver, these can be easily omitted, because
these also need to be updated in 2 switch statements.

However, if adding them in the chip-info constants, they are updated in a
single place and propagated in both switch statements.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20200924080518.96410-2-alexandru.ardelean@analog.com

This is to encourage the use of devm_iio_dmaengine_buffer_alloc().
Currently the managed version of the DMAEngine buffer alloc is the only
function used from this part of the framework.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200923121810.944075-1-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Make use of devm_platform_get_and_ioremap_resource() provided by
driver core platform instead of duplicated analogue, dev_err() is
removed because it has been done in devm_ioremap_resource().
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Link: https://lore.kernel.org/r/20200918083142.32816-1-bobo.shaobowang@huawei.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Make use of devm_platform_get_and_ioremap_resource() provided by
driver core platform instead of duplicated analogue.
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Link: https://lore.kernel.org/r/20200918082837.32610-1-bobo.shaobowang@huawei.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Use PLATFORM_DEVID_NONE define instead of "-1" value because:
 - it brings some meaning,
 - it might point attention why auto device ID was not used.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200921204939.20341-1-krzk@kernel.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Add device-tree binding for ADI AD7291 ADC.
Signed-off-by: Michael Auchter <michael.auchter@ni.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200922144422.542669-2-michael.auchter@ni.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

There are no in-tree users of the platform data for this driver, so
remove it and convert the driver to use device tree instead.
Signed-off-by: Michael Auchter <michael.auchter@ni.com>
Link: https://lore.kernel.org/r/20200922144422.542669-1-michael.auchter@ni.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Though we know that the iio_device_unregister_eventset() call is followed
by the free-ing of the IIO device object, we should not make this
assumption in the iio_device_unregister_eventset() function. It should
allow for the clean unregistering of the event-set, allowing a re-register
should we decide to implement this at some point later.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200921103156.194748-2-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

With the recent 'iio_dev_opaque' variable name, these two functions are
looking a bit ugly.

This change uses an 'ev_int' variable for the
iio_device_{un}register_eventset functions to make the code a little easier
to read.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200921103156.194748-1-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

This binding is non trivial due to the range of different parts
supported having several subtle quirks. Martin has helped
clarify some of them.

Note, I haven't restricted the amlogic,hhi-sysctrl to only
be present on the relevant parts if nvmem stuff also is, but
it would seem to be rather odd if it were otherwise.

Perhaps we look to make this binding more restrictive at a later date.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200920135436.199003-2-jic23@kernel.org

Change the comment typo: "definately" -> "definitely".
Signed-off-by: Wang Qing <wangqing@vivo.com>
Link: https://lore.kernel.org/r/1600772818-30882-1-git-send-email-wangqing@vivo.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Commit 515ce733 ("staging:r8188eu: Use lib80211 to encrypt (CCMP) tx frames")
was reverted because it caused scheduling while atomic bugs and hard
freezes. Experimentation showed that there were no freezes and no BUG
messages logged when lib80211_get_crypto_ops() was called directly
rather than indirectly through try_then_request_module().

Reapply "staging:r8188eu: Use lib80211 to encrypt (CCMP) tx frames"
with resolved revert conflicts and replace try_then_request_module()
with direct call to lib80211_get_crypto_ops().

Original commit message:
Put data to skb, decrypt with lib80211_crypt_ccmp, and place back to tx buffer.

Cc: Ivan Safonov <insafonov@gmail.com>
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20200927083535.2895-1-straube.linux@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

As found earlier, there is a problem in the create_pagelist() function
that takes a pointer argument that either points into vmalloc space or
into user space, with the pointer value controlled by user space allowing
a malicious user to trick the driver into accessing the kernel instead.

Avoid this problem by adding another function argument and passing
kernel pointers separately from user pointers. This makes it possible
to rely on sparse to point out invalid conversions, and it prevents
user space from faking a kernel pointer.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200925114424.2647144-2-arnd@arndb.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

My earlier patches caused some new sparse warnings, but it turns out
that a number of those are actual bugs, or at least suspicous code.

Adding __user annotations to the data structures that are defined in
uapi headers helps avoid the new warnings, but that causes a different
set of warnings to show up, as some of these structures are used both
inside of the kernel and at the user interface but storing pointers to
different things there.

Duplicating the vchiq_service_params and vchiq_completion_data structures
in turn takes care of most of those, and then it turns out that there
is a 'data' pointer that can be any of a __user address, a dmd_addr_t
and a kernel pointer in vmalloc space at times.

I'm trying to annotate these as best I can without changing behavior,
but there still seems to be a serious bug when user space passes
a valid vmalloc space address instead of a user pointer. Adding
comments in the code there, and leaving the warnings in place that
seem to correspond to actual bugs.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200925114424.2647144-1-arnd@arndb.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The only usage of mchp_tc_ops is to assign its address to the ops field
in the counter_device struct which is a const pointer. Make it const to
allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Link: https://lore.kernel.org/r/20200922201941.41328-1-rikard.falkeborn@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

WIFI_REASON_CODE is duplication of enum ieee80211_reasoncode.
Signed-off-by: Ivan Safonov <insafonov@gmail.com>
Link: https://lore.kernel.org/r/20200919212443.264126-1-insafonov@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In hi3670_phy_probe(), when reading property tx-vboost-lvl fails, its
default value is assigned to priv->eye_diagram_param, rather than to
priv->tx_vboost_lvl. Fix this.

Fixes: 8971a3b8 ("staging: hikey9xx: add USB physical layer for Kirin 3670")
Addresses-Coverity: CID 1497107: Incorrect expression (COPY_PASTE_ERROR)
Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
Link: https://lore.kernel.org/r/20200921212146.34662-1-alex.dewar90@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Clean up comparsions to NULL reported by checkpatch.
if (x == NULL) -> if (!x)
if (x != NULL) -> if (x)
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20200919150823.16923-3-straube.linux@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>