[PATCH wireless-next 0/3] wifi: netif_napi_add() conversions

[PATCH wireless-next 0/3] wifi: netif_napi_add() conversions

[Jakub Kicinski]

Convert wifi callers to the new netif_napi_add() APIs.

The callers passing 64 or NAPI_POLL_WEIGHT to the non-Tx flavor
are left alone. I'm planning to include wifi drivers in the massive
tree-wide patch/series which will drop the last argument from
netif_napi_add(). Alternatively I can switch all of wifi to
netif_napi_add_tx_weight() and back after the netif_napi_add()
change makes its wait into wireless-next.
Please LMK if you prefer that.

Jakub Kicinski (3):
  wifi: wil6210: switch to netif_napi_add_tx()
  wifi: mt76: switch to netif_napi_add_tx()
  wifi: qtnfmac: switch to netif_napi_add_weight()

 drivers/net/wireless/ath/wil6210/netdev.c              | 10 ++++------
 drivers/net/wireless/mediatek/mt76/mt7603/dma.c        |  4 ++--
 drivers/net/wireless/mediatek/mt76/mt7615/dma.c        |  4 ++--
 drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c      |  4 ++--
 drivers/net/wireless/mediatek/mt76/mt7915/dma.c        |  4 ++--
 drivers/net/wireless/mediatek/mt76/mt7921/dma.c        |  4 ++--
 .../net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c   |  4 ++--
 .../net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c   |  4 ++--
 8 files changed, 18 insertions(+), 20 deletions(-)

-- 
2.34.1

[PATCH wireless-next 1/3] wifi: wil6210: switch to netif_napi_add_tx()

[Jakub Kicinski]

Switch to the new API not requiring passing in NAPI_POLL_WEIGHT.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: kvalo@kernel.org
CC: linux-wireless@vger.kernel.org
---
 drivers/net/wireless/ath/wil6210/netdev.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/netdev.c b/drivers/net/wireless/ath/wil6210/netdev.c
index 390648066382..87a88f26233e 100644
--- a/drivers/net/wireless/ath/wil6210/netdev.c
+++ b/drivers/net/wireless/ath/wil6210/netdev.c
@@ -458,16 +458,14 @@ int wil_if_add(struct wil6210_priv *wil)
 		netif_napi_add(&wil->napi_ndev, &wil->napi_rx,
 			       wil6210_netdev_poll_rx_edma,
 			       NAPI_POLL_WEIGHT);
-		netif_tx_napi_add(&wil->napi_ndev,
-				  &wil->napi_tx, wil6210_netdev_poll_tx_edma,
-				  NAPI_POLL_WEIGHT);
+		netif_napi_add_tx(&wil->napi_ndev,
+				  &wil->napi_tx, wil6210_netdev_poll_tx_edma);
 	} else {
 		netif_napi_add(&wil->napi_ndev, &wil->napi_rx,
 			       wil6210_netdev_poll_rx,
 			       NAPI_POLL_WEIGHT);
-		netif_tx_napi_add(&wil->napi_ndev,
-				  &wil->napi_tx, wil6210_netdev_poll_tx,
-				  NAPI_POLL_WEIGHT);
+		netif_napi_add_tx(&wil->napi_ndev,
+				  &wil->napi_tx, wil6210_netdev_poll_tx);
 	}
 
 	wil_update_net_queues_bh(wil, vif, NULL, true);
-- 
2.34.1

Re: [wireless-next,1/3] wil6210: switch to netif_napi_add_tx()

[Kalle Valo]

Jakub Kicinski <kuba@kernel.org> wrote:

> Switch to the new API not requiring passing in NAPI_POLL_WEIGHT.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

3 patches applied to wireless-next.git, thanks.

f1c5d4ded782 wil6210: switch to netif_napi_add_tx()
3ed27b602cc3 mt76: switch to netif_napi_add_tx()
193eb523d27c qtnfmac: switch to netif_napi_add_weight()

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20220504163316.549648-2-kuba@kernel.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH wireless-next 2/3] wifi: mt76: switch to netif_napi_add_tx()

[Jakub Kicinski]

