* Re: [RFC] mt76: fix tx hung regression on MT7630E
From: Stanislaw Gruszka @ 2019-07-30 13:54 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, Felix Fietkau, Ryder Lee, Roy Luo
In-Reply-To: <20190729140241.GC4030@localhost.localdomain>
On Mon, Jul 29, 2019 at 04:02:41PM +0200, Lorenzo Bianconi wrote:
> > On Fri, Jul 26, 2019 at 02:10:56PM +0200, Stanislaw Gruszka wrote:
> > > Since 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
> > > I can observe firmware hangs on MT7630E on station mode: tx stop
> > > functioning after minor activity (rx keep working) and on module
> > > unload device fail to stop with messages:
> > >
> > > [ 5446.141413] mt76x0e 0000:06:00.0: TX DMA did not stop
> > > [ 5449.176764] mt76x0e 0000:06:00.0: TX DMA did not stop
> > >
> > > Loading module again results in failure to associate with AP.
> > > Only machine power off / power on cycle can make device work again.
> > >
> > > I have no idea why the commit caused F/W hangs. Most likely some proper
> > > fix is needed of changing registers programming (or assuring proper order
> > > of actions), but so far I can not came up with any better fix than
> > > a partial revert of 41634aa8d6db.
> >
> > The difference is that with 41634aa8d6db we can run mt76x02_poll_tx()
> > and mt76x02_tx_tasklet() in parallel on 2 different CPUs. Without
> > the commit, since tasklet is not scheduled from mt76_wake_tx_queue(),
> > it does not happen.
> >
> > I'm not quite sure why, but MT7630E does not like when we poll tx status
> > on 2 cpus at once. Change like below:
>
> Hi Stanislaw,
Hi
> have you tried to look at the commit: 6fe533378795f87
> ("mt76: mt76x02: remove irqsave/restore in locking for tx status fifo")?
> Could it be a race between a registermap update and a stats load? (we are using a
> different lock now)
This commit seems to be fine, reverting it did not solve the issue.
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > index 467b28379870..622251faa415 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
> > @@ -170,7 +170,7 @@ static int mt76x02_poll_tx(struct napi_struct *napi, int budget)
> > mt76.tx_napi);
> > int i;
> >
> > - mt76x02_mac_poll_tx_status(dev, false);
> > + mt76x02_mac_poll_tx_status(dev, true);
>
> I am not sure if we really need mt76x02_mac_poll_tx_status() here since we run
> it in mt76x02_tx_complete_skb() and in mt76x02_tx_tasklet(). Anyway the only
> difference doing so is we do not run mt76x02_send_tx_status().
I thought this is the problem, but it was my mistake during testing.
I tested the above change together with mt76_txq_schedule(dev, txq->ac)
change and get wrong impression it fixes the issue. But above change
alone does not help.
I tried to add some locking to avoid parallel execution of mt76x02_poll_tx()
and mt76x02_tx_tasklet(), but it didn't help either. So far only patch
originally posted here make the problem gone.
Stanislaw
^ permalink raw reply
* [PATCH] Revert "mac80211: set NETIF_F_LLTX when using intermediate tx queues"
From: Johannes Berg @ 2019-07-30 12:54 UTC (permalink / raw)
To: linux-wireless
Cc: Jean Delvare, Peter Lebbing, Felix Fietkau,
Toke Høiland-Jørgensen, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Revert this for now, it has been reported multiple times that it
completely breaks connectivity on various devices.
Cc: stable@vger.kernel.org
Fixes: 8dbb000ee73b ("mac80211: set NETIF_F_LLTX when using intermediate tx queues")
Reported-by: Jean Delvare <jdelvare@suse.de>
Reported-by: Peter Lebbing <peter@digitalbrains.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/iface.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 06aac0aaae64..8dc6580e1787 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1222,7 +1222,6 @@ static void ieee80211_if_setup(struct net_device *dev)
static void ieee80211_if_setup_no_queue(struct net_device *dev)
{
ieee80211_if_setup(dev);
- dev->features |= NETIF_F_LLTX;
dev->priv_flags |= IFF_NO_QUEUE;
}
--
2.20.1
^ permalink raw reply related
* NETIF_F_LLTX breaks iwlwifi
From: Jean Delvare @ 2019-07-30 12:18 UTC (permalink / raw)
To: Felix Fietkau, Toke Høiland-Jørgensen, Johannes Berg
Cc: David S. Miller, linux-wireless, netdev, linux-kernel
Hi Felix, Toke, Johannes,
After updating to kernel 5.2, I started losing wireless network on my
workstation a few minutes after boot. I could restart the network
service to get it back, but it would go away again a few minutes later.
No error message logged, but somehow the network traffic was no long
being processed.
My hardware is:
05:00.0 Network controller [0280]: Intel Corporation Wireless 8265 / 8275 [8086:24fd] (rev 78)
This is an Intel 8265 PCIe WiFI adapter by Gigabyte, model GC-WB867D-I,
which worked flawlessly for me until then.
I bisected it down to:
commit 8dbb000ee73be2c05e34756739ce308885312a29 (refs/bisect/bad)
Author: Felix Fietkau
Date: Sat Mar 16 18:06:34 2019 +0100
mac80211: set NETIF_F_LLTX when using intermediate tx queues
So whatever the commit message says, it is apparently not safe to run
TX handlers on multiple CPUs in parallel for this specific driver /
device.
Unless someone has an immediate explanation as to why it broke the
iwlwifi driver and the actual bug is in iwlwifi and it can be fixed
quickly and easily there, I would suggest that the above commit is
reverted for the time being, as apparently it wasn't fixing anything
but was just a performance optimization.
I am available to do any amount of tests or debugging, given the
guidance.
Thanks,
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* [PATCH] rtw88: pci: enable MSI interrupt
From: yhchuang @ 2019-07-30 11:50 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, jano.vesely, briannorris
From: Yu-Yen Ting <steventing@realtek.com>
MSI interrupt should be enabled on certain platform.
Add a module parameter disable_msi to disable MSI interrupt,
driver will then use legacy interrupt instead.
And the interrupt mode is not able to change at run-time, so
the module parameter is read only.
Tested-by: Ján Veselý <jano.vesely@gmail.com>
Signed-off-by: Yu-Yen Ting <steventing@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
---
drivers/net/wireless/realtek/rtw88/pci.c | 51 ++++++++++++++++++++++++++++++--
drivers/net/wireless/realtek/rtw88/pci.h | 1 +
2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index 23dd06a..25410f6 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -10,6 +10,10 @@
#include "rx.h"
#include "debug.h"
+static bool rtw_disable_msi;
+module_param_named(disable_msi, rtw_disable_msi, bool, 0444);
+MODULE_PARM_DESC(disable_msi, "Set Y to disable MSI interrupt support");
+
static u32 rtw_pci_tx_queue_idx_addr[] = {
[RTW_TX_QUEUE_BK] = RTK_PCI_TXBD_IDX_BKQ,
[RTW_TX_QUEUE_BE] = RTK_PCI_TXBD_IDX_BEQ,
@@ -874,6 +878,7 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void *dev)
if (!rtwpci->irq_enabled)
goto out;
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -893,6 +898,8 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void *dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+
out:
spin_unlock(&rtwpci->irq_lock);
@@ -1103,6 +1110,45 @@ static struct rtw_hci_ops rtw_pci_ops = {
.write_data_h2c = rtw_pci_write_data_h2c,
};
+static int rtw_pci_request_irq(struct rtw_dev *rtwdev, struct pci_dev *pdev)
+{
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ int ret;
+
+ if (!rtw_disable_msi) {
+ ret = pci_enable_msi(pdev);
+ if (ret) {
+ rtw_warn(rtwdev, "failed to enable msi, using legacy irq\n");
+ } else {
+ rtw_warn(rtwdev, "pci msi enabled\n");
+ rtwpci->msi_enabled = true;
+ }
+ }
+
+ ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler, IRQF_SHARED,
+ KBUILD_MODNAME, rtwdev);
+ if (ret) {
+ rtw_err(rtwdev, "failed to request irq\n");
+ if (rtwpci->msi_enabled) {
+ pci_disable_msi(pdev);
+ rtwpci->msi_enabled = false;
+ }
+ }
+
+ return ret;
+}
+
+static void rtw_pci_free_irq(struct rtw_dev *rtwdev, struct pci_dev *pdev)
+{
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+
+ free_irq(pdev->irq, rtwdev);
+ if (rtwpci->msi_enabled) {
+ pci_disable_msi(pdev);
+ rtwpci->msi_enabled = false;
+ }
+}
+
static int rtw_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
@@ -1157,8 +1203,7 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = rtw_pci_request_irq(rtwdev, pdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1197,7 +1242,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ rtw_pci_free_irq(rtwdev, pdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
diff --git a/drivers/net/wireless/realtek/rtw88/pci.h b/drivers/net/wireless/realtek/rtw88/pci.h
index 87824a4..a8e369c 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.h
+++ b/drivers/net/wireless/realtek/rtw88/pci.h
@@ -186,6 +186,7 @@ struct rtw_pci {
spinlock_t irq_lock;
u32 irq_mask[4];
bool irq_enabled;
+ bool msi_enabled;
u16 rx_tag;
struct rtw_pci_tx_ring tx_rings[RTK_MAX_TX_QUEUE_NUM];
--
2.7.4
^ permalink raw reply related
* RE: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: David Laight @ 2019-07-30 9:48 UTC (permalink / raw)
To: 'Stanislaw Gruszka', Jian-Hong Pan
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com,
stable@vger.kernel.org
In-Reply-To: <20190730093533.GC3174@redhat.com>
From: Stanislaw Gruszka
> Sent: 30 July 2019 10:36
...
> > + len = pkt_stat.pkt_len + pkt_offset;
> > + skb = dev_alloc_skb(len);
> > + if (WARN_ONCE(!skb, "rx routine starvation\n"))
> > goto next_rp;
> >
> > /* put the DMA data including rx_desc from phy to new skb */
> > - skb_put_data(new, skb->data, new_len);
> > + skb_put_data(skb, rx_desc, len);
>
> Coping big packets it quite inefficient. What drivers usually do is
> copy only for small packets and for big ones allocate new rx buf
> (drop packet alloc if fail) and pas old buf to network stack via
> skb_add_rx_frag(). See iwlmvm as example.
If you have to do iommu setup/teardown then the breakeven point
for (not) copying may be surprisingly large.
You do need to do the measurements on a range of hardware.
Coping is also likely to affect the L1 cache - unless you can
copy quickly without polluting the cache.
It is all 'swings and roundabouts'.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: Stanislaw Gruszka @ 2019-07-30 9:35 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, David Laight,
linux-wireless, netdev, linux-kernel, linux, stable
In-Reply-To: <20190725080925.6575-1-jian-hong@endlessm.com>
On Thu, Jul 25, 2019 at 04:09:26PM +0800, Jian-Hong Pan wrote:
> Each skb as the element in RX ring was expected with sized buffer 8216
> (RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is
> 16640 bytes for alignment after allocated, x86_64 for example. And, the
rtw88 advertise IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454, so maximum AMSDU
packet can be approximately 12kB. This might be accidental, but having
16kB skb's allow to handle such big AMSDUs. If you shrink buf size,
you can probably override memory after buffer end.
> difference will be enlarged 512 times (RTK_MAX_RX_DESC_NUM).
> To prevent that much wasted memory, this patch follows David's
> suggestion [1] and uses general buffer arrays, instead of skbs as the
> elements in RX ring.
>
> [1] https://www.spinics.net/lists/linux-wireless/msg187870.html
>
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> Cc: <stable@vger.kernel.org>
This does not fix any serious problem, it actually most likely
introduce memory corruption problem described above. Should not
be targeted to stable anyway.
> - dev_kfree_skb_any(skb);
> + devm_kfree(rtwdev->dev, buf);
For what this is needed? devm_ allocations are used exactly to avoid
manual freeing.
> + len = pkt_stat.pkt_len + pkt_offset;
> + skb = dev_alloc_skb(len);
> + if (WARN_ONCE(!skb, "rx routine starvation\n"))
> goto next_rp;
>
> /* put the DMA data including rx_desc from phy to new skb */
> - skb_put_data(new, skb->data, new_len);
> + skb_put_data(skb, rx_desc, len);
Coping big packets it quite inefficient. What drivers usually do is
copy only for small packets and for big ones allocate new rx buf
(drop packet alloc if fail) and pas old buf to network stack via
skb_add_rx_frag(). See iwlmvm as example.
Stanislaw
^ permalink raw reply
* [PATCH V8] mac80211: add hw 80211 encapsulation offloading support
From: John Crispin @ 2019-07-30 9:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin, Vasanthakumar Thiagarajan
This patch adds a new transmit path for hardware that supports 802.11
encapsulation offloading. In those cases 802.3a frames get passed
directly to the driver allowing to hardware to handle the encapsulation.
Certain features wont work and the patch masks these out.
* monitor interfaces are not supported if any of the vif is in encap mode.
* amsdu/non-linear frames wont work in encap offloading mode.
* TKIP countermeasures cannot be triggered and hence those keys are not
accepted.
The patch defines a secondary netdev_ops struct that the device is assigned
to the device if 802.11 encap support is available and enabled. The driver
needs to enable the support on a per vif basis if it finds that all
pre-reqs are meet.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: John Crispin <john@phrozen.org>
---
Changes in V8
* fix double locking when setting frag threshold
Changes in V7
* dont mask out monitor support when encap is available. Instead turn encap
of if a monitor device is brought up or already present
Changes in V6
* the conditional masking out monitor support was inverse
Changes in V5
* implement comments from Johannes
Changes in V4
* disable encap when TKIP is used instead of refusing TKIP
* use a flag inside tx_info instead of an extra element
* move 4addr detection into ieee80211_set_hw_80211_encap()
* ieee80211_tx_dequeue() was dropping out to early
Changes in V3
* rebase on latest kernel
* various code style clean ups
* give some of the variables and functions more obvious names
* move the code that disables support for non-linear frames to the core
* disable monitor and tkip support
include/net/mac80211.h | 25 +++++
net/mac80211/cfg.c | 6 ++
net/mac80211/debugfs.c | 1 +
net/mac80211/ieee80211_i.h | 10 ++
net/mac80211/iface.c | 100 ++++++++++++++++++++
net/mac80211/key.c | 7 ++
net/mac80211/main.c | 4 +-
net/mac80211/status.c | 79 ++++++++++++++++
net/mac80211/tx.c | 187 ++++++++++++++++++++++++++++++++++++-
9 files changed, 413 insertions(+), 6 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index bd91388797fc..4370c58465db 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -822,6 +822,7 @@ enum mac80211_tx_control_flags {
IEEE80211_TX_CTRL_AMSDU = BIT(3),
IEEE80211_TX_CTRL_FAST_XMIT = BIT(4),
IEEE80211_TX_CTRL_SKIP_MPATH_LOOKUP = BIT(5),
+ IEEE80211_TX_CTRL_HW_80211_ENCAP = BIT(6),
};
/*
@@ -2280,6 +2281,9 @@ struct ieee80211_txq {
* aggregating MPDUs with the same keyid, allowing mac80211 to keep Tx
* A-MPDU sessions active while rekeying with Extended Key ID.
*
+ * @IEEE80211_HW_SUPPORTS_80211_ENCAP: Hardware/driver supports 802.11
+ * encap for data frames.
+ *
* @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
*/
enum ieee80211_hw_flags {
@@ -2332,6 +2336,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SUPPORTS_MULTI_BSSID,
IEEE80211_HW_SUPPORTS_ONLY_HE_MULTI_BSSID,
IEEE80211_HW_AMPDU_KEYBORDER_SUPPORT,
+ IEEE80211_HW_SUPPORTS_80211_ENCAP,
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
@@ -4628,6 +4633,25 @@ static inline void ieee80211_tx_status_ni(struct ieee80211_hw *hw,
void ieee80211_tx_status_irqsafe(struct ieee80211_hw *hw,
struct sk_buff *skb);
+/**
+ * ieee80211_tx_status_8023 - transmit status callback for 802.3 frame format
+ *
+ * Call this function for all transmitted data frames after their transmit
+ * completion. This callback should only be called for data frames which
+ * are are using driver's (or hardware's) offload capability of encap/decap
+ * 802.11 frames.
+ *
+ * This function may not be called in IRQ context. Calls to this function
+ * for a single hardware must be synchronized against each other.
+ *
+ * @hw: the hardware the frame was transmitted by
+ * @vif: the interface for which the frame was transmitted
+ * @skb: the frame that was transmitted, owned by mac80211 after this call
+ */
+void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct sk_buff *skb);
+
/**
* ieee80211_report_low_ack - report non-responding station
*
@@ -6408,4 +6432,5 @@ void ieee80211_nan_func_match(struct ieee80211_vif *vif,
struct cfg80211_nan_match_params *match,
gfp_t gfp);
+bool ieee80211_set_hw_80211_encap(struct ieee80211_vif *vif, bool enable);
#endif /* MAC80211_H */
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 4d458067d80d..5be377b048c7 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2425,11 +2425,17 @@ static int ieee80211_set_mcast_rate(struct wiphy *wiphy, struct net_device *dev,
static int ieee80211_set_wiphy_params(struct wiphy *wiphy, u32 changed)
{
struct ieee80211_local *local = wiphy_priv(wiphy);
+ struct ieee80211_sub_if_data *sdata;
int err;
if (changed & WIPHY_PARAM_FRAG_THRESHOLD) {
ieee80211_check_fast_xmit_all(local);
+ mutex_lock(&local->iflist_mtx);
+ list_for_each_entry(sdata, &local->interfaces, list)
+ ieee80211_set_hw_80211_encap(&sdata->vif, false);
+ mutex_unlock(&local->iflist_mtx);
+
err = drv_set_frag_threshold(local, wiphy->frag_threshold);
if (err) {
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 568b3b276931..87ece0640a43 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -272,6 +272,7 @@ static const char *hw_flag_names[] = {
FLAG(SUPPORTS_MULTI_BSSID),
FLAG(SUPPORTS_ONLY_HE_MULTI_BSSID),
FLAG(AMPDU_KEYBORDER_SUPPORT),
+ FLAG(SUPPORTS_80211_ENCAP),
#undef FLAG
};
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 38769f5c3da4..eaa0423eaaf9 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -984,6 +984,8 @@ struct ieee80211_sub_if_data {
} debugfs;
#endif
+ bool hw_80211_encap;
+
/* must be last, dynamically sized area in this! */
struct ieee80211_vif vif;
};
@@ -1731,6 +1733,7 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
struct vif_params *params);
int ieee80211_if_change_type(struct ieee80211_sub_if_data *sdata,
enum nl80211_iftype type);
+bool ieee80211_is_hw_80211_encap(struct ieee80211_local *local);
void ieee80211_if_remove(struct ieee80211_sub_if_data *sdata);
void ieee80211_remove_interfaces(struct ieee80211_local *local);
u32 ieee80211_idle_off(struct ieee80211_local *local);
@@ -1758,6 +1761,8 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
struct net_device *dev);
netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
struct net_device *dev);
+netdev_tx_t ieee80211_subif_start_xmit_8023(struct sk_buff *skb,
+ struct net_device *dev);
void __ieee80211_subif_start_xmit(struct sk_buff *skb,
struct net_device *dev,
u32 info_flags,
@@ -1941,6 +1946,11 @@ void __ieee80211_tx_skb_tid_band(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb, int tid,
enum nl80211_band band, u32 txdata_flags);
+/* sta_out needs to be checked for ERR_PTR() before using */
+int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
+ struct sk_buff *skb,
+ struct sta_info **sta_out);
+
static inline void
ieee80211_tx_skb_tid_band(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb, int tid,
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 06aac0aaae64..1943e5399475 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1173,6 +1173,105 @@ static const struct net_device_ops ieee80211_dataif_ops = {
.ndo_get_stats64 = ieee80211_get_stats64,
};
+static const struct net_device_ops ieee80211_dataif_8023_ops = {
+ .ndo_open = ieee80211_open,
+ .ndo_stop = ieee80211_stop,
+ .ndo_uninit = ieee80211_uninit,
+ .ndo_start_xmit = ieee80211_subif_start_xmit_8023,
+ .ndo_set_rx_mode = ieee80211_set_multicast_list,
+ .ndo_set_mac_address = ieee80211_change_mac,
+ .ndo_select_queue = ieee80211_netdev_select_queue,
+ .ndo_get_stats64 = ieee80211_get_stats64,
+};
+
+static void __ieee80211_set_hw_80211_encap(struct ieee80211_sub_if_data *sdata,
+ bool enable)
+{
+ if (enable) {
+ sdata->dev->netdev_ops = &ieee80211_dataif_8023_ops;
+ sdata->hw_80211_encap = true;
+ } else {
+ sdata->dev->netdev_ops = &ieee80211_dataif_ops;
+ sdata->hw_80211_encap = false;
+ }
+}
+
+bool ieee80211_set_hw_80211_encap(struct ieee80211_vif *vif, bool enable)
+{
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_sub_if_data *iter;
+ struct ieee80211_key *key;
+
+ sdata_assert_lock(sdata);
+
+ mutex_lock_nested(&local->iflist_mtx, 1);
+ list_for_each_entry(iter, &local->interfaces, list) {
+ if (vif->type == NL80211_IFTYPE_MONITOR)
+ __ieee80211_set_hw_80211_encap(iter, false);
+ else if (iter->vif.type == NL80211_IFTYPE_MONITOR)
+ enable = 0;
+ }
+ mutex_unlock(&local->iflist_mtx);
+
+ if (enable == sdata->hw_80211_encap)
+ return enable;
+
+ switch (vif->type) {
+ case NL80211_IFTYPE_STATION:
+ if (sdata->u.mgd.use_4addr)
+ enable = 0;
+ break;
+ case NL80211_IFTYPE_AP_VLAN:
+ if (sdata->wdev.use_4addr)
+ enable = 0;
+ break;
+ default:
+ break;
+ }
+
+ if (!sdata->dev)
+ return 0;
+
+ if (!ieee80211_hw_check(&local->hw, SUPPORTS_80211_ENCAP))
+ enable = 0;
+
+ if (!ieee80211_hw_check(&local->hw, SUPPORTS_TX_FRAG) &&
+ (local->hw.wiphy->frag_threshold != (u32)-1))
+ enable = 0;
+
+ mutex_lock(&sdata->local->key_mtx);
+ list_for_each_entry(key, &sdata->key_list, list) {
+ if (key->conf.cipher == WLAN_CIPHER_SUITE_TKIP)
+ enable = 0;
+ }
+ mutex_unlock(&sdata->local->key_mtx);
+
+ __ieee80211_set_hw_80211_encap(sdata, enable);
+
+ return enable;
+}
+EXPORT_SYMBOL(ieee80211_set_hw_80211_encap);
+
+bool ieee80211_is_hw_80211_encap(struct ieee80211_local *local)
+{
+ struct ieee80211_sub_if_data *sdata;
+ bool offloaded = false;
+
+ rcu_read_lock();
+ mutex_lock(&local->iflist_mtx);
+ list_for_each_entry_rcu(sdata, &local->interfaces, list) {
+ if (sdata->hw_80211_encap) {
+ offloaded = true;
+ break;
+ }
+ }
+ mutex_unlock(&local->iflist_mtx);
+ rcu_read_unlock();
+
+ return offloaded;
+}
+
static u16 ieee80211_monitor_select_queue(struct net_device *dev,
struct sk_buff *skb,
struct net_device *sb_dev)
@@ -1405,6 +1504,7 @@ static void ieee80211_setup_sdata(struct ieee80211_sub_if_data *sdata,
sdata->vif.bss_conf.idle = true;
sdata->noack_map = 0;
+ sdata->hw_80211_encap = false;
/* only monitor/p2p-device differ */
if (sdata->dev) {
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 7dfee848abac..220726d56235 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -176,6 +176,10 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
}
}
+ /* TKIP countermeasures wont work on encap offload mode */
+ if (key->conf.cipher == WLAN_CIPHER_SUITE_TKIP)
+ ieee80211_set_hw_80211_encap(&sdata->vif, false);
+
ret = drv_set_key(key->local, SET_KEY, sdata,
sta ? &sta->sta : NULL, &key->conf);
@@ -202,6 +206,9 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
key->conf.keyidx,
sta ? sta->sta.addr : bcast_addr, ret);
+ if (sdata->hw_80211_encap)
+ return -EINVAL;
+
out_unsupported:
switch (key->conf.cipher) {
case WLAN_CIPHER_SUITE_WEP40:
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 29b9d57df1a3..c248f57b7cc7 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -997,7 +997,9 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);
}
- /* mac80211 always supports monitor */
+ /* mac80211 always supports monitor unless we do 802.11
+ * encapsulation offloading.
+ */
hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_MONITOR);
hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_MONITOR);
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index f03aa8924d23..374fb51f1ffd 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -1168,6 +1168,85 @@ void ieee80211_tx_rate_update(struct ieee80211_hw *hw,
}
EXPORT_SYMBOL(ieee80211_tx_rate_update);
+void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct sk_buff *skb)
+{
+ struct ieee80211_local *local = hw_to_local(hw);
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct sta_info *sta;
+ int retry_count;
+ int rates_idx;
+ bool acked;
+
+ if (WARN_ON(!ieee80211_hw_check(hw, SUPPORTS_80211_ENCAP)))
+ goto skip_stats_update;
+
+ sdata = vif_to_sdata(vif);
+
+ acked = info->flags & IEEE80211_TX_STAT_ACK;
+ rates_idx = ieee80211_tx_get_rates(hw, info, &retry_count);
+
+ rcu_read_lock();
+
+ if (ieee80211_lookup_ra_sta(sdata, skb, &sta)) {
+ rcu_read_unlock();
+ goto counters_update;
+ }
+
+ if (!sta || IS_ERR(sta)) {
+ rcu_read_unlock();
+ goto counters_update;
+ }
+
+ if (!acked)
+ sta->status_stats.retry_failed++;
+
+ if (rates_idx != -1)
+ sta->tx_stats.last_rate = info->status.rates[rates_idx];
+
+ sta->status_stats.retry_count += retry_count;
+
+ if (ieee80211_hw_check(hw, REPORTS_TX_ACK_STATUS)) {
+ if (acked && vif->type == NL80211_IFTYPE_STATION)
+ ieee80211_sta_reset_conn_monitor(sdata);
+
+ sta->status_stats.last_ack = jiffies;
+ if (info->flags & IEEE80211_TX_STAT_ACK) {
+ if (sta->status_stats.lost_packets)
+ sta->status_stats.lost_packets = 0;
+
+ if (test_sta_flag(sta, WLAN_STA_TDLS_PEER_AUTH))
+ sta->status_stats.last_tdls_pkt_time = jiffies;
+ } else {
+ ieee80211_lost_packet(sta, info);
+ }
+ }
+
+ rcu_read_unlock();
+
+counters_update:
+ ieee80211_led_tx(local);
+
+ if (!(info->flags & IEEE80211_TX_STAT_ACK) &&
+ !(info->flags & IEEE80211_TX_STAT_NOACK_TRANSMITTED))
+ goto skip_stats_update;
+
+ I802_DEBUG_INC(local->dot11TransmittedFrameCount);
+ if (is_multicast_ether_addr(skb->data))
+ I802_DEBUG_INC(local->dot11MulticastTransmittedFrameCount);
+ if (retry_count > 0)
+ I802_DEBUG_INC(local->dot11RetryCount);
+ if (retry_count > 1)
+ I802_DEBUG_INC(local->dot11MultipleRetryCount);
+
+skip_stats_update:
+ ieee80211_report_used_skb(local, skb, false);
+ dev_kfree_skb(skb);
+}
+EXPORT_SYMBOL(ieee80211_tx_status_8023);
+
void ieee80211_report_low_ack(struct ieee80211_sta *pubsta, u32 num_packets)
{
struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 235c6377a203..30f98066f3ec 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1249,7 +1249,8 @@ static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
(info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE))
return NULL;
- if (unlikely(!ieee80211_is_data_present(hdr->frame_control))) {
+ if (!(info->control.flags & IEEE80211_TX_CTRL_HW_80211_ENCAP) &&
+ unlikely(!ieee80211_is_data_present(hdr->frame_control))) {
if ((!ieee80211_is_mgmt(hdr->frame_control) ||
ieee80211_is_bufferable_mmpdu(hdr->frame_control) ||
vif->type == NL80211_IFTYPE_STATION) &&
@@ -2354,9 +2355,9 @@ static inline bool ieee80211_is_tdls_setup(struct sk_buff *skb)
skb->data[14] == WLAN_TDLS_SNAP_RFTYPE;
}
-static int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
- struct sk_buff *skb,
- struct sta_info **sta_out)
+int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
+ struct sk_buff *skb,
+ struct sta_info **sta_out)
{
struct sta_info *sta;
@@ -2866,7 +2867,8 @@ void ieee80211_check_fast_xmit(struct sta_info *sta)
struct ieee80211_chanctx_conf *chanctx_conf;
__le16 fc;
- if (!ieee80211_hw_check(&local->hw, SUPPORT_FAST_XMIT))
+ if (!ieee80211_hw_check(&local->hw, SUPPORT_FAST_XMIT) ||
+ sdata->hw_80211_encap)
return;
/* Locking here protects both the pointer itself, and against concurrent
@@ -3598,6 +3600,9 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
else
info->flags &= ~IEEE80211_TX_CTL_AMPDU;
+ if (info->control.flags & IEEE80211_TX_CTRL_HW_80211_ENCAP)
+ goto encap_out;
+
if (info->control.flags & IEEE80211_TX_CTRL_FAST_XMIT) {
struct sta_info *sta = container_of(txq->sta, struct sta_info,
sta);
@@ -3657,6 +3662,7 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
break;
}
+encap_out:
IEEE80211_SKB_CB(skb)->control.vif = vif;
return skb;
@@ -4028,6 +4034,167 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
}
+static bool ieee80211_tx_8023(struct ieee80211_sub_if_data *sdata,
+ struct sk_buff *skb, int led_len,
+ struct sta_info *sta,
+ bool txpending)
+{
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_tx_control control = {};
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_sta *pubsta = NULL;
+ unsigned long flags;
+ int q = info->hw_queue;
+
+ if (ieee80211_queue_skb(local, sdata, sta, skb))
+ return true;
+
+ spin_lock_irqsave(&local->queue_stop_reason_lock, flags);
+
+ if (local->queue_stop_reasons[q] ||
+ (!txpending && !skb_queue_empty(&local->pending[q]))) {
+ if (txpending)
+ skb_queue_head(&local->pending[q], skb);
+ else
+ skb_queue_tail(&local->pending[q], skb);
+
+ spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags);
+
+ return false;
+ }
+
+ spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags);
+
+ if (sta && sta->uploaded)
+ pubsta = &sta->sta;
+
+ control.sta = pubsta;
+
+ drv_tx(local, &control, skb);
+
+ return true;
+}
+
+static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,
+ struct net_device *dev, struct sta_info *sta,
+ struct sk_buff *skb)
+{
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ethhdr *ehdr = (struct ethhdr *)skb->data;
+ struct ieee80211_local *local = sdata->local;
+ bool authorized = false;
+ bool multicast;
+ bool tdls_peer;
+ unsigned char *ra = NULL;
+
+ if (IS_ERR(sta) || (sta && !sta->uploaded))
+ sta = NULL;
+
+ if (sdata->vif.type == NL80211_IFTYPE_STATION) {
+ tdls_peer = test_sta_flag(sta, WLAN_STA_TDLS_PEER);
+ if (tdls_peer)
+ ra = skb->data;
+ else
+ ra = sdata->u.mgd.bssid;
+ } else {
+ ra = ehdr->h_dest;
+ }
+
+ if (!ra)
+ goto out_free;
+ multicast = is_multicast_ether_addr(ra);
+
+ if (sta)
+ authorized = test_sta_flag(sta, WLAN_STA_AUTHORIZED);
+
+ if (!multicast && !authorized &&
+ (ehdr->h_proto != sdata->control_port_protocol ||
+ !ether_addr_equal(sdata->vif.addr, ehdr->h_source)))
+ goto out_free;
+
+ if (multicast && sdata->vif.type == NL80211_IFTYPE_AP &&
+ !atomic_read(&sdata->u.ap.num_mcast_sta))
+ goto out_free;
+
+ if (unlikely(test_bit(SCAN_SW_SCANNING, &local->scanning)) &&
+ test_bit(SDATA_STATE_OFFCHANNEL, &sdata->state))
+ goto out_free;
+
+ /* TODO: Handle frames requiring wifi tx status to be notified */
+
+ memset(info, 0, sizeof(*info));
+
+ if (unlikely(sdata->control_port_protocol == ehdr->h_proto)) {
+ if (sdata->control_port_no_encrypt)
+ info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT;
+ info->control.flags |= IEEE80211_TX_CTRL_PORT_CTRL_PROTO;
+ }
+
+ if (multicast)
+ info->flags |= IEEE80211_TX_CTL_NO_ACK;
+
+ info->hw_queue = sdata->vif.hw_queue[skb_get_queue_mapping(skb)];
+
+ ieee80211_tx_stats(dev, skb->len);
+
+ if (sta) {
+ sta->tx_stats.bytes[skb_get_queue_mapping(skb)] += skb->len;
+ sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
+ }
+
+ if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ sdata = container_of(sdata->bss,
+ struct ieee80211_sub_if_data, u.ap);
+
+ info->control.flags |= IEEE80211_TX_CTRL_HW_80211_ENCAP;
+ info->control.vif = &sdata->vif;
+
+ ieee80211_tx_8023(sdata, skb, skb->len, sta, false);
+
+ return;
+
+out_free:
+ kfree_skb(skb);
+}
+
+netdev_tx_t ieee80211_subif_start_xmit_8023(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ struct sta_info *sta;
+
+ if (WARN_ON(!sdata->hw_80211_encap)) {
+ kfree_skb(skb);
+ return NETDEV_TX_OK;
+ }
+
+ if (unlikely(skb->len < ETH_HLEN)) {
+ kfree_skb(skb);
+ return NETDEV_TX_OK;
+ }
+
+ if (WARN_ON(dev->ieee80211_ptr->use_4addr)) {
+ kfree_skb(skb);
+ return NETDEV_TX_OK;
+ }
+
+ rcu_read_lock();
+
+ if (ieee80211_lookup_ra_sta(sdata, skb, &sta))
+ goto out_free;
+
+ ieee80211_8023_xmit(sdata, dev, sta, skb);
+
+ goto out;
+
+out_free:
+ kfree_skb(skb);
+out:
+ rcu_read_unlock();
+
+ return NETDEV_TX_OK;
+}
+
struct sk_buff *
ieee80211_build_data_template(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb, u32 info_flags)
@@ -4106,6 +4273,16 @@ static bool ieee80211_tx_pending_skb(struct ieee80211_local *local,
}
info->band = chanctx_conf->def.chan->band;
result = ieee80211_tx(sdata, NULL, skb, true, 0);
+ } else if (info->control.flags & IEEE80211_TX_CTRL_HW_80211_ENCAP) {
+ if (ieee80211_lookup_ra_sta(sdata, skb, &sta)) {
+ dev_kfree_skb(skb);
+ return true;
+ }
+
+ if (IS_ERR(sta) || (sta && !sta->uploaded))
+ sta = NULL;
+
+ result = ieee80211_tx_8023(sdata, skb, skb->len, sta, true);
} else {
struct sk_buff_head skbs;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 0/2] mmc: core: Fix Marvell WiFi reset by adding SDIO API to replug card
From: Andreas Fenkart @ 2019-07-30 8:46 UTC (permalink / raw)
To: Douglas Anderson
Cc: Ulf Hansson, Kalle Valo, Adrian Hunter, Ganapathi Bhat,
linux-wireless, Brian Norris, Amitkumar Karwar, linux-rockchip,
Wolfram Sang, Nishant Sarmukadam, netdev, Avri Altman, linux-mmc,
David Miller, Xinming Hu, linux-kernel, Thomas Gleixner,
Kate Stewart
In-Reply-To: <20190722193939.125578-1-dianders@chromium.org>
Hi Douglas,
Am Mo., 22. Juli 2019 um 21:41 Uhr schrieb Douglas Anderson
<dianders@chromium.org>:
>
> As talked about in the thread at:
>
> http://lkml.kernel.org/r/CAD=FV=X7P2F1k_zwHc0mbtfk55-rucTz_GoDH=PL6zWqKYcpuw@mail.gmail.com
>
> ...when the Marvell WiFi card tries to reset itself it kills
> Bluetooth. It was observed that we could re-init the card properly by
> unbinding / rebinding the host controller. It was also observed that
> in the downstream Chrome OS codebase the solution used was
> mmc_remove_host() / mmc_add_host(), which is similar to the solution
> in this series.
>
> So far I've only done testing of this series using the reset test
> source that can be simulated via sysfs. Specifically I ran this test:
>
> for i in $(seq 1000); do
> echo "LOOP $i --------"
> echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset
>
> while true; do
> if ! ping -w15 -c1 "${GW}" >/dev/null 2>&1; then
> fail=$(( fail + 1 ))
> echo "Fail WiFi ${fail}"
> if [[ ${fail} == 3 ]]; then
> exit 1
> fi
> else
> fail=0
> break
> fi
> done
>
> hciconfig hci0 down
> sleep 1
> if ! hciconfig hci0 up; then
> echo "Fail BT"
> exit 1
> fi
> done
>
> I ran this several times and got several hundred iterations each
> before a failure. When I saw failures:
>
> * Once I saw a "Fail BT"; manually resetting the card again fixed it.
> I didn't give it time to see if it would have detected this
> automatically.
> * Once I saw the ping fail because (for some reason) my device only
> got an IPv6 address from my router and the IPv4 ping failed. I
> changed my script to use 'ping6' to see if that would help.
> * Once I saw the ping fail because the higher level network stack
> ("shill" in my case) seemed to crash. A few minutes later the
> system recovered itself automatically. https://crbug.com/984593 if
> you want more details.
> * Sometimes while I was testing I saw "Fail WiFi 1" indicating a
> transitory failure. Usually this was an association failure, but in
> one case I saw the device do "Firmware wakeup failed" after I
> triggered the reset. This caused the driver to trigger a re-reset
> of itself which eventually recovered things. This was good because
> it was an actual test of the normal reset flow (not the one
> triggered via sysfs).
This error triggers something. I remember that when I was working on
suspend-to-ram feature, we had problems to wake up the firmware
reliable. I found this patch in one of my old 3.13 tree
the missing bit -- ugly hack to force cmd52 before cmd53.
---
drivers/mmc/host/omap_hsmmc.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fb24a006080f..710d0bdf39e5 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2372,6 +2372,12 @@ static int omap_hsmmc_suspend(struct device *dev)
if (host->flags & HSMMC_SWAKEUP_QUIRK)
disable_irq(host->gpio_sdio_irq);
+ /*
+ * force a polling cycle after resume.
+ * will issue cmd52, not cmd53 straight away
+ */
+ omap_hsmmc_enable_sdio_irq(host->mmc, false);
+
if (host->dbclk)
clk_disable_unprepare(host->dbclk);
>
> Changes in v2:
> - s/routnine/routine (Brian Norris, Matthias Kaehlcke).
> - s/contining/containing (Matthias Kaehlcke).
> - Add Matthias Reviewed-by tag.
> - Removed clear_bit() calls and old comment (Brian Norris).
> - Explicit CC of Andreas Fenkart.
> - Explicit CC of Brian Norris.
> - Add "Fixes" pointing at the commit Brian talked about.
> - Add Brian's Reviewed-by tag.
>
> Douglas Anderson (2):
> mmc: core: Add sdio_trigger_replug() API
> mwifiex: Make use of the new sdio_trigger_replug() API to reset
>
> drivers/mmc/core/core.c | 28 +++++++++++++++++++--
> drivers/mmc/core/sdio_io.c | 20 +++++++++++++++
> drivers/net/wireless/marvell/mwifiex/sdio.c | 16 +-----------
> include/linux/mmc/host.h | 15 ++++++++++-
> include/linux/mmc/sdio_func.h | 2 ++
> 5 files changed, 63 insertions(+), 18 deletions(-)
>
> --
> 2.22.0.657.g960e92d24f-goog
>
^ permalink raw reply related
* Re: ath10k: Fix channel info parsing for non tlv target
From: Kalle Valo @ 2019-07-30 8:42 UTC (permalink / raw)
To: Lukas Redlinger; +Cc: linux-wireless
In-Reply-To: <CAN5HydqLuX=gg-j6kn_nzTTvxgKxdYaB3ZviVH_+ZD694pHJoQ@mail.gmail.com>
Lukas Redlinger <lukas.redlinger@agilox.net> writes:
> My x86_64 system with Arch Linux 5.2.2 and a Compex WLE600VX card is
> filling the log with "ath10k_pci 0000:01:00.0: failed to parse chan
> info event: -71".
>
> WiFi in general works, but wavemon is struggling as some packets seem
> to be incomplete.
> This seems to be the fix: https://patchwork.kernel.org/patch/10844513/
>
> How/when will i get mainline? Can I speed up the process somehow?
Do to various reasons ath10k patches have been queuing up quite a lot,
that's why the delay. I'll try to push this to 5.3.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: Fix channel info parsing for non tlv target
From: Kalle Valo @ 2019-07-30 8:40 UTC (permalink / raw)
To: Rakesh Pillai; +Cc: ath10k, linux-wireless
In-Reply-To: <1552044366-9186-1-git-send-email-pillair@codeaurora.org>
Rakesh Pillai <pillair@codeaurora.org> writes:
> The tlv targets such as WCN3990 send more data in
> the chan info event, which is not sent by the non tlv
> targets. There is a minimum size check in the wmi event for
> non-tlv targets and hence we cannot update the common
> channel info structure.
>
> If the common channel info structure is updated, the
> size check for chan info event for non-tlv targets
> will fail and return -EPROTO and we see the below
> error messages
>
> ath10k_pci 0000:01:00.0: failed to parse chan info event: -71
>
> Add tlv specific channel info structure and restore the
> original size of the common channel info structure to
> mitigate this issue.
>
> Tested HW: WCN3990
> QCA9887
> Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
> 10.2.4-1.0-00037
>
> Fixes: 13104929d2ec ("ath10k: fill the channel survey results for WCN3990 correctly")
> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
I'll queue this v5.3, and also for stable v5.0 and later.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] drivers: net: wireless: rsi: return explicit error values
From: Kalle Valo @ 2019-07-30 8:29 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, amitkarwar, siva8118, linux-wireless, netdev
In-Reply-To: <1564413872-10720-1-git-send-email-info@metux.net>
"Enrico Weigelt, metux IT consult" <info@metux.net> writes:
> From: Enrico Weigelt <info@metux.net>
>
> Explicitly return constants instead of variable (and rely on
> it to be explicitly initialized), if the value is supposed
> to be fixed anyways. Align it with the rest of the driver,
> which does it the same way.
>
> Signed-off-by: Enrico Weigelt <info@metux.net>
> ---
> drivers/net/wireless/rsi/rsi_91x_sdio.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
The prefix should be just "rsi:", I'll fix that.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 5.3] mwifiex: fix 802.11n/WPA detection
From: Kalle Valo @ 2019-07-30 8:08 UTC (permalink / raw)
To: Brian Norris
Cc: Takashi Iwai, Ganapathi Bhat, Nishant Sarmukadam,
Amitkumar Karwar, Xinming Hu, Linux Kernel, linux-wireless,
Guenter Roeck, stable, Johannes Berg
In-Reply-To: <CA+ASDXMEFew2Sg5G1ofKq-0gfOTFEOhZNjfyNJMRzRjv7ZFgXw@mail.gmail.com>
Brian Norris <briannorris@chromium.org> writes:
> On Mon, Jul 29, 2019 at 9:01 AM Takashi Iwai <tiwai@suse.de> wrote:
>> This isn't seen in linux-next yet.
>
> Apparently not.
>
>> Still pending review?
>
> I guess? Probably mostly pending maintainer attention.
Correct, I was offline for few days.
> Also, Johannes already had noticed (and privately messaged me): this
> patch took a while to show up on the linux-wireless Patchwork
> instance. So the first review (from Guenter Roeck) and my extra reply
> noting the -stable regression didn't make it to Patchwork:
>
> https://patchwork.kernel.org/patch/11057585/
>
>> In anyway,
>> Reviewed-by: Takashi Iwai <tiwai@suse.de>
>
> Thanks. Hopefully Kalle can pick it up.
I expect to apply this today.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 5/5] rtw88: add BT co-existence support
From: Stanislaw Gruszka @ 2019-07-30 6:34 UTC (permalink / raw)
To: Tony Chuang
Cc: kvalo@codeaurora.org, linux-wireless@vger.kernel.org,
briannorris@chromium.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D1881C82@RTITMBSVM04.realtek.com.tw>
On Tue, Jul 30, 2019 at 03:13:35AM +0000, Tony Chuang wrote:
> > Those coex response skb buffers are allocated in rtw_pci_rx_isr(),
> > but I do not see where they are freed (seems we do not process
> > them in c2h_work which does dev_kfree_skb()).
>
> You're right, that SKB leaked. Should free them after responded.
> I will send v2 to fix it :)
FWIW maybe would be better to process coex commands entairly in
c2h_work ? Not sure if that would work or really would be better,
just an idea you can consider :-)
Stanislaw
^ permalink raw reply
* RE: [PATCH v2 5/5] rtw88: add BT co-existence support
From: Tony Chuang @ 2019-07-30 3:13 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: kvalo@codeaurora.org, linux-wireless@vger.kernel.org,
briannorris@chromium.org
In-Reply-To: <20190729081211.GB2066@redhat.com>
> Subject: Re: [PATCH v2 5/5] rtw88: add BT co-existence support
>
> On Thu, Jul 25, 2019 at 10:53:31AM +0800, yhchuang@realtek.com wrote:
> > +static struct sk_buff *rtw_coex_info_request(struct rtw_dev *rtwdev,
> > + struct rtw_coex_info_req *req)
> > +{
> > + struct rtw_coex *coex = &rtwdev->coex;
> > + struct sk_buff *skb_resp = NULL;
> > +
> > + mutex_lock(&coex->mutex);
> > +
> > + rtw_fw_query_bt_mp_info(rtwdev, req);
> > +
> > + if (!wait_event_timeout(coex->wait, !skb_queue_empty(&coex->queue),
> > + COEX_REQUEST_TIMEOUT)) {
> > + rtw_err(rtwdev, "coex request time out\n");
> > + goto out;
> > + }
> > +
> > + skb_resp = skb_dequeue(&coex->queue);
> > + if (!skb_resp) {
> > + rtw_err(rtwdev, "failed to get coex info response\n");
> > + goto out;
> > + }
> > +
> > +out:
> > + mutex_unlock(&coex->mutex);
> > + return skb_resp;
> > +}
> > +
> > +static bool rtw_coex_get_bt_scan_type(struct rtw_dev *rtwdev, u8
> *scan_type)
> > +{
> > + struct rtw_coex_info_req req = {0};
> > + struct sk_buff *skb;
> > + u8 *payload;
> > + bool ret = false;
> > +
> > + req.op_code = BT_MP_INFO_OP_SCAN_TYPE;
> > + skb = rtw_coex_info_request(rtwdev, &req);
> > + if (!skb)
> > + goto out;
> > +
> > + payload = get_payload_from_coex_resp(skb);
> > + *scan_type = GET_COEX_RESP_BT_SCAN_TYPE(payload);
> > + ret = true;
> > +
> > +out:
> > + return ret;
> > +}
> > +
> > +static bool rtw_coex_set_lna_constrain_level(struct rtw_dev *rtwdev,
> > + u8 lna_constrain_level)
> > +{
> > + struct rtw_coex_info_req req = {0};
> > + struct sk_buff *skb;
> > + bool ret = false;
> > +
> > + req.op_code = BT_MP_INFO_OP_LNA_CONSTRAINT;
> > + req.para1 = lna_constrain_level;
> > + skb = rtw_coex_info_request(rtwdev, &req);
> > + if (!skb)
> > + goto out;
>
> Those coex response skb buffers are allocated in rtw_pci_rx_isr(),
> but I do not see where they are freed (seems we do not process
> them in c2h_work which does dev_kfree_skb()).
You're right, that SKB leaked. Should free them after responded.
I will send v2 to fix it :)
Thanks.
>
> Stanislaw
Yan-Hsuan
^ permalink raw reply
* RE: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: Tony Chuang @ 2019-07-30 3:11 UTC (permalink / raw)
To: Jian-Hong Pan, David Laight
Cc: Kalle Valo, David S . Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux@endlessm.com, stable@vger.kernel.org
In-Reply-To: <CAPpJ_eey7+KCMFj2YVQD8ziWR_xf-==k9MYb49-32Z5E6vTdHA@mail.gmail.com>
> > > > While allocating all 512 buffers in one block (just over 4MB)
> > > > is probably not a good idea, you may need to allocated (and dma map)
> > > > then in groups.
> > >
> > > Thanks for reviewing. But got questions here to double confirm the
> idea.
> > > According to original code, it allocates 512 skbs for RX ring and dma
> > > mapping one by one. So, the new code allocates memory buffer 512
> > > times to get 512 buffer arrays. Will the 512 buffers arrays be in one
> > > block? Do you mean aggregate the buffers as a scatterlist and use
> > > dma_map_sg?
> >
> > If you malloc a buffer of size (8192+32) the allocator will either
> > round it up to a whole number of (often 4k) pages or to a power of
> > 2 of pages - so either 12k of 16k.
> > I think the Linux allocator does the latter.
> > Some of the allocators also 'steal' a bit from the front of the buffer
> > for 'red tape'.
> >
> > OTOH malloc the space 15 buffers and the allocator will round the
> > 15*(8192 + 32) up to 32*4k - and you waste under 8k across all the
> > buffers.
> >
> > You then dma_map the large buffer and split into the actual rx buffers.
> > Repeat until you've filled the entire ring.
> > The only complication is remembering the base address (and size) for
> > the dma_unmap and free.
> > Although there is plenty of padding to extend the buffer structure
> > significantly without using more memory.
> > Allocate in 15's and you (probably) have 512 bytes per buffer.
> > Allocate in 31's and you have 256 bytes.
> >
> > The problem is that larger allocates are more likely to fail
> > (especially if the system has been running for some time).
> > So you almost certainly want to be able to fall back to smaller
> > allocates even though they use more memory.
> >
> > I also wonder if you actually need 512 8k rx buffers to cover
> > interrupt latency?
> > I've not done any measurements for 20 years!
>
> Thanks for the explanation.
> I am not sure the combination of 512 8k RX buffers. Maybe Realtek
> folks can give us some idea.
> Tony Chuang any comment?
>
> Jian-Hong Pan
>
512 RX buffers is not necessary I think. But I haven't had a chance to
test if reduce the number of RX SKBs could affect the latency.
I can run some throughput tests and then decide a minimum numbers
that RX ring requires. Or if you can try it.
Thanks.
Yan-Hsuan
^ permalink raw reply
* RE: [5.2 regression] rtwpci + amd iommu
From: Tony Chuang @ 2019-07-30 2:46 UTC (permalink / raw)
To: Brian Norris; +Cc: linux-wireless, Ján Veselý
In-Reply-To: <CA+ASDXPcnbiZmZLbRS0VXbof5ED+iqtySD+tr+pTszv6Jru4bg@mail.gmail.com>
> Hi Tony,
>
> Can you please submit that patch upstream soon?
>
> Thanks,
> Brian
>
Sure! I can submit it today.
Yan-Hsuan
^ permalink raw reply
* [PATCH v2] Fix typo reigster to register
From: Pei-Hsuan Hung @ 2019-07-30 2:42 UTC (permalink / raw)
Cc: Pei-Hsuan Hung, trivial, Russell Currey, Sam Bobroff,
Oliver O'Halloran, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Jeremy Kerr, Arnd Bergmann, MyungJoo Ham,
Chanwoo Choi, Liviu Dudau, Brian Starkey, David Airlie,
Daniel Vetter, Ping-Ke Shih, Kalle Valo, David S. Miller,
James Smart, Dick Kennedy, James E.J. Bottomley,
Martin K. Petersen, Alexander Viro, Larry Finger, linuxppc-dev,
linux-kernel, dri-devel, linux-wireless, netdev, linux-scsi,
linux-fsdevel
Signed-off-by: Pei-Hsuan Hung <afcidk@gmail.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Cc: trivial@kernel.org
---
Hi Liviu, thanks for your reply.
This patch is generated by a script so at first I didn't notice there is
also a typo in the word coefficient. I've fixed the typo in this
version.
arch/powerpc/kernel/eeh.c | 2 +-
arch/powerpc/platforms/cell/spufs/switch.c | 4 ++--
drivers/extcon/extcon-rt8973a.c | 2 +-
drivers/gpu/drm/arm/malidp_regs.h | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h | 2 +-
drivers/scsi/lpfc/lpfc_hbadisc.c | 2 +-
fs/userfaultfd.c | 2 +-
7 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index c0e4b73191f3..d75c9c24ec4d 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1030,7 +1030,7 @@ int __init eeh_ops_register(struct eeh_ops *ops)
}
/**
- * eeh_ops_unregister - Unreigster platform dependent EEH operations
+ * eeh_ops_unregister - Unregister platform dependent EEH operations
* @name: name of EEH platform operations
*
* Unregister the platform dependent EEH operation callback
diff --git a/arch/powerpc/platforms/cell/spufs/switch.c b/arch/powerpc/platforms/cell/spufs/switch.c
index 5c3f5d088c3b..9548a086937b 100644
--- a/arch/powerpc/platforms/cell/spufs/switch.c
+++ b/arch/powerpc/platforms/cell/spufs/switch.c
@@ -574,7 +574,7 @@ static inline void save_mfc_rag(struct spu_state *csa, struct spu *spu)
{
/* Save, Step 38:
* Save RA_GROUP_ID register and the
- * RA_ENABLE reigster in the CSA.
+ * RA_ENABLE register in the CSA.
*/
csa->priv1.resource_allocation_groupID_RW =
spu_resource_allocation_groupID_get(spu);
@@ -1227,7 +1227,7 @@ static inline void restore_mfc_rag(struct spu_state *csa, struct spu *spu)
{
/* Restore, Step 29:
* Restore RA_GROUP_ID register and the
- * RA_ENABLE reigster from the CSA.
+ * RA_ENABLE register from the CSA.
*/
spu_resource_allocation_groupID_set(spu,
csa->priv1.resource_allocation_groupID_RW);
diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
index 40c07f4d656e..e75c03792398 100644
--- a/drivers/extcon/extcon-rt8973a.c
+++ b/drivers/extcon/extcon-rt8973a.c
@@ -270,7 +270,7 @@ static int rt8973a_muic_get_cable_type(struct rt8973a_muic_info *info)
}
cable_type = adc & RT8973A_REG_ADC_MASK;
- /* Read Device 1 reigster to identify correct cable type */
+ /* Read Device 1 register to identify correct cable type */
ret = regmap_read(info->regmap, RT8973A_REG_DEV1, &dev1);
if (ret) {
dev_err(info->dev, "failed to read DEV1 register\n");
diff --git a/drivers/gpu/drm/arm/malidp_regs.h b/drivers/gpu/drm/arm/malidp_regs.h
index 993031542fa1..9b4f95d8ccec 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -145,7 +145,7 @@
#define MALIDP_SE_COEFFTAB_DATA_MASK 0x3fff
#define MALIDP_SE_SET_COEFFTAB_DATA(x) \
((x) & MALIDP_SE_COEFFTAB_DATA_MASK)
-/* Enhance coeffents reigster offset */
+/* Enhance coefficients register offset */
#define MALIDP_SE_IMAGE_ENH 0x3C
/* ENH_LIMITS offset 0x0 */
#define MALIDP_SE_ENH_LOW_LEVEL 24
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h
index 99c6f7eefd85..d03c8f12a15c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h
@@ -58,7 +58,7 @@ struct fw_priv {
/* 0x81: PCI-AP, 01:PCIe, 02: 92S-U,
* 0x82: USB-AP, 0x12: 72S-U, 03:SDIO */
u8 hci_sel;
- /* the same value as reigster value */
+ /* the same value as register value */
u8 chip_version;
/* customer ID low byte */
u8 customer_id_0;
diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
index 28ecaa7fc715..42b125602d72 100644
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -6551,7 +6551,7 @@ lpfc_sli4_unregister_fcf(struct lpfc_hba *phba)
* lpfc_unregister_fcf_rescan - Unregister currently registered fcf and rescan
* @phba: Pointer to hba context object.
*
- * This function unregisters the currently reigstered FCF. This function
+ * This function unregisters the currently registered FCF. This function
* also tries to find another FCF for discovery by rescan the HBA FCF table.
*/
void
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index ccbdbd62f0d8..612dc1240f90 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -267,7 +267,7 @@ static inline bool userfaultfd_huge_must_wait(struct userfaultfd_ctx *ctx,
#endif /* CONFIG_HUGETLB_PAGE */
/*
- * Verify the pagetables are still not ok after having reigstered into
+ * Verify the pagetables are still not ok after having registered into
* the fault_pending_wqh to avoid userland having to UFFDIO_WAKE any
* userfault that has already been resolved, if userfaultfd_read and
* UFFDIO_COPY|ZEROPAGE are being run simultaneously on two different
--
2.17.1
^ permalink raw reply related
* [PATCH V2] mac80211: allow setting spatial reuse parameters from bss_conf
From: John Crispin @ 2019-07-29 19:26 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
Store the OBSS PD parameters inside bss_conf when bringing up an AP and/or
when a station connects to an AP. This allows the driver to configure the
HW accordingly.
Signed-off-by: John Crispin <john@phrozen.org>
---
Changes in V2
* fix symbol prefixes
* fix nl policy
include/net/cfg80211.h | 15 ++++++++++++
include/net/mac80211.h | 4 ++++
include/uapi/linux/nl80211.h | 27 ++++++++++++++++++++++
net/mac80211/cfg.c | 5 +++-
net/mac80211/he.c | 24 ++++++++++++++++++++
net/mac80211/ieee80211_i.h | 3 +++
net/mac80211/mlme.c | 1 +
net/wireless/nl80211.c | 44 ++++++++++++++++++++++++++++++++++++
8 files changed, 122 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7269bc681b0a..6fbee944d083 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -246,6 +246,19 @@ struct ieee80211_rate {
u16 hw_value, hw_value_short;
};
+/**
+ * struct ieee80211_he_obss_pd - AP settings for spatial reuse
+ *
+ * @enable: is the feature enabled.
+ * @min_offset: minimal tx power offset an associated station shall use
+ * @max_offset: maximum tx power offset an associated station shall use
+ */
+struct ieee80211_he_obss_pd {
+ bool enable;
+ u8 min_offset;
+ u8 max_offset;
+};
+
/**
* struct ieee80211_sta_ht_cap - STA's HT capabilities
*
@@ -891,6 +904,7 @@ enum cfg80211_ap_settings_flags {
* @vht_required: stations must support VHT
* @twt_responder: Enable Target Wait Time
* @flags: flags, as defined in enum cfg80211_ap_settings_flags
+ * @he_obss_pd: OBSS Packet Detection settings
*/
struct cfg80211_ap_settings {
struct cfg80211_chan_def chandef;
@@ -918,6 +932,7 @@ struct cfg80211_ap_settings {
bool ht_required, vht_required;
bool twt_responder;
u32 flags;
+ struct ieee80211_he_obss_pd he_obss_pd;
};
/**
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d5270a5f3bcc..e2203ffdd591 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -315,6 +315,7 @@ struct ieee80211_vif_chanctx_switch {
* @BSS_CHANGED_FTM_RESPONDER: fime timing reasurement request responder
* functionality changed for this BSS (AP mode).
* @BSS_CHANGED_TWT: TWT status changed
+ * @BSS_CHANGED_HE_OBSS_PD: OBSS Packet Detection status changed.
*
*/
enum ieee80211_bss_change {
@@ -346,6 +347,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_MCAST_RATE = 1<<25,
BSS_CHANGED_FTM_RESPONDER = 1<<26,
BSS_CHANGED_TWT = 1<<27,
+ BSS_CHANGED_HE_OBSS_PD = 1<<28,
/* when adding here, make sure to change ieee80211_reconfig */
};
@@ -601,6 +603,7 @@ struct ieee80211_ftm_responder_params {
* @profile_periodicity: the least number of beacon frames need to be received
* in order to discover all the nontransmitted BSSIDs in the set.
* @he_operation: HE operation information of the AP we are connected to
+ * @he_obss_pd: OBSS Packet Detection parameters.
*/
struct ieee80211_bss_conf {
const u8 *bssid;
@@ -663,6 +666,7 @@ struct ieee80211_bss_conf {
bool ema_ap;
u8 profile_periodicity;
struct ieee80211_he_operation he_operation;
+ struct ieee80211_he_obss_pd he_obss_pd;
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 3c9acc1a11bb..77b6ddb195d8 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2344,6 +2344,9 @@ enum nl80211_commands {
*
* @NL80211_ATTR_TWT_RESPONDER: Enable target wait time responder support.
*
+ * @NL80211_ATTR_HE_OBSS_PD: nested attribute for OBSS Packet Detection
+ * functionality.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2799,6 +2802,8 @@ enum nl80211_attrs {
NL80211_ATTR_TWT_RESPONDER,
+ NL80211_ATTR_HE_OBSS_PD,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -6469,4 +6474,26 @@ enum nl80211_peer_measurement_ftm_resp {
NL80211_PMSR_FTM_RESP_ATTR_MAX = NUM_NL80211_PMSR_FTM_RESP_ATTR - 1
};
+/**
+ * enum nl80211_obss_pd_attributes - OBSS packet detection attributes
+ * @__NL80211_HE_OBSS_PD_ATTR_INVALID: Invalid
+ *
+ * @NL80211_HE_OBSS_PD_ATTR_MIN_OFFSET: the OBSS PD minimum tx power offset.
+ * @NL80211_HE_OBSS_PD_ATTR_MAX_OFFSET: the OBSS PD maximum tx power offset.
+ *
+ * @__NL80211_HE_OBSS_PD_ATTR_LAST: Internal
+ * @NL80211_HE_OBSS_PD_ATTR_MAX: highest OBSS PD attribute.
+ */
+enum nl80211_obss_pd_attributes {
+ __NL80211_HE_OBSS_PD_ATTR_INVALID,
+
+ NL80211_HE_OBSS_PD_ATTR_MIN_OFFSET,
+ NL80211_HE_OBSS_PD_ATTR_MAX_OFFSET,
+
+ /* keep last */
+ __NL80211_HE_OBSS_PD_ATTR_LAST,
+ NL80211_HE_OBSS_PD_ATTR_MAX = __NL80211_HE_OBSS_PD_ATTR_LAST - 1,
+};
+
+
#endif /* __LINUX_NL80211_H */
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index e41e156f92f8..9e8f8137ebcf 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -975,7 +975,8 @@ static int ieee80211_start_ap(struct wiphy *wiphy, struct net_device *dev,
BSS_CHANGED_SSID |
BSS_CHANGED_P2P_PS |
BSS_CHANGED_TXPOWER |
- BSS_CHANGED_TWT;
+ BSS_CHANGED_TWT |
+ BSS_CHANGED_HE_OBSS_PD;
int err;
int prev_beacon_int;
@@ -1046,6 +1047,8 @@ static int ieee80211_start_ap(struct wiphy *wiphy, struct net_device *dev,
sdata->vif.bss_conf.enable_beacon = true;
sdata->vif.bss_conf.allow_p2p_go_ps = sdata->vif.p2p;
sdata->vif.bss_conf.twt_responder = params->twt_responder;
+ memcpy(&sdata->vif.bss_conf.he_obss_pd, ¶ms->he_obss_pd,
+ sizeof(struct ieee80211_he_obss_pd));
sdata->vif.bss_conf.ssid_len = params->ssid_len;
if (params->ssid_len)
diff --git a/net/mac80211/he.c b/net/mac80211/he.c
index 5d3aa9c65fdf..758b83eea4ff 100644
--- a/net/mac80211/he.c
+++ b/net/mac80211/he.c
@@ -64,3 +64,27 @@ ieee80211_he_op_ie_to_bss_conf(struct ieee80211_vif *vif,
}
memcpy(he_operation, he_op_ie_elem, sizeof(*he_operation));
}
+
+void
+ieee80211_he_spr_ie_to_bss_conf(struct ieee80211_vif *vif,
+ const struct ieee80211_he_spr *he_spr_ie_elem)
+{
+ struct ieee80211_he_obss_pd *he_obss_pd =
+ &vif->bss_conf.he_obss_pd;
+ const u8 *data = he_spr_ie_elem->optional;
+
+ memset(he_obss_pd, 0, sizeof(*he_obss_pd));
+
+ if (!he_spr_ie_elem)
+ return;
+
+ if (he_spr_ie_elem->he_sr_control &
+ IEEE80211_HE_SPR_NON_SRG_OFFSET_PRESENT)
+ data++;
+ if (he_spr_ie_elem->he_sr_control &
+ IEEE80211_HE_SPR_SRG_INFORMATION_PRESENT) {
+ he_obss_pd->max_offset = *data++;
+ he_obss_pd->min_offset = *data++;
+ he_obss_pd->enable = true;
+ }
+}
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 08996980c793..d7bf2e6f4c4d 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1873,6 +1873,9 @@ ieee80211_he_cap_ie_to_sta_he_cap(struct ieee80211_sub_if_data *sdata,
struct ieee80211_supported_band *sband,
const u8 *he_cap_ie, u8 he_cap_len,
struct sta_info *sta);
+void
+ieee80211_he_spr_ie_to_bss_conf(struct ieee80211_vif *vif,
+ const struct ieee80211_he_spr *he_spr_ie_elem);
void
ieee80211_he_op_ie_to_bss_conf(struct ieee80211_vif *vif,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0fbb54bde527..498def3164a0 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3381,6 +3381,7 @@ static bool ieee80211_assoc_success(struct ieee80211_sub_if_data *sdata,
bss_conf->uora_ocw_range = elems.uora_element[0];
ieee80211_he_op_ie_to_bss_conf(&sdata->vif, elems.he_operation);
+ ieee80211_he_spr_ie_to_bss_conf(&sdata->vif, elems.he_spr);
/* TODO: OPEN: what happens if BSS color disable is set? */
}
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e48e3120b2f3..1e9abdbe9c8b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -281,6 +281,14 @@ nl80211_pmsr_attr_policy[NL80211_PMSR_ATTR_MAX + 1] = {
NLA_POLICY_NESTED_ARRAY(nl80211_psmr_peer_attr_policy),
};
+static const struct nla_policy
+he_obss_pd_policy[NL80211_HE_OBSS_PD_ATTR_MAX + 1] = {
+ [NL80211_HE_OBSS_PD_ATTR_MIN_OFFSET] =
+ NLA_POLICY_RANGE(NLA_U8, 1, 20),
+ [NL80211_HE_OBSS_PD_ATTR_MAX_OFFSET] =
+ NLA_POLICY_RANGE(NLA_U8, 1, 20),
+};
+
const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_WIPHY] = { .type = NLA_U32 },
[NL80211_ATTR_WIPHY_NAME] = { .type = NLA_NUL_STRING,
@@ -572,6 +580,7 @@ const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
NLA_POLICY_NESTED(nl80211_pmsr_attr_policy),
[NL80211_ATTR_AIRTIME_WEIGHT] = NLA_POLICY_MIN(NLA_U16, 1),
[NL80211_ATTR_TWT_RESPONDER] = { .type = NLA_FLAG },
+ [NL80211_ATTR_HE_OBSS_PD] = NLA_POLICY_NESTED(he_obss_pd_policy),
};
/* policy for the key attributes */
@@ -4359,6 +4368,34 @@ static int nl80211_parse_beacon(struct cfg80211_registered_device *rdev,
return 0;
}
+static int nl80211_parse_he_obss_pd(struct nlattr *attrs,
+ struct ieee80211_he_obss_pd *he_obss_pd)
+{
+ struct nlattr *tb[NL80211_HE_OBSS_PD_ATTR_MAX + 1];
+ int err;
+
+ err = nla_parse_nested(tb, NL80211_HE_OBSS_PD_ATTR_MAX, attrs,
+ he_obss_pd_policy, NULL);
+ if (err)
+ return err;
+
+ if (!tb[NL80211_HE_OBSS_PD_ATTR_MIN_OFFSET] ||
+ !tb[NL80211_HE_OBSS_PD_ATTR_MAX_OFFSET])
+ return -EINVAL;
+
+ he_obss_pd->min_offset =
+ nla_get_u32(tb[NL80211_HE_OBSS_PD_ATTR_MIN_OFFSET]);
+ he_obss_pd->max_offset =
+ nla_get_u32(tb[NL80211_HE_OBSS_PD_ATTR_MAX_OFFSET]);
+
+ if (he_obss_pd->min_offset >= he_obss_pd->max_offset)
+ return -EINVAL;
+
+ he_obss_pd->enable = true;
+
+ return 0;
+}
+
static void nl80211_check_ap_rate_selectors(struct cfg80211_ap_settings *params,
const u8 *rates)
{
@@ -4642,6 +4679,13 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
params.twt_responder =
nla_get_flag(info->attrs[NL80211_ATTR_TWT_RESPONDER]);
+ if (info->attrs[NL80211_ATTR_HE_OBSS_PD]) {
+ err = nl80211_parse_he_obss_pd(info->attrs[NL80211_ATTR_HE_OBSS_PD],
+ ¶ms.he_obss_pd);
+ if (err)
+ return err;
+ }
+
nl80211_calculate_ap_params(¶ms);
if (info->attrs[NL80211_ATTR_EXTERNAL_AUTH_SUPPORT])
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 5.3] mwifiex: fix 802.11n/WPA detection
From: Brian Norris @ 2019-07-29 19:45 UTC (permalink / raw)
To: Takashi Iwai
Cc: Kalle Valo, Ganapathi Bhat, Nishant Sarmukadam, Amitkumar Karwar,
Xinming Hu, Linux Kernel, linux-wireless, Guenter Roeck, stable,
Johannes Berg
In-Reply-To: <s5hv9vkx21i.wl-tiwai@suse.de>
On Mon, Jul 29, 2019 at 9:01 AM Takashi Iwai <tiwai@suse.de> wrote:
> This isn't seen in linux-next yet.
Apparently not.
> Still pending review?
I guess? Probably mostly pending maintainer attention.
Also, Johannes already had noticed (and privately messaged me): this
patch took a while to show up on the linux-wireless Patchwork
instance. So the first review (from Guenter Roeck) and my extra reply
noting the -stable regression didn't make it to Patchwork:
https://patchwork.kernel.org/patch/11057585/
> In anyway,
> Reviewed-by: Takashi Iwai <tiwai@suse.de>
Thanks. Hopefully Kalle can pick it up.
Brian
^ permalink raw reply
* [PATCH v2] wireless-regdb: update regulatory rules for Russia (RU) on 5GHz
From: Dmitry Tunin @ 2019-07-29 19:07 UTC (permalink / raw)
To: Seth Forshee; +Cc: wireless-regdb, linux-wireless, Dmitry Tunin
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 1257 bytes --]
Russian entry is incorrect. According to the last regulations document of Feb 29, 2016,
160 MHz channels and 802.11ad are allowed.
http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
Note that there was never a DFS requirement in Russia, but always was
NO-OUTDOOR on 5GHz.
Maximum power is 200mW that is ~23dBm on all 5GHz channels.
Also Russia has never been regulated by ETSI.
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
---
db.txt | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/db.txt b/db.txt
index 37393e6..d95ed5e 100644
--- a/db.txt
+++ b/db.txt
@@ -1097,14 +1097,12 @@ country RS: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
-country RU: DFS-ETSI
+country RU:
(2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW
- (5650 - 5730 @ 80), (30), DFS
- (5735 - 5835 @ 80), (30)
+ (5170 - 5350 @ 160), (23), NO-OUTDOOR
+ (5650 - 5850 @ 160), (23), NO-OUTDOOR
# 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
- (57000 - 66000 @ 2160), (40)
+ (57000 - 66000 @ 2160), (40), NO-OUTDOOR
country RW: DFS-FCC
(2402 - 2482 @ 40), (20)
--
2.7.4
^ permalink raw reply related
* [PATCH v2] wireless-regdb: update regulatory rules for Russia (RU) on 5GHz
From: Dmitry Tunin @ 2019-07-29 19:01 UTC (permalink / raw)
To: Seth Forshee; +Cc: wireless-regdb, linux-wireless, Dmitry Tunin
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 1363 bytes --]
Russian entry is incorrect. According to the last regulations document of Feb 29, 2016,
160 MHz channels and 802.11ad are allowed.
http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
Note that there was never a DFS requirement in Russia, but always was
NO-OUTDOOR on 5GHz.
Maximum power is 200mW that is ~23dBm on all 5GHz channels.
Also Russia has never been regulated by ETSI.
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
---
db.txt | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/db.txt b/db.txt
index 37393e6..068fb5a 100644
--- a/db.txt
+++ b/db.txt
@@ -1097,14 +1097,12 @@ country RS: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
-country RU: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW
- (5650 - 5730 @ 80), (30), DFS
- (5735 - 5835 @ 80), (30)
- # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
- (57000 - 66000 @ 2160), (40)
+country RU:
+(2402 - 2482 @ 40), (20)
+(5170 - 5350 @ 160), (23), NO-OUTDOOR
+(5650 - 5850 @ 160), (23), NO-OUTDOOR
+# 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
+(57000 - 66000 @ 2160), (40), NO-OUTDOOR
country RW: DFS-FCC
(2402 - 2482 @ 40), (20)
--
2.7.4
^ permalink raw reply related
* Regression with the latest iwlwifi 9260 and Canon Point firmware
From: Peter Robinson @ 2019-07-29 18:49 UTC (permalink / raw)
To: luciano.coelho; +Cc: linux-wireless
Hi Luca,
Similar to the issues seen in the thread on [1] thje 9260 we're seeing
the same reports in Fedora on both versions of the firmware [2], on
both the 9260 series but also the Cannon Point-LP CNVi wifi devices as
well. There's more details and dmesg output in that bug report.
Do you have an update on the issue?
Peter
[1] https://www.spinics.net/lists/linux-wireless/msg188200.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1733369
^ permalink raw reply
* [PATCH] wireless-regdb: update regulatory rules for Russia (RU) on 5GHz
From: Dmitry Tunin @ 2019-07-29 18:42 UTC (permalink / raw)
To: Seth Forshee; +Cc: wireless-regdb, linux-wireless, Dmitry Tunin
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 1363 bytes --]
Russian entry is incorrect. According to the last regulations document of Feb 29, 2016,
160 MHz channels and 802.11ad are allowed.
http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
Note that there was never a DFS requirement in Russia, but always was
NO-OUTDOOR on 5GHz.
Maximum power is 200mW that is ~23dBm on all 5GHz channels.
Also Russia has never been regulated by ETSI.
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
---
db.txt | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/db.txt b/db.txt
index 37393e6..068fb5a 100644
--- a/db.txt
+++ b/db.txt
@@ -1097,14 +1097,12 @@ country RS: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
-country RU: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW
- (5650 - 5730 @ 80), (30), DFS
- (5735 - 5835 @ 80), (30)
- # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
- (57000 - 66000 @ 2160), (40)
+country RU:
+(2402 - 2482 @ 40), (20)
+(5170 - 5350 @ 160), (23), NO-OUTDOOR
+(5650 - 5850 @ 160), (23), NO-OUTDOOR
+# 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
+(57000 - 66000 @ 2160), (40), NO-OUTDOOR
country RW: DFS-FCC
(2402 - 2482 @ 40), (20)
--
2.7.4
^ permalink raw reply related
* Re: wireless-regdb: Update regulatory rules for Russia (RU) on 5GHz
From: Dmitry Tunin @ 2019-07-29 18:33 UTC (permalink / raw)
To: Seth Forshee; +Cc: wireless-regdb, linux-wireless
In-Reply-To: <20190729183009.GD21772@ubuntu-xps13>
It is not easy to find and understand these Russian regulatory docs.
There is also another link with the master doc with both attachments.
http://rfs-rf.ru/grfc/norm_doc/detail/?ID=41839
I'll make a patch.
пн, 29 июл. 2019 г. в 21:30, Seth Forshee <seth.forshee@canonical.com>:
>
> On Mon, Jul 29, 2019 at 09:05:06PM +0300, Dmitry Tunin wrote:
> > I made an error while editing. The correct section is
> >
> > country RU:
> > (2402 - 2482 @ 40), (20)
> > (5170 - 5350 @ 160), (23), NO-OUTDOOR
> > (5650 - 5850 @ 160), (23), NO-OUTDOOR
> > # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> > (57000 - 66000 @ 2160), (40), NO-OUTDOOR
>
> Thanks. I haven't had time to look over the document to verify your
> proposed changes, but I would encourage you to go ahead and send a
> patch. I will try to look this over soon.
>
> Thanks,
> Seth
>
> >
> > вт, 23 июл. 2019 г. в 00:53, Dmitry Tunin <hanipouspilot@gmail.com>:
> > >
> > > The db entry looks like this now
> > >
> > > country RU: DFS-ETSI
> > > (2402 - 2482 @ 40), (20)
> > > (5170 - 5250 @ 80), (20), AUTO-BW
> > > (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> > > (5650 - 5730 @ 80), (30), DFS
> > > (5735 - 5835 @ 80), (30)
> > > # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> > > (57000 - 66000 @ 2160), (40)
> > >
> > >
> > > This doesn't look correct. The regulation document is here
> > > http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
> > >
> > > According to the regulation document issued Feb 29 2016, there
> > > frequencies should look like this:
> > >
> > > country RU:
> > > (2402 - 2482 @ 40), (20)
> > > (5170 - 5330 @ 160), (23), NO-OUTDOOR
> > > (5650 - 5835 @ 160), (23), NO-OUTDOOR
> > > # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> > > (57000 - 66000 @ 2160), (40), NO-OUTDOOR
> > >
> > > Note that there was never a DFS requirement in Russia, but always was
> > > NO-OUTDOOR on 5GHz.
> > > Maximum power is 200mW that is ~23dBm on all 5GHz channels.
> > > Also Russia has never been regulated by ETSI.
> > >
> > > If this looks good, I can send a patch if needed.
^ permalink raw reply
* Re: wireless-regdb: Update regulatory rules for Russia (RU) on 5GHz
From: Seth Forshee @ 2019-07-29 18:30 UTC (permalink / raw)
To: Dmitry Tunin; +Cc: wireless-regdb, linux-wireless
In-Reply-To: <CANoib0Et3gLu2gGYeWracV4v7tgWj8qhtO7w_c8TSJ+CE-gjMg@mail.gmail.com>
On Mon, Jul 29, 2019 at 09:05:06PM +0300, Dmitry Tunin wrote:
> I made an error while editing. The correct section is
>
> country RU:
> (2402 - 2482 @ 40), (20)
> (5170 - 5350 @ 160), (23), NO-OUTDOOR
> (5650 - 5850 @ 160), (23), NO-OUTDOOR
> # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> (57000 - 66000 @ 2160), (40), NO-OUTDOOR
Thanks. I haven't had time to look over the document to verify your
proposed changes, but I would encourage you to go ahead and send a
patch. I will try to look this over soon.
Thanks,
Seth
>
> вт, 23 июл. 2019 г. в 00:53, Dmitry Tunin <hanipouspilot@gmail.com>:
> >
> > The db entry looks like this now
> >
> > country RU: DFS-ETSI
> > (2402 - 2482 @ 40), (20)
> > (5170 - 5250 @ 80), (20), AUTO-BW
> > (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> > (5650 - 5730 @ 80), (30), DFS
> > (5735 - 5835 @ 80), (30)
> > # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> > (57000 - 66000 @ 2160), (40)
> >
> >
> > This doesn't look correct. The regulation document is here
> > http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf
> >
> > According to the regulation document issued Feb 29 2016, there
> > frequencies should look like this:
> >
> > country RU:
> > (2402 - 2482 @ 40), (20)
> > (5170 - 5330 @ 160), (23), NO-OUTDOOR
> > (5650 - 5835 @ 160), (23), NO-OUTDOOR
> > # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order №129_22042015.pdf
> > (57000 - 66000 @ 2160), (40), NO-OUTDOOR
> >
> > Note that there was never a DFS requirement in Russia, but always was
> > NO-OUTDOOR on 5GHz.
> > Maximum power is 200mW that is ~23dBm on all 5GHz channels.
> > Also Russia has never been regulated by ETSI.
> >
> > If this looks good, I can send a patch if needed.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox