Move the read of max-speed from device-tree out of the qca_is_wcn399x
if block so oper_speed can be set for QCA9377 devices as well.
Suggested-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Add a compatible so QCA9377 devices can be defined in device-tree.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
QCA9377 is a QCA ROME device frequently found in Android TV boxes.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This change adds support for LE scatternet connections to Intel's JfP
and ThP controllers.
Signed-off-by: Alain Michaud <alainm@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This change allows scatternet connections to be created if the
controller reports support and the HCI_QUIRK_VALID_LE_STATES indicates
that the reported LE states can be trusted.
Signed-off-by: Alain Michaud <alainm@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This change adds the relevant driver and quirk to allow drivers to
report the le_states as being trustworthy.
This has historically been disabled as controllers did not reliably
support this. In particular, this will be used to relax this condition
for controllers that have been well tested and reliable.
/* Most controller will fail if we try to create new connections
* while we have an existing one in slave role.
*/
if (hdev->conn_hash.le_num_slave > 0)
return NULL;
Signed-off-by: Alain Michaud <alainm@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tegra124 and Tegra210 support addressing more than 32 bits of physical
memory. However, since their host1x does not support the wide GATHER
opcode, they should use the SMMU if at all possible to ensure that all
the system memory can be used for command buffers, irrespective of
whether or not the host1x firewall is enabled.
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When testing whether or not to enable the use of the SMMU, consult the
supported DMA mask rather than the actually configured DMA mask, since
the latter might already have been restricted.
Fixes: 2d9384ff91 ("drm/tegra: Relax IOMMU usage criteria on old Tegra")
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Currently, for EINT_TYPE GPIOs, the CON and FLTCON registers
are saved and restored over a suspend/resume cycle. However, the
EINT_MASK registers are not.
On S5PV210 at the very least, these registers are not retained over
suspend, leading to the interrupts remaining masked upon resume and
therefore no interrupts being triggered for the device. There should
be no effect on any SoCs that do retain these registers as theoretically
we would just be re-writing what was already there.
Fixes: 7ccbc60cd9 ("pinctrl: exynos: Handle suspend/resume of GPIO EINT registers")
Cc: <stable@vger.kernel.org>
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
This extends espintcp to support IPv6, building on the existing code
and the new UDPv6 encapsulation support. Most of the code is either
reused directly (stream parser, ULP) or very similar to the IPv4
variant (net/ipv6/esp6.c changes).
The separation of config options for IPv4 and IPv6 espintcp requires a
bit of Kconfig gymnastics to enable the core code.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
This patch adds support for encapsulation of ESP over UDPv6. The code
is very similar to the IPv4 encapsulation implementation, and allows
to easily add espintcp on IPv6 as a follow-up.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
For legacy mode, tx bitrate not show correct sometimes, for example:
iw wlan0 link
Connected to 8c:21:0a:b3:5a:64 (on wlan0)
SSID: tplinkgw
freq: 2462
RX: 19672 bytes (184 packets)
TX: 9851 bytes (87 packets)
signal: -51 dBm
rx bitrate: 54.0 MBit/s
tx bitrate: 2.8 MBit/s
This patch use the tx bitrate info from WMI_TLV_PEER_STATS_INFO_EVENTID
report from firmware, and tx bitrate show correct.
iw wlan0 link
Connected to 8c:21:0a:b3:5a:64 (on wlan0)
SSID: tplinkgw
freq: 2462
RX: 13973 bytes (120 packets)
TX: 6737 bytes (57 packets)
signal: -52 dBm
rx bitrate: 54.0 MBit/s
tx bitrate: 54.0 MBit/s
This patch only effect SDIO chip, ath10k_mac_sta_get_peer_stats_info
has check for bitrate_statistics of hw_params, it is enabled only for
"qca6174 hw3.2 sdio".
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200427080416.8265-5-wgong@codeaurora.org
The rate code and rate kbps report by WMI_TLV_PEER_STATS_INFO_EVENTID
from firmware contains all the bitrate info which include OFDM, CCK,
HT/VHT, and mac80211 need the struct rate_info which include below
parameters:
flags: bitflag of flags from &enum rate_info_flags
mcs: mcs index if struct describes an HT/VHT/HE rate
legacy: bitrate in 100kbit/s for 802.11abg
nss: number of streams (VHT & HE only)
bw: bandwidth (from &enum rate_info_bw)
For OFDM/CCK, its rate kbps indicate the bitrate, for HT/VHT, mac80211
need the above 5 parameters to cacluate the bitrate and show by iw.
After parse the bitrate info, iw show the correct rx bitrate:
localhost ~ # iw wlan0 link
rx bitrate: 234.0 MBit/s VHT-MCS 3 80MHz VHT-NSS 2
rx bitrate: 40.5 MBit/s MCS 2 40MHz
rx bitrate: 72.2 MBit/s MCS 7 short GI
rx bitrate: 54.0 MBit/s
rx bitrate: 48.0 MBit/s
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200427080416.8265-4-wgong@codeaurora.org
For SDIO chip, its rx indication is struct htt_rx_indication_hl, which
does not include the bitrate info as well as PCIe, for PCIe, it use
function ath10k_htt_rx_h_rates to parse the bitrate info in struct
rx_ppdu_start and then report it to mac80211 via ieee80211_rx_status.
SDIO does not have the same info as PCIe, then iw command can not get
the rx bitrate by "iw wlan0 station dump".
for example, it always show 6.0 MBit/s
localhost ~ # iw wlan0 link
Connected to 3c:28:6d:96:fd:69 (on wlan0)
SSID: kukui_test
freq: 5180
RX: 111800 bytes (595 packets)
TX: 35419 bytes (202 packets)
signal: -41 dBm
rx bitrate: 6.0 MBit/s
This patch is to send WMI_TLV_REQUEST_PEER_STATS_INFO_CMDID to firmware
for ath10k_sta_statistics and save the rx bitrate for WMI event
WMI_TLV_PEER_STATS_INFO_EVENTID.
This patch only effect SDIO chip, ath10k_mac_sta_get_peer_stats_info
has check for bitrate_statistics of hw_params, this patch only enable
it for "qca6174 hw3.2 sdio".
Tested with QCA6174 SDIO firmware WLAN.RMH.4.4.1-00042.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200427080416.8265-3-wgong@codeaurora.org
For wmi tlv type, firmware disable peer stats info by default, after
enable it, firmware will report WMI_TLV_PEER_STATS_INFO_EVENTID if
ath10k send WMI_TLV_REQUEST_PEER_STATS_INFO_CMDID to firmware.
Enable it will only set a flag in firmware, firmware will not report
it without receive request WMI command.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200427080416.8265-2-wgong@codeaurora.org
The '>' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:
drivers/net/wireless/ath/ath5k/ani.c:504:56-61: WARNING: conversion to
bool not needed here
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200426094037.23048-1-yanaijie@huawei.com
ADC & I/Q calibrations could take infinite time to comple, since they
depend on received frames. In particular the I/Q mismatch calibration
requires receiving of OFDM frames for completion. But in the 2.4GHz
band, a station could receive only CCK frames for a very long time.
And while we wait for the completion of one of the mentioned
calibrations, the NF calibration is blocked. Moreover, in some
environments, I/Q calibration is unable to complete until a correct
noise calibration will be performed due to AGC behaviour.
In order to avoid delaying NF calibration on forever, limit the maximum
duration of ADCs & I/Q calibrations. If the calibration is not completed
within the maximum time, it will be interrupted and a next calibration
will be performed. The code that selects the next calibration has been
reworked to the loop so incompleted calibration will be respinned later.
Ð maximum calibration time of 30 seconds was selected to give the
calibration enough time to complete and to not interfere with the long
(NF) calibration.
Run tested with AR9220.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200424004923.17129-7-ryazanov.s.a@gmail.com
Previously after the calibration validity period is over,
calibrations are invalidated in a one at time manner. So, for AR9002
family, which has three calibrations, the full recalibration interval
becomes 3 x ATH_RESTART_CALINTERVAL. And each next calibration will be
separated by the ATH_RESTART_CALINTERVAL time from a previous one.
It seems like it is better to do whole recalibration at once. Also, this
change makes the driver behaviour a little simpler. So, invalidate all
calibrations at once at the end of the calibration validity interval.
This change affects only AR9002 chips family, since the AR9003 utilize
only a single calibration.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200424004923.17129-6-ryazanov.s.a@gmail.com
NF calibration and other elements of long calibration are usually faster
than ADCs & I/Q calibrations due to independence of receiption of the
OFDM signal. Moreover sometime I/Q calibration can not be completed at
all without preceding NF calibration. This is due to AGC, which has a
habit to block a weak signal without regular NF calibration. Thus, we do
not need to deferr the long calibration forever.
So, if the long calibration is requested, then deferr the ADCs & I/Q
calibration(s) and run the longcal (the NF calibration in particular) to
obtain fresh noise data.
Run tested with AR9220.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200424004923.17129-5-ryazanov.s.a@gmail.com
Each of AGC & I/Q calibrations can take a long time. Long calibration
and NF calibration in particular are forbiden for parallel run with
ADC & I/Q calibrations. So, the chip could not be ready to perform the
long calibration at the time of request. And a request to perform the
long calibration may be lost.
In order to fix this, preserve the long calibration request as a
calibration state flag and restore the long calibration request each
time the calibration function is called again (i.e. on each subsequent
ivocation of the short calibration).
This feature will be twice useful after the next change, which will
make it possible to start the long calibration before all ADCs & I/Q
calibrations are completed.
Run tested with AR9220.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200424004923.17129-4-ryazanov.s.a@gmail.com
The NFCAL_PENDING flag is set by the ath9k_hw_start_nfcal() routine,
so there is no reason to set it manually after calling it during the
AR9002 calibrations initialization.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200424004923.17129-3-ryazanov.s.a@gmail.com
ADC calibration is only required for a 80 MHz sampling rate (i.e. for
40 MHz channels), when the chip utilizes the pair of ADCs in interleved
mode. Calibration on a 20 MHz channel will never be completed.
Previous channel check is trying to exclude all channels where the
calibration will get stuck. It effectively blocks the calibration run
for HT20 channels, but fails to exclude 20 MHz channels without HT (e.g.
legacy mode channels).
Fix this issue by reworking the channel check to explicitly allow ADCs
gain & DC offset calibrations for HT40 channels only. Also update the
complicated comment to make it clear that these calibrations are for
multi-ADC mode only.
Stuck ADCs calibration blocks the NF calibration, what could make it
impossible to work in a noisy evironment: too big Rx attentuation,
invalid RSSI value, etc. So this change is actually more of a NF
calibration fix rather then the ADC calibration fix.
Run tested with AR9220.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200424004923.17129-2-ryazanov.s.a@gmail.com
This structure is only really used in tboot.c. The only exception
is a single tboot_enabled check, but for that we don't need an inline
function.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200428051703.1625952-1-hch@lst.de
i.MX7ULP's ARM core clock design is totally different compared
with i.MX7D/8M SoCs which supported by imx-cpufreq-dt. It needs
get_intermediate and target_intermedate to configure clk MUX ready,
before let OPP configure ARM core clk.
|---FIRC
|------RUN---...---SCS(MUX2) --------|
ARM --(MUX1) |---SPLL_PFD0(CLK_SET_RATE_GATE)
|------HSRUN--...--HSRUN_SCS(MUX3)---|
|---SRIC
FIRC is step clk, SPLL_PFD0 is the normal clk driving ARM core.
MUX2 and MUX3 share same inputs. So if MUX2/MUX3 both sources from
SPLL_PFD0, both MUXes will lose input when configure SPLL_PFD0.
So the target_intermediate will configure MUX2/MUX3 to FIRC, to avoid
ARM core lose clk when configure SPLL_PFD0.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
With mailbox driver support i.MX8 SCU MU channel, we could
use it to avoid trigger interrupts for each TR/RR registers
in one MU, instead, only one RX interrupt for a recv and
one TX interrupt for a send.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
sparse warnings: (new ones prefixed by >>)
>> drivers/net/wireless/realtek/rtw88/mac.c:653:5: sparse: sparse:
symbol '__rtw_download_firmware' was not declared. Should it be static?
>> drivers/net/wireless/realtek/rtw88/mac.c:817:5: sparse: sparse:
symbol '__rtw_download_firmware_legacy' was not declared. Should it be
static?
Fixes: 15d2fcc6b2 ("rtw88: add legacy firmware download for 8723D devices")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200424101255.28239-1-yhchuang@realtek.com
Usually it does not hurt to add "clock-names" properties, even if the
(pre-json-schema) DT bindings do not mention them.
However, the actual clock names for the OS Timer nodes are not fixed,
but contain the indices of the consumer instances. Hence they cannot
easily be used by a driver, without scanning for all possible indices.
Remove them, as the OSTM DT bindings do not specify clock-names anyway.
Fixes: bbbcd02b82 ("ARM: dts: r7s9210: Initial SoC device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Chris Brandt <Chris.Brandt@renesas.com>
Link: https://lore.kernel.org/r/20200427192932.28967-1-geert+renesas@glider.be
Clock and Power Domain definitions for the Renesas RZ/G1H (R8A7742) SoC,
shared by driver and DT source files.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCXqfi5AAKCRCKwlD9ZEnx
cJcxAP4+fAavWGp1dyIyDdECbmUUNLe6Cw8DN1SVWBlxvy1gugD/TR4Q0QR7dgUZ
ZpeuRTyM7iBDL57TiChwdLyjuFwqpgw=
=l1L1
-----END PGP SIGNATURE-----
Merge tag 'renesas-r8a7742-dt-binding-defs-tag' into renesas-drivers-for-v5.8
Renesas RZ/G1H DT Binding Definitions
Clock and Power Domain definitions for the Renesas RZ/G1H (R8A7742) SoC,
shared by driver and DT source files.
Clock and Power Domain definitions for the Renesas RZ/G1H (R8A7742) SoC,
shared by driver and DT source files.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCXqfi5AAKCRCKwlD9ZEnx
cJcxAP4+fAavWGp1dyIyDdECbmUUNLe6Cw8DN1SVWBlxvy1gugD/TR4Q0QR7dgUZ
ZpeuRTyM7iBDL57TiChwdLyjuFwqpgw=
=l1L1
-----END PGP SIGNATURE-----
Merge tag 'renesas-r8a7742-dt-binding-defs-tag' into clk-renesas-for-v5.8
Renesas RZ/G1H DT Binding Definitions
Clock and Power Domain definitions for the Renesas RZ/G1H (R8A7742) SoC,
shared by driver and DT source files.
mx25u51245g is a mass production for new design and
replace mx66u51235f(phase out).
Validated by read, erase, read back, write and read back
on Xilinx Zynq PicoZed FPGA board which included
Macronix SPI Host (driver/spi/spi-mxic.c).
Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
If probing the LP885x backlight fails after the regulators have been
enabled, then the following warning is seen when releasing the
regulators ...
WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051 _regulator_put.part.28+0x158/0x160
Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables x_tables ipv6 nf_defrag_ipv6
CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1
Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
...
Call trace:
_regulator_put.part.28+0x158/0x160
regulator_put+0x34/0x50
devm_regulator_release+0x10/0x18
release_nodes+0x12c/0x230
devres_release_all+0x34/0x50
really_probe+0x1c0/0x370
driver_probe_device+0x58/0x100
device_driver_attach+0x6c/0x78
__driver_attach+0xb0/0xf0
bus_for_each_dev+0x68/0xc8
driver_attach+0x20/0x28
bus_add_driver+0x160/0x1f0
driver_register+0x60/0x110
i2c_register_driver+0x40/0x80
lp855x_driver_init+0x20/0x1000 [lp855x_bl]
do_one_initcall+0x58/0x1a0
do_init_module+0x54/0x1d0
load_module+0x1d80/0x21c8
__do_sys_finit_module+0xe8/0x100
__arm64_sys_finit_module+0x18/0x20
el0_svc_common.constprop.3+0xb0/0x168
do_el0_svc+0x20/0x98
el0_sync_handler+0xf4/0x1b0
el0_sync+0x140/0x180
Fix this by ensuring that the regulators are disabled, if enabled, on
probe failure.
Finally, ensure that the vddio regulator is disabled in the driver
remove handler.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mx25l51245g is a mass production for new design and
replace mx66l51235l(phase out).
Validated by read, erase, read back, write and read back
on Xilinx Zynq PicoZed FPGA board which included
Macronix SPI Host (driver/spi/spi-mxic.c).
Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
When spi_nor_info_init_params(), spi_nor_sfdp_init_params(), and
spi_nor_init_params() were added, the kernel-doc for them contained
a typo: 'struct spi-nor' instead of 'struct spi_nor' -- fix them.
Fixes: 1c1d8d98e1 ("mtd: spi-nor: Split spi_nor_init_params()")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
When spi_nor_manufacturer_init_params() was added, the kernel-doc for it
contained a typo: 'struct spi-nor' instead of 'struct spi_nor' -- fix it.
Fixes: ce0b6f3f3c ("mtd: spi-nor: Add default_init() hook to tweak flash parameters")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
When adding the 'spimem' field to 'struct spi_nor', a grammar mistake
("point" instead of "pointer") was made -- fix it and convert the SPI
acronym to uppercase and fully spell out "memory", while at it...
Fixes: b35b9a1036 ("mtd: spi-nor: Move m25p80 code in spi-nor.c")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
When adding the 'info' field to 'struct spi_nor', some acronyms were in
lower case and some in upper case and the JEDEC acronym mistyped -- fix
these issues.
Fixes: 46dde01f6b ("mtd: spi-nor: add spi_nor_init() function")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