Switch to the new API not requiring passing in NAPI_POLL_WEIGHT.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: nbd@nbd.name
CC: lorenzo@kernel.org
CC: ryder.lee@mediatek.com
CC: shayne.chen@mediatek.com
CC: sean.wang@mediatek.com
CC: kvalo@kernel.org
CC: matthias.bgg@gmail.com
CC: Bo.Jiao@mediatek.com
CC: sujuan.chen@mediatek.com
CC: linux-wireless@vger.kernel.org
CC: linux-mediatek@lists.infradead.org
---
 drivers/net/wireless/mediatek/mt76/mt7603/dma.c   | 4 ++--
 drivers/net/wireless/mediatek/mt76/mt7615/dma.c   | 4 ++--
 drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c | 4 ++--
 drivers/net/wireless/mediatek/mt76/mt7915/dma.c   | 4 ++--
 drivers/net/wireless/mediatek/mt76/mt7921/dma.c   | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/dma.c b/drivers/net/wireless/mediatek/mt76/mt7603/dma.c
index 37b092e3ea51..2c1c79dc7fda 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/dma.c
@@ -223,8 +223,8 @@ int mt7603_dma_init(struct mt7603_dev *dev)
 	if (ret)
 		return ret;
 
-	netif_tx_napi_add(&dev->mt76.tx_napi_dev, &dev->mt76.tx_napi,
-			  mt7603_poll_tx, NAPI_POLL_WEIGHT);
+	netif_napi_add_tx(&dev->mt76.tx_napi_dev, &dev->mt76.tx_napi,
+			  mt7603_poll_tx);
 	napi_enable(&dev->mt76.tx_napi);
 
 	return 0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/dma.c b/drivers/net/wireless/mediatek/mt76/mt7615/dma.c
index 00aefea1bf61..95dbb413678a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/dma.c
@@ -284,8 +284,8 @@ int mt7615_dma_init(struct mt7615_dev *dev)
 	if (ret < 0)
 		return ret;
 
