| Message ID | 20170918122950.32612-2-sergey.matyukevich.os@quantenna.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 20da2ec06bfad2d4dfd40d77d3831f5e56365d20 |
| Delegated to: | Kalle Valo |
| Headers | show |
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> wrote: > Fix tx path regression. Lock should be held when queuing packets > to h/w fifos in order to properly handle configurations with > multiple enabled interfaces. > > Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> 2 patches applied to wireless-drivers.git, thanks. 20da2ec06bfa qtnfmac: lock access to h/w in tx path a715b3a0efe7 qtnfmac: cancel scans on wireless interface changes
Hello Kalle, > > Fix tx path regression. Lock should be held when queuing packets > > to h/w fifos in order to properly handle configurations with > > multiple enabled interfaces. > > > > Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> > > 2 patches applied to wireless-drivers.git, thanks. > > 20da2ec06bfa qtnfmac: lock access to h/w in tx path > a715b3a0efe7 qtnfmac: cancel scans on wireless interface changes Could you please clarify a couple of points regarding wireless-drivers-next and wireless-drivers trees. I checked development process article at wireless.wiki.kernel.org, but it looks a bit outdated. So am I correct assuming the following: - these two fixes were applied to wireless-drivers because I asked to to queue them to 4.14 - these two fixes will show up in wireless-drivers-next at some point in the future after you move wireless-drivers-next forward, rebasing it on top of one of the upcoming "-rc" Regards, Sergey
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> writes: > Hello Kalle, > >> > Fix tx path regression. Lock should be held when queuing packets >> > to h/w fifos in order to properly handle configurations with >> > multiple enabled interfaces. >> > >> > Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> >> >> 2 patches applied to wireless-drivers.git, thanks. >> >> 20da2ec06bfa qtnfmac: lock access to h/w in tx path >> a715b3a0efe7 qtnfmac: cancel scans on wireless interface changes > > Could you please clarify a couple of points regarding wireless-drivers-next > and wireless-drivers trees. I checked development process article at > wireless.wiki.kernel.org, but it looks a bit outdated. You mean this page: https://wireless.wiki.kernel.org/en/developers/process Yeah, that is outdated :) > So am I correct assuming the following: - these two fixes were applied > to wireless-drivers because I asked to to queue them to 4.14 Correct. > - these two fixes will show up in wireless-drivers-next at some point > in the future after you move wireless-drivers-next forward, rebasing > it on top of one of the upcoming "-rc" I would not use the term "rebase" here, as that means rewriting the history which should be avoided on public trees. What I usually do is to "merge" (git pull) or "fast forward" (git pull --ff-only). You are correct that eventually commits from wireless-drivers trickle down to wireless-drivers-next, I guess usually it takes something like 2-4 weeks. Most of them time they trickle down when Dave merges net to net-next and I fast forward wireless-drivers-next to latest net-next (after Dave has pulled from me). But occasionally I also merge wireless-drivers to wireless-drivers-next myself, for example I did that last cycle as there were major conflicts on iwlwifi and we wanted to fix those early on. The earlier the conflicts are resolved the smoother it is for everyone. So if you have needs for getting the commits from wireless-drivers to wireless-drivers-next please let me know and let's see what's the best way forward. Did this help?
> > - these two fixes will show up in wireless-drivers-next at some point > > in the future after you move wireless-drivers-next forward, rebasing > > it on top of one of the upcoming "-rc" > > I would not use the term "rebase" here, as that means rewriting the > history which should be avoided on public trees. What I usually do is to > "merge" (git pull) or "fast forward" (git pull --ff-only). > > You are correct that eventually commits from wireless-drivers trickle > down to wireless-drivers-next, I guess usually it takes something like > 2-4 weeks. Most of them time they trickle down when Dave merges net to > net-next and I fast forward wireless-drivers-next to latest net-next > (after Dave has pulled from me). But occasionally I also merge > wireless-drivers to wireless-drivers-next myself, for example I did that > last cycle as there were major conflicts on iwlwifi and we wanted to fix > those early on. The earlier the conflicts are resolved the smoother it > is for everyone. Understood. > So if you have needs for getting the commits from wireless-drivers to > wireless-drivers-next please let me know and let's see what's the best > way forward. Ok, good to know. But not this time, of course. We are keeping a bunch of upcoming features and fixes in our internal tree on top of wireless-drivers-next. So two more small patches for two more weeks don't make any difference. > Did this help? Sure, thanks a lot for explanation! Regards, Sergey
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c index 502e72b7cdcc..69131965a298 100644 --- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c +++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c @@ -661,14 +661,18 @@ static int qtnf_pcie_data_tx(struct qtnf_bus *bus, struct sk_buff *skb) struct qtnf_pcie_bus_priv *priv = (void *)get_bus_priv(bus); dma_addr_t txbd_paddr, skb_paddr; struct qtnf_tx_bd *txbd; + unsigned long flags; int len, i; u32 info; int ret = 0; + spin_lock_irqsave(&priv->tx0_lock, flags); + if (!qtnf_tx_queue_ready(priv)) { if (skb->dev) netif_stop_queue(skb->dev); + spin_unlock_irqrestore(&priv->tx0_lock, flags); return NETDEV_TX_BUSY; } @@ -717,8 +721,10 @@ static int qtnf_pcie_data_tx(struct qtnf_bus *bus, struct sk_buff *skb) dev_kfree_skb_any(skb); } - qtnf_pcie_data_tx_reclaim(priv); priv->tx_done_count++; + spin_unlock_irqrestore(&priv->tx0_lock, flags); + + qtnf_pcie_data_tx_reclaim(priv); return NETDEV_TX_OK; } @@ -1247,6 +1253,7 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const struct pci_device_id *id) strcpy(bus->fwname, QTN_PCI_PEARL_FW_NAME); init_completion(&bus->request_firmware_complete); mutex_init(&bus->bus_lock); + spin_lock_init(&pcie_priv->tx0_lock); spin_lock_init(&pcie_priv->irq_lock); spin_lock_init(&pcie_priv->tx_reclaim_lock); diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h index e76a23716ee0..86ac1ccedb52 100644 --- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h +++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h @@ -34,6 +34,8 @@ struct qtnf_pcie_bus_priv { /* lock for tx reclaim operations */ spinlock_t tx_reclaim_lock; + /* lock for tx0 operations */ + spinlock_t tx0_lock; u8 msi_enabled; int mps;
Fix tx path regression. Lock should be held when queuing packets to h/w fifos in order to properly handle configurations with multiple enabled interfaces. Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> --- drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 9 ++++++++- drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h | 2 ++ 2 files changed, 10 insertions(+), 1 deletion(-)