The MC firmware will enable the switch interfaces at DPSW creation
without waiting for an 'ifconfig up' on the switch interfaces. When this
happens, the states held by the Linux software vs the firmware are not
in sync. Make sure to disable the switch ports at probe time to not
encounter this issue.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Link: https://lore.kernel.org/r/20200714133431.17532-5-ioana.ciornei@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are some cases where the switch interface needs to be disabled so
that changes in the configuration can be made. In such cases, we should
check for a running interface (bit __LINK_STATE_START of the netdev)
instead of netif_carrier_ok(). This is because on open() we enable the
switch interface even though the link up has not come out yet.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Link: https://lore.kernel.org/r/20200714133431.17532-4-ioana.ciornei@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Link: https://lore.kernel.org/r/20200713091305.32708-1-grandmaster@al2klimov.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Link: https://lore.kernel.org/r/20200708183117.16563-1-grandmaster@al2klimov.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The code has the functionality to insert the GPIO lines using
the global GPIO numbers through module parameters.
As we are clearly deprecating the use of global GPIO numbers
look up the GPIO descriptors from the device instead. This
usually falls back to device hardware descriptions using e.g.
device tree or ACPI. This device clearly supports device
tree when used over SPI for example.
For example, this can be supplied in the device tree like so:
wfx@0x01 {
compatible = "silabs,wf200";
reset-gpios = <&gpio0 1>;
wakeup-gpios = <&gpio0 2>;
};
Cc: Jérôme Pouiller <jerome.pouiller@silabs.com>
Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200703130756.514868-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When multiple interface on different channels are in use. It is
necessary to advertise the AP that the device is no more awake before to
switch to the other channel.
Until now, PS-Poll was the preferred mechanism for that. However. The
new firmwares (>= 3.7) now nicely support FastPS.
FastPS improves bandwidth and compatibility with AP.
This patch drop the complex and rarely used mechanism introduced in the
commit dd5eba1bb5 ("staging: wfx: fix support for AP that do not
support PS-Poll") and use FastPS as soon as it is possible.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-14-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In some advanced usage or debug scenarios, it could interesting to
change the value of ps_timeout or eventually to force use of PS-Poll
frames.
The wext API (used by iwconfig) provide a way to change ps_timeout.
However, this API is obsolete and it seems a little weird to use (it
seems it does apply the change, so the user have to disable then
re-enable de power save)
On side of nl80211, there is no way to change the ps_timeout.
This patch provides a file in debugfs to change the value of ps_timeout.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-13-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.
Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.
So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.
The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.
This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It seems that in the old days, the RSSI information could be missing. In
this case, in order to not pollute the RSSI stats, the frame was
dropped (!).
It is far better to mark the frame with the flag RX_FLAG_NO_SIGNAL_VAL.
In add, the problem seems now fixed in the firmware (at least, it has
not been encountered with recent firmwares).
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-10-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a station go to sleep, the driver receive the status REQUEUE and
forward this answer to mac80211. So, neither the driver, neither the
hardware buffer the frames. So the call to ieee80211_sta_set_buffered is
useless.
In add, it seems that mac80211 does not expect to receive
ieee80211_sta_set_buffered(false) after the station is asleep(). When
the device send data to a station, the following sequence can be
observed:
- Mac80211 call wfx_sta_notify(awake).
- The driver calls ieee80211_sta_set_buffered(true). Since the
station is awake, its TIM is not set.
- Mac80211 receive a power save notification from the station, so it
calls wfx_sta_notify(asleep).
- Then, since the driver has declared it has buffered some frames,
the TIM of the station should be set. This action is delayed by
mac80211.
- The device also notice the station go to sleep. It replies the
REQUEUE status for the buffered frames. The driver forward this
status to mac80211.
- There is no more frames in queues, so the driver call
ieee80211_sta_set_buffered(false).
- Mac80211 updates the TIM but since there is no frames buffered by
the driver, it set the TIM for the station to 0.
Anyway, correctly use the ieee80211_sta_set_buffered() API solves the
problem.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-8-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During the loading of the firmware, the WFX_DCA_GET register provide the
number available bytes in the receiving buffer. It is not necessary to
access to the WFX_DCA_GET after sent of each firmware fragment.
This patch allows to send the firmware:
- in 64ms instead of 130ms using SDIO bus
- in 78ms instead of 115ms using SPI bus
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-6-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The device is able to send multiple Tx confirmations in the one reply.
In this case, there is only one vif identifier for all the
confirmations.
Unfortunately, to generate this kind of messages the device squashes all
the confirmations whatever their vif ID and use the vif ID of the first
confirmation. So, the driver cannot rely on the vif ID mentioned in the
header. Fortunately, using the packet_id, the driver can retrieve the Tx
request and the associated vif.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The device handles 4 queues (one per AC) for each virtual interface (and
maximum 4 virtual interfaces). Until now the driver unified the queue of
all interfaces and handled only 4 queues for whole device.
This architecture did not allow to balance the traffic between the vif. So,
this patch relocate the queues into the vif and change the API accordingly.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