-	netif_tx_napi_add(&dev->mt76.tx_napi_dev, &dev->mt76.tx_napi,
-			  mt7615_poll_tx, NAPI_POLL_WEIGHT);
+	netif_napi_add_tx(&dev->mt76.tx_napi_dev, &dev->mt76.tx_napi,
+			  mt7615_poll_tx);
 	napi_enable(&dev->mt76.tx_napi);
 
 	mt76_poll(dev, MT_WPDMA_GLO_CFG,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
index 8bcd8afa0d3a..23d2864d37fb 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
@@ -230,8 +230,8 @@ int mt76x02_dma_init(struct mt76x02_dev *dev)
 	if (ret)
 		return ret;
 
-	netif_tx_napi_add(&dev->mt76.tx_napi_dev, &dev->mt76.tx_napi,
-			  mt76x02_poll_tx, NAPI_POLL_WEIGHT);
+	netif_napi_add_tx(&dev->mt76.tx_napi_dev, &dev->mt76.tx_napi,
+			  mt76x02_poll_tx);
 	napi_enable(&dev->mt76.tx_napi);
 
 	return 0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/dma.c b/drivers/net/wireless/mediatek/mt76/mt7915/dma.c
index 49b4d8ade16b..75678aabff32 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/dma.c
@@ -434,8 +434,8 @@ int mt7915_dma_init(struct mt7915_dev *dev)
 	if (ret < 0)
 		return ret;
 
-	netif_tx_napi_add(&dev->mt76.tx_napi_dev, &dev->mt76.tx_napi,
-			  mt7915_poll_tx, NAPI_POLL_WEIGHT);
+	netif_napi_add_tx(&dev->mt76.tx_napi_dev, &dev->mt76.tx_napi,
+			  mt7915_poll_tx);
 	napi_enable(&dev->mt76.tx_napi);
 
 	mt7915_dma_enable(dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/dma.c b/drivers/net/wireless/mediatek/mt76/mt7921/dma.c
index ca7e20fb5fc0..34b3effe14f3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/dma.c
@@ -296,8 +296,8 @@ int mt7921_dma_init(struct mt7921_dev *dev)
 	if (ret < 0)
 		return ret;
 
-	netif_tx_napi_add(&dev->mt76.tx_napi_dev, &dev->mt76.tx_napi,
-			  mt7921_poll_tx, NAPI_POLL_WEIGHT);
+	netif_napi_add_tx(&dev->mt76.tx_napi_dev, &dev->mt76.tx_napi,
+			  mt7921_poll_tx);
 	napi_enable(&dev->mt76.tx_napi);
 
 	return mt7921_dma_enable(dev);
-- 
2.34.1

Re: [PATCH wireless-next 2/3] wifi: mt76: switch to netif_napi_add_tx()

[Kalle Valo]

Jakub Kicinski <kuba@kernel.org> writes:

> Switch to the new API not requiring passing in NAPI_POLL_WEIGHT.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Felix, I'll assign this to me on patchwork and apply directly to
wireless-next.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH wireless-next 3/3] wifi: qtnfmac: switch to netif_napi_add_weight()

[Jakub Kicinski]

qtnfmac chooses its own magic NAPI weight so switch to the new
API created for those who don't use NAPI_POLL_WEIGHT.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: imitsyanko@quantenna.com
CC: geomatsi@gmail.com
CC: kvalo@kernel.org
CC: linux-wireless@vger.kernel.org
---
 drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c | 4 ++--
 drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c
index 840728ed57b2..8c23a77d1671 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c
@@ -1146,8 +1146,8 @@ static int qtnf_pcie_pearl_probe(struct qtnf_bus *bus, unsigned int tx_bd_size,
 	}
 
 	tasklet_setup(&ps->base.reclaim_tq, qtnf_pearl_reclaim_tasklet_fn);
-	netif_napi_add(&bus->mux_dev, &bus->mux_napi,
-		       qtnf_pcie_pearl_rx_poll, 10);
+	netif_napi_add_weight(&bus->mux_dev, &bus->mux_napi,
+			      qtnf_pcie_pearl_rx_poll, 10);
 
 	ipc_int.fn = qtnf_pcie_pearl_ipc_gen_ep_int;
 	ipc_int.arg = ps;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c
index 9534e1b33780..d83362578374 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c
@@ -1159,8 +1159,8 @@ static int qtnf_pcie_topaz_probe(struct qtnf_bus *bus,
 	}
 
 	tasklet_setup(&ts->base.reclaim_tq, qtnf_reclaim_tasklet_fn);
-	netif_napi_add(&bus->mux_dev, &bus->mux_napi,
-		       qtnf_topaz_rx_poll, 10);
+	netif_napi_add_weight(&bus->mux_dev, &bus->mux_napi,
+			      qtnf_topaz_rx_poll, 10);
 
 	ipc_int.fn = qtnf_topaz_ipc_gen_ep_int;
 	ipc_int.arg = ts;
-- 
2.34.1

Re: [PATCH wireless-next 0/3] wifi: netif_napi_add() conversions

[Kalle Valo]

Jakub Kicinski <kuba@kernel.org> writes:

> Convert wifi callers to the new netif_napi_add() APIs.
>
> The callers passing 64 or NAPI_POLL_WEIGHT to the non-Tx flavor
> are left alone. I'm planning to include wifi drivers in the massive
> tree-wide patch/series which will drop the last argument from
> netif_napi_add(). Alternatively I can switch all of wifi to
> netif_napi_add_tx_weight() and back after the netif_napi_add()
> change makes its wait into wireless-next.
> Please LMK if you prefer that.
>
> Jakub Kicinski (3):
>   wifi: wil6210: switch to netif_napi_add_tx()
>   wifi: mt76: switch to netif_napi_add_tx()
>   wifi: qtnfmac: switch to netif_napi_add_weight()

We don't use that "wifi:" prefix, otherwise looks good. Feel free to
take via your tree:

Acked-by: Kalle Valo <kvalo@kernel.org>

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH wireless-next 0/3] wifi: netif_napi_add() conversions

[Jakub Kicinski]

