It adds support of reading chipname via sysfs, so that user space can
distinguish WiFi module among AP5256, AP5256V and 1MW.
- AP5256
reMarkable: ~/ cat /sys/class/ieee80211/phy*/chipname
BCM4345/9
- AP5256V
reMarkable: ~/ cat /sys/class/ieee80211/phy*/chipname
BCM43012/2
- 1MW
reMarkable: ~/ cat /sys/class/ieee80211/phy*/chipname
BCM4345/6
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The chip id can either be four or five digits. For the chip name either
the hexadecimal value needs to be taken (four digits) or the decimal
value (five digits). The function brcmf_chip_name() does this conversion
so use it to store the name in driver revision info.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 756a2b3908 upstream)
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
This is a backport of commit e3062e05e1 ("brcmfmac: Loading the
correct firmware for brcm43456") from upstream.
AP5256 is SDIO based brcm43456 and currently misdetected as brcm43455.
Correct the detection so that the firmware files can be loaded for both
1MW and AP5256 in names as below.
1MW: brcmfmac43455-sdio
AP5256: brcmfmac43456-sdio
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Although upstream accepts the solution of coding country code map in DT,
it will require different DTB between AP5256 (BCM4345/9) and AP5256V
(BCM43012/2). To support both chipsets with single kernel image and
DTB, let's hard code country code map table of AP5256 in driver, and use
it over the one from DT if any.
The map table of AP5256 comes from bcmdhd driver, ccode_43456c5[] in
drivers/net/wireless/bcmdhd/dhd_ccode.c.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
With any regulatory domain requests coming from either user space or
802.11 IE (Information Element), the country is coded in ISO3166
standard. It needs to be translated to firmware country code and
revision with the mapping info in settings->country_codes table.
Support populate country_codes table by parsing the mapping from DT.
The BRCMF_BUSTYPE_SDIO bus_type check gets separated from general DT
validation, so that country code can be handled as general part rather
than SDIO bus specific one.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Instead of aborting country code setup in firmware, use ISO3166 country
code and 0 rev as fallback, when country_codes mapping table is not
configured. This fallback saves the country_codes table setup for recent
brcmfmac chipsets/firmwares, which just use ISO3166 code and require no
revision number.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The newest firmwares provide STA info using v7 of the struct. As v7
isn't backward compatible, a union is needed.
Even though brcmfmac does not use any of the new info it's important to
provide the proper struct buffer. Without this change new firmwares will
fallback to the very limited v3 instead of something in between such as
v4.
Signed-off-by: Dan Haab <dan.haab@luxul.com>
Reviewed-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 4282ff17e5 upstream)
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
That struct is used when querying firmware for the STA. It seem is has
been changing during the time. Luckily its format seems to be backward
compatible starting with v2 (the only breakage was v1 -> v2).
The version that was supported by brcmfmac so far was v4. It was what
43602a1 and 4366b1 firmwares (7.35.177.56 and 10.10.69.3309 accordingly)
were using. It also seems to be used by early 4366c0 firmwares
(10.10.69.6908 and 10.10.69.69017).
The problem appears when switching to the 10.10.122.20 firmware. It uses
v5 and instead of falling back to v4 when submitted buffer isn't big
enough it fallbacks to the v3.
To receive all v4 specific info with the newest firmware we have to
submit a struct (buffer) that matches v5.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 07b1ae4687 upstream)
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
That struct is passed by a firmware when querying for STA info. Flags
are used to indicate what info could be obtained.
These new defines may allow passing more info to the cfg80211 in the
future. They had been obtained from Broadcom's SDK file wlioctl_defs.h
used by DD-WRT.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 4b4a8d808c upstream)
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
from patchwork.kernel.org:
The linux-firmware brcmfmac firmware files contain an embedded table with
per country allowed channels and strength info.
These versions of the firmware are specially build for linux-firmware,
the firmware files directly available from Broadcom / Cypress rely on
a separate clm_blob file for this info.
For some unknown reason Broadcom / Cypress refuse to provide the standard
firmware files + clm_blob files it uses elsewhere for inclusion into
linux-firmware, instead relying on these special builds with the clm_blob
info embedded. This means that the linux-firmware firmware versions often
lag behind, but I digress.
The brcmfmac driver does support the separate clm_blob file and always
tries to load this. Currently we use request_firmware for this. This means
that on any standard install, using the standard combo of linux-kernel +
linux-firmware, we will get a warning:
"Direct firmware load for ... failed with error -2"
On top of this, brcmfmac itself prints: "no clm_blob available (err=-2),
device may have limited channels available" and we will get a slow
fallback to the userspace firmware loading mechanism.
This commit fixes both almost any brcmfmac device logging the warning
(leaving the brcmfmac info message in pace), as well as the slow and
unnecesary fallback by switching to request_firmware_direct for
the clm_blob.
The system can be wakeuped only when system is totally suspend, when the
wakeup event comes during suspend will cause the system hang. For the reason
that CAN will not call flexcan_noirq_resume() callback if the wakeup event
comes before noirq suspend stage.
The way to fix the issue is that assure the system to call
flexcan_noirq_suspend() during suspend and then call
flexcan_noirq_resume() during resume.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
When dev->power.can_wakeup set to true, device_prepare() may runtime resume the device:
dpm_suspend_start()
dpm_prepare(state);
dev->driver->pm->prepare()
pm_genpd_prepare()
if (resume_needed(dev, genpd))
pm_runtime_resume(dev);
And imx8qm/qxp power domain driver don't implement the active_wakeup() callback, then
resume_needed() always return "true" when dev->power.can_wakeup is true.
Once CAN device is runtime active status, then CAN's clock's count is 1 during system
suspend. And CAN0/CAN1/CAN2 share the same module clock, so we can say all CAN's module
clock is enabled during system suspended.
flexcan_runtime_resume()
flexcan_clks_enable(priv);
i.MX8QM/QXP SCU code clock logic requires linux kernel clocks should be disabled during
suspend, otherwise SCU don't enable them after system resume back.
There are two ways to fix the issue:
1. CAN driver should check the runtime status to ensure all clocks are disabled during
system suspend.
2. Don't set CAN wakeup capability during probe, move it into flexcan_open().
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Check the return value of .brcmf_fil_iovar_data_get() to fix
the coverity issue of "error handling issue".
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Init the wlfc_mode variable before it is used to fix
coverity issue of "Uninitialized variable".
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
The flexcan driver allocates canfd-skb no matter whether use CAN FD
mode or not, it's unreasonable due to it will affect the parse of the
remote request frame.
To fix the issue, allocating can-skb with "alloc_can_skb()" in normal
mode and canfd-skb with "alloc_canfd_skb()" in fd mode.
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
commit f5e64032a7 ("net: phy: fix resume handling") and commit 6bccf8962b
(net: phy: Restore phy_resume() locking assumption) make phy_resume() take
phydev->lock mutex, not PHY driver resume callback take that lock.
(The two commits enter kernel tree after v4.9, so v4.9 has no such issue)
To avoid dead lock, fix it by ensuring that the PHY driver resume methods
do not take the phydev->lock mutex themselves, but phy_resume() only take
that lock.
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
This patch is to add CAN wakeup function on MX8 platforms and update the
binding file fsl-flexcan.txt.
For MX8, the function "flexcan_irq()" should not call "flexcan_exit_stop_mode()"
due to firmware(SCU) cannot make SC IPC calls from an interrupt context.
If not exit stop mode in ISR, it will continuously enter wakeup ISR for the reason
that system will respond IRQ before call CAN system resume.
To fix the issue, we can exit stop mode during noirq resume stage.
For wakeup case, it should not set pinctrl to sleep state by
pinctrl_pm_select_sleep_state.
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Andy Duan <fugang.duan@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
When do CAN wakeup test, it printed "flexcan 2094000.can: Unbalanced
pm_runtime_enable!" warning.
For wakeup system resume case, it will call pm_runtime_force_resume(),
however, pm_runtime_force_suspend() haven't been called in system suspend.
While pm_runtime_force_resume() will decrease the variable "disable_depth",
and pm_runtime_force_suspend() will increase "disable_depth". So, if we
didn't call pm_runtime_force_suspend() but called pm_runtime_force_resume(),
would produce this waring.
To fix this warning, pm_runtime_force_suspend() and pm_runtime_force_resume()
should appear in pairs.
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Andy Duan <fugang.duan@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Configure wowl parameters only if firmware support wowl.
Tested-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Lo-Hsiang Lo <double.lo@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
In WLAN, priority among various access categories of traffic is
always set by the AP using WMM parameters and this may not always
follow the standard 802.1d priority.
In this change, priority is adjusted based on the AP WMM params
received as part of the Assoc Response and the same is later used
to map the priority of all incoming traffic.
This change should fix the following 802.11n certification tests:
* 5.2.31 ACM Bit Conformance test
* 5.2.32 AC Parameter Modification test
Signed-off-by: Saravanan Shanmugham <sasm@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
The driver sends an action frame down and waits for a completion signal
triggered by the received BRCMF_E_ACTION_FRAME_OFF_CHAN_COMPLETE event
to continue the process. However, the action frame could be transmitted
either on the current channel or on an off channel. For the on-channel
case, only BRCMF_E_ACTION_FRAME_COMPLETE event will be received when
the frame is transmitted, which make the driver always wait a full
timeout duration. This patch has the completion signal be triggered by
receiving the BRCMF_E_ACTION_FRAME_COMPLETE event for the on-channel
case.
Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Finding a common channel to send an action frame out is required for
some action types. Since a loop with several scan retry is used to find
the channel, a short wait time could be considered for each attempt.
This patch reduces the wait time from 1500 to 450 msec for each action
frame scan.
Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Will enable FMAC to push more packets to bus tx queue and help
improve throughput when fws queuing is enabled. This change is
required to tune the throughput for passing WMM CERT tests.
Signed-off-by: Madhan Mohan R <MadhanMohan.R@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Transaction between AOS and SDIOD is not protected, and if cmd 52
received in AOS and in the middle of response state changed from AOS to
SDIOD, response is corrupted and it causes to SDIO Host controller to
hang.
Signed-off-by: Lo-Hsiang Lo <double.lo@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
P2p spec mentioned that the p2p device address should be the globally
administered address with locally administered bit set. Therefore,
follow this guideline by default.
When the primary interface is set to a locally administered address, the
locally administered bit cannot be set again. Generate a random locally
administered address for this case.
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Send P2P Presence Response from the p2p interface address instead
of the p2p device address.
Signed-off-by: Madhan Mohan R <MadhanMohan.R@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
brcmfmac is a FullMAC driver and it implements/uses cfg80211 interface
for stations management. At the same time it doesn't receive or pass up
management frames.
This flag indicates that authenticator doesn't have to subscribe to or
handle management frames. Some authenticators (e.g. hostapd) were
working with brcmfmac thanks to some extra assumptions. This commit
clears up the situation.
Signed-off-by: Rafal Milecki <rafal@milecki.pl>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Transaction between AOS and SDIOD is not protected, and if cmd 52
received in AOS and in the middle of response state changed from AOS to
SDIOD, response is corrupted and it causes to SDIO Host controller to
hang.
Signed-off-by: Wright Feng <wright.feng@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
The variable "wq_flags" is not used anymore. Remove it.
Signed-off-by: Wright Feng <wright.feng@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
The firmware does not respond ARP request and causes ping failed with
following steps.
1. Bring up inteface
ifconfig wlan0 up or start wpa_supplicant
2. Set the IP address
ifconfig wlan0 192.168.100.10
3. Bring down interface or
ifconfig wlan0 down or kill wpa_supplicant
4. Bring up inteface again and set the same IP address
5. Connect to AP(192.168.100.1) and ping to AP will be failed.
FMAC clears arp_hostip when bringing down the interface, but not set it
back if setting the same IP address. We are able to see the IP address
in interface info(inconfig wlan0) but the ping still cannot work because
the firmware ARP offload does not respond the ARP request.
Because of that, we remove "arp_hostip_clear" from function
"brcmf_netdev_stop"
Signed-off-by: Wright Feng <wright.feng@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
The credit numbers are static and tunable per chip in firmware side.
However the credit number may be changed that is based on packet pool
length and will send BRCMF_E_FIFO_CREDIT_MAP event to ask host driver
updating the credit numbers during interface up.
The purpose of this patch is making host driver has ability of updating
the credit numbers when receiving the BRCMF_E_FIFO_CREDIT_MAP event.
Signed-off-by: Wright Feng <wright.feng@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
With setting sdio_wq_highpri=1 in module parameters, tasks submitted to
SDIO workqueue will put at the head of the queue and run immediately.
This parameter is for getting higher TX/RX throughput with SDIO bus.
Signed-off-by: Wright Feng <wright.feng@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Firmware inform the driver about tx status by normal tx status signal
or compressed tx status signal. This patch adds support to handle the
compressed tx status signal.
Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
CYW89342 is a 2x2 MIMO,802.11a/b/g/n/ac,SDIO 3.0 and PCIe 3.0 for WLAN.
It is an automotive wireless chip.
Signed-off-by: Saint Chuang <jiac@cypress.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
This patch does't add new feature just clean up the code. We choose the
exist method in upstream to read/write registers, but modify the method
to read/write mailboxes. The struct of "flexcan_mb" and variables of
"tx_mb/tx_mb_reserved" will not be used, so delete them.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
tree
Normally CAN FD capable device must work on FD mode as it has different
statically claimed bittiming capability.
This patch provides users to disable CAN FD capability if users want
to only work at normal mode.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
combination
CAN FD can only support some specific bitrate combinations in FD mode
due to HW limitations. See below info mentioned in RM:
"To minimize errors when processing FD frames, use the same value
for FPRESDIV and PRESDIV (in CAN_CBT or CAN_CTRL1)."
Add notes in driver to let user know easily:
CAN FD supported rates combinations
* Combination 1:
* Bitrate: 225000 375000 400000 425000 500000 875000
* Data rate: 1000000
*
* Combination 2:
* Bitrate: 550000 600000 625000 650000 675000 750000 775000
* 800000 850000 925000 950000 975000 1000000
* Data rate: 1500000 2000000 2500000 3000000 3500000 4000000
* 5000000
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
The CAN bit timing variables (PRESDIV, PROPSEG, PSEG1, PSEG2 and RJW)
can also be configured in CAN_CBT register, which extends the range of
all these variables. It can improve the bittiming accuracy.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Shawn Guo