On Thu, 05 May 2022 07:25:03 +0300 Kalle Valo wrote:
> Jakub Kicinski <kuba@kernel.org> writes:
> 
> > Convert wifi callers to the new netif_napi_add() APIs.
> >
> > The callers passing 64 or NAPI_POLL_WEIGHT to the non-Tx flavor
> > are left alone. I'm planning to include wifi drivers in the massive
> > tree-wide patch/series which will drop the last argument from
> > netif_napi_add(). Alternatively I can switch all of wifi to
> > netif_napi_add_tx_weight() and back after the netif_napi_add()
> > change makes its wait into wireless-next.
> > Please LMK if you prefer that.
> >
> > Jakub Kicinski (3):
> >   wifi: wil6210: switch to netif_napi_add_tx()
> >   wifi: mt76: switch to netif_napi_add_tx()
> >   wifi: qtnfmac: switch to netif_napi_add_weight()  
> 
> We don't use that "wifi:" prefix, otherwise looks good. 

I know, my silent effort to make git log --oneline be more
understandable for folks outside of networking is not really
being met with much applause :) Ethernet people also don't
like the "eth:" prefix..

AFAICS drivers tend to use a format consisting of (numbers at 
the top denoting commonality):

3    4       1       2
net: vendor: driver: component: bla bla

Driver name is the most common prefix. It is the most meaningful
and natural for people working on the code. Not everyone is working 
on the driver code, tho.

1) When I send PRs to Linus I always wonder how much he can 
make out of the shortlog. And if people throw "net:" into the mix
whether it's still clear when something is "just" a driver bug vs
a core bug affecting everyone. So I started using "eth: " for ethernet
drivers, and "wifi: " for wireless drivers in the text of the PRs.

2) For people doing backporting the driver names may not be meaningful,
but if I'm doing backports for a datacenter kernel I know to pay
attention to "eth:" while "wifi:" I can safely skip.

3) The case of this set - I have conversions for the entire tree queued
up on a branch, it's quite useful for me to use a common area-specific
prefix to see what goes were.

Anyway, that's just me rambling. I hope you don't mind if I send things
with a wifi prefix from time to time given it's a convenient way for me
to mark the queued patches.

> Feel free to take via your tree:
> 
> Acked-by: Kalle Valo <kvalo@kernel.org>

Actually I didn't cc netdev so would be easier if you could take them :)
I have to wait for RDMA/infiniband to get merged up before I can start
deleting stuff anyway :(

Re: [PATCH wireless-next 0/3] wifi: netif_napi_add() conversions

[Kalle Valo]

Jakub Kicinski <kuba@kernel.org> writes:

>> Feel free to take via your tree:
>> 
>> Acked-by: Kalle Valo <kvalo@kernel.org>
>
> Actually I didn't cc netdev so would be easier if you could take them :)
> I have to wait for RDMA/infiniband to get merged up before I can start
> deleting stuff anyway :(

Ah sorry, I misunderstood. Then I'll take these to wireless-next.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH wireless-next 0/3] wifi: netif_napi_add() conversions

[Kalle Valo]

Jakub Kicinski <kuba@kernel.org> writes:

> On Thu, 05 May 2022 07:25:03 +0300 Kalle Valo wrote:
>> Jakub Kicinski <kuba@kernel.org> writes:
>> 
>> > Convert wifi callers to the new netif_napi_add() APIs.
>> >
>> > The callers passing 64 or NAPI_POLL_WEIGHT to the non-Tx flavor
>> > are left alone. I'm planning to include wifi drivers in the massive
>> > tree-wide patch/series which will drop the last argument from
>> > netif_napi_add(). Alternatively I can switch all of wifi to
>> > netif_napi_add_tx_weight() and back after the netif_napi_add()
>> > change makes its wait into wireless-next.
>> > Please LMK if you prefer that.
>> >
>> > Jakub Kicinski (3):
>> >   wifi: wil6210: switch to netif_napi_add_tx()
>> >   wifi: mt76: switch to netif_napi_add_tx()
>> >   wifi: qtnfmac: switch to netif_napi_add_weight()  
>> 
>> We don't use that "wifi:" prefix, otherwise looks good. 
>
> I know, my silent effort to make git log --oneline be more
> understandable for folks outside of networking is not really
> being met with much applause :) Ethernet people also don't
> like the "eth:" prefix..
>
> AFAICS drivers tend to use a format consisting of (numbers at 
> the top denoting commonality):
>
> 3    4       1       2
> net: vendor: driver: component: bla bla

To me that's almost like the full path. An example from wireless
drivers:

drivers/net/wireless/ath/ath11k/mac.c

net: wireless: ath: ath11k: mac: blah blah

Only the directory name "drivers" is missing from the path.

Wouldn't it be easier to modify the tools showing logs (like git log or
gitk) to add that to each commit, then people who want to see that can
enable the feature :)

> Driver name is the most common prefix. It is the most meaningful
> and natural for people working on the code. Not everyone is working 
> on the driver code, tho.

Sure, I understand that not everyone are developers. It's always a
balance.

> 1) When I send PRs to Linus I always wonder how much he can 
> make out of the shortlog. And if people throw "net:" into the mix
> whether it's still clear when something is "just" a driver bug vs
> a core bug affecting everyone. So I started using "eth: " for ethernet
> drivers, and "wifi: " for wireless drivers in the text of the PRs.
>
> 2) For people doing backporting the driver names may not be meaningful,
> but if I'm doing backports for a datacenter kernel I know to pay
> attention to "eth:" while "wifi:" I can safely skip.

Is there a specific reason why you use "wifi:" and not "wireless:"? I
admit the term wireless is not great for our 802.11 subsystem but that
has been used as long as I know.

> 3) The case of this set - I have conversions for the entire tree queued
> up on a branch, it's quite useful for me to use a common area-specific
> prefix to see what goes were.
>
> Anyway, that's just me rambling. I hope you don't mind if I send things
> with a wifi prefix from time to time given it's a convenient way for me
> to mark the queued patches.

I don't mind if you submit with "wifi:", it's easy to edit patches with
my patchwork script during commit :) And if there's a strong need I
think we can change our title scheme in wireless patches. This has come
before but I have always resisted due to extra work involved. To me most
important is consistency within wireless subsystem, if different
wireless drivers (and stack) use a different scheme when the logs will
become hard to read. So I would hope everyone can agree to the new
scheme.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH wireless-next 0/3] wifi: netif_napi_add() conversions

[Jakub Kicinski]

On Mon, 09 May 2022 14:14:02 +0300 Kalle Valo wrote:
> > 1) When I send PRs to Linus I always wonder how much he can 
> > make out of the shortlog. And if people throw "net:" into the mix
> > whether it's still clear when something is "just" a driver bug vs
> > a core bug affecting everyone. So I started using "eth: " for ethernet
> > drivers, and "wifi: " for wireless drivers in the text of the PRs.
> >
> > 2) For people doing backporting the driver names may not be meaningful,
> > but if I'm doing backports for a datacenter kernel I know to pay
> > attention to "eth:" while "wifi:" I can safely skip.  
> 
> Is there a specific reason why you use "wifi:" and not "wireless:"? I
> admit the term wireless is not great for our 802.11 subsystem but that
> has been used as long as I know.

Right, I take the liberty of using wifi in PR texts since it seems most
appropriate as none of the low range or WWAN drivers go via the
wireless tree.

> > 3) The case of this set - I have conversions for the entire tree queued
> > up on a branch, it's quite useful for me to use a common area-specific
> > prefix to see what goes were.
> >
> > Anyway, that's just me rambling. I hope you don't mind if I send things
> > with a wifi prefix from time to time given it's a convenient way for me
> > to mark the queued patches.  
> 
> I don't mind if you submit with "wifi:", it's easy to edit patches with
> my patchwork script during commit :) And if there's a strong need I
> think we can change our title scheme in wireless patches. This has come
> before but I have always resisted due to extra work involved. To me most
> important is consistency within wireless subsystem, if different
> wireless drivers (and stack) use a different scheme when the logs will
> become hard to read. So I would hope everyone can agree to the new
> scheme.

No need to change the scheme overall. What you use now is the most
prevalent in the tree so I'm probably overthinking.