Embedding net_device into structures prohibits the usage of flexible
arrays in the net_device structure. For more details, see the discussion
at [1].
Un-embed the net_device from the private struct by converting it
into a pointer. Then use the leverage the new alloc_netdev_dummy()
helper to allocate and initialize dummy devices.
[1] https://lore.kernel.org/all/[email protected]/
Signed-off-by: Breno Leitao <[email protected]>
---
drivers/net/wireless/realtek/rtw89/core.c | 11 ++++++++---
drivers/net/wireless/realtek/rtw89/core.h | 4 ++--
drivers/net/wireless/realtek/rtw89/pci.c | 6 +++++-
3 files changed, 15 insertions(+), 6 deletions(-)
PS: This is compile-tested only due to lack of hardware.
diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
index d474b8d5df3d..ade3e2a953a1 100644
--- a/drivers/net/wireless/realtek/rtw89/core.c
+++ b/drivers/net/wireless/realtek/rtw89/core.c
@@ -2485,11 +2485,15 @@ void rtw89_core_napi_stop(struct rtw89_dev *rtwdev)
}
EXPORT_SYMBOL(rtw89_core_napi_stop);
-void rtw89_core_napi_init(struct rtw89_dev *rtwdev)
+int rtw89_core_napi_init(struct rtw89_dev *rtwdev)
{
- init_dummy_netdev(&rtwdev->netdev);
- netif_napi_add(&rtwdev->netdev, &rtwdev->napi,
+ rtwdev->netdev = alloc_netdev_dummy(0);
+ if (!rtwdev->netdev)
+ return -ENOMEM;
+
+ netif_napi_add(rtwdev->netdev, &rtwdev->napi,
rtwdev->hci.ops->napi_poll);
+ return 0;
}
EXPORT_SYMBOL(rtw89_core_napi_init);
@@ -2497,6 +2501,7 @@ void rtw89_core_napi_deinit(struct rtw89_dev *rtwdev)
{
rtw89_core_napi_stop(rtwdev);
netif_napi_del(&rtwdev->napi);
+ free_netdev(rtwdev->netdev);
}
EXPORT_SYMBOL(rtw89_core_napi_deinit);
diff --git a/drivers/net/wireless/realtek/rtw89/core.h b/drivers/net/wireless/realtek/rtw89/core.h
index fc1ed8612cf1..e206a2186747 100644
--- a/drivers/net/wireless/realtek/rtw89/core.h
+++ b/drivers/net/wireless/realtek/rtw89/core.h
@@ -5239,7 +5239,7 @@ struct rtw89_dev {
struct rtw89_wow_param wow;
/* napi structure */
- struct net_device netdev;
+ struct net_device *netdev;
struct napi_struct napi;
int napi_budget_countdown;
@@ -6211,7 +6211,7 @@ void rtw89_core_query_rxdesc_v2(struct rtw89_dev *rtwdev,
u8 *data, u32 data_offset);
void rtw89_core_napi_start(struct rtw89_dev *rtwdev);
void rtw89_core_napi_stop(struct rtw89_dev *rtwdev);
-void rtw89_core_napi_init(struct rtw89_dev *rtwdev);
+int rtw89_core_napi_init(struct rtw89_dev *rtwdev);
void rtw89_core_napi_deinit(struct rtw89_dev *rtwdev);
int rtw89_core_sta_add(struct rtw89_dev *rtwdev,
struct ieee80211_vif *vif,
diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c
index 19001130ad94..ef41c3a83b4a 100644
--- a/drivers/net/wireless/realtek/rtw89/pci.c
+++ b/drivers/net/wireless/realtek/rtw89/pci.c
@@ -4201,7 +4201,11 @@ int rtw89_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
rtw89_pci_link_cfg(rtwdev);
rtw89_pci_l1ss_cfg(rtwdev);
- rtw89_core_napi_init(rtwdev);
+ ret = rtw89_core_napi_init(rtwdev);
+ if (ret) {
+ rtw89_err(rtwdev, "failed to init napi\n");
+ goto err_clear_resource;
+ }
ret = rtw89_pci_request_irq(rtwdev, pdev);
if (ret) {
--
2.43.0
Breno Leitao <[email protected]> wrote:
> Embedding net_device into structures prohibits the usage of flexible
> arrays in the net_device structure. For more details, see the discussion
> at [1].
>
> Un-embed the net_device from the private struct by converting it
> into a pointer. Then use the leverage the new alloc_netdev_dummy()
> helper to allocate and initialize dummy devices.
>
> [1] https://lore.kernel.org/all/[email protected]/
>
> Signed-off-by: Breno Leitao <[email protected]>
I think this patch should go via net-next tree, because wireless-next tree
doesn't have patch of dummy devices yet.
Acked-by: Ping-Ke Shih <[email protected]>
> ---
> drivers/net/wireless/realtek/rtw89/core.c | 11 ++++++++---
> drivers/net/wireless/realtek/rtw89/core.h | 4 ++--
> drivers/net/wireless/realtek/rtw89/pci.c | 6 +++++-
> 3 files changed, 15 insertions(+), 6 deletions(-)
>
> PS: This is compile-tested only due to lack of hardware.
I picked this patch to local net-next tree, and tested on RTL8852BE, RTL8852C
and RTL8922AE.
Tested-by: Ping-Ke Shih <[email protected]>
Ping-Ke Shih <[email protected]> writes:
> Breno Leitao <[email protected]> wrote:
>> Embedding net_device into structures prohibits the usage of flexible
>> arrays in the net_device structure. For more details, see the discussion
>> at [1].
>>
>> Un-embed the net_device from the private struct by converting it
>> into a pointer. Then use the leverage the new alloc_netdev_dummy()
>> helper to allocate and initialize dummy devices.
>>
>> [1] https://lore.kernel.org/all/[email protected]/
>>
>> Signed-off-by: Breno Leitao <[email protected]>
>
> I think this patch should go via net-next tree, because wireless-next tree
> doesn't have patch of dummy devices yet.
>
> Acked-by: Ping-Ke Shih <[email protected]>
FWIW I sent the wireless-next pull request yesterday and once it pulled
we will fast forward wireless-next to latest net-next.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Kalle Valo <[email protected]> writes:
> Ping-Ke Shih <[email protected]> writes:
>
>> Breno Leitao <[email protected]> wrote:
>>> Embedding net_device into structures prohibits the usage of flexible
>>> arrays in the net_device structure. For more details, see the discussion
>>> at [1].
>>>
>>> Un-embed the net_device from the private struct by converting it
>>> into a pointer. Then use the leverage the new alloc_netdev_dummy()
>>> helper to allocate and initialize dummy devices.
>>>
>>> [1] https://lore.kernel.org/all/[email protected]/
>>>
>>> Signed-off-by: Breno Leitao <[email protected]>
>>
>> I think this patch should go via net-next tree, because wireless-next tree
>> doesn't have patch of dummy devices yet.
>>
>> Acked-by: Ping-Ke Shih <[email protected]>
>
> FWIW I sent the wireless-next pull request yesterday and once it pulled
> we will fast forward wireless-next to latest net-next.
Oh, I just realised that this is not CCed to netdev so their patchwork
won't even see the patch. Ping, I recommend that you wait for the
dependency commits to trickle down to your tree and then apply the
patch. That's the simplest approach and no need to resend anything.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Kalle Valo <[email protected]> wrote:
> Kalle Valo <[email protected]> writes:
>
> > Ping-Ke Shih <[email protected]> writes:
> >
> >> Breno Leitao <[email protected]> wrote:
> >>> Embedding net_device into structures prohibits the usage of flexible
> >>> arrays in the net_device structure. For more details, see the discussion
> >>> at [1].
> >>>
> >>> Un-embed the net_device from the private struct by converting it
> >>> into a pointer. Then use the leverage the new alloc_netdev_dummy()
> >>> helper to allocate and initialize dummy devices.
> >>>
> >>> [1] https://lore.kernel.org/all/[email protected]/
> >>>
> >>> Signed-off-by: Breno Leitao <[email protected]>
> >>
> >> I think this patch should go via net-next tree, because wireless-next tree
> >> doesn't have patch of dummy devices yet.
> >>
> >> Acked-by: Ping-Ke Shih <[email protected]>
> >
> > FWIW I sent the wireless-next pull request yesterday and once it pulled
> > we will fast forward wireless-next to latest net-next.
>
> Oh, I just realised that this is not CCed to netdev so their patchwork
> won't even see the patch. Ping, I recommend that you wait for the
> dependency commits to trickle down to your tree and then apply the
> patch. That's the simplest approach and no need to resend anything.
Okay. If we don't hurry to get this patch merged, I will apply this patch
to my tree.
Breno Leitao <[email protected]> wrote:
> Embedding net_device into structures prohibits the usage of flexible
> arrays in the net_device structure. For more details, see the discussion
> at [1].
>
> Un-embed the net_device from the private struct by converting it
> into a pointer. Then use the leverage the new alloc_netdev_dummy()
> helper to allocate and initialize dummy devices.
>
> [1] https://lore.kernel.org/all/[email protected]/
>
> Signed-off-by: Breno Leitao <[email protected]>
> Acked-by: Ping-Ke Shih <[email protected]>
> Tested-by: Ping-Ke Shih <[email protected]>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
4c9aa94a39e6 wifi: rtw89: Un-embed dummy device
---
https://github.com/pkshih/rtw.git
On Thu, Apr 25, 2024 at 06:15:21AM +0000, Ping-Ke Shih wrote:
> Kalle Valo <[email protected]> wrote:
> > Kalle Valo <[email protected]> writes:
> >
> > > Ping-Ke Shih <[email protected]> writes:
> > >
> > >> Breno Leitao <[email protected]> wrote:
> > >>> Embedding net_device into structures prohibits the usage of flexible
> > >>> arrays in the net_device structure. For more details, see the discussion
> > >>> at [1].
> > >>>
> > >>> Un-embed the net_device from the private struct by converting it
> > >>> into a pointer. Then use the leverage the new alloc_netdev_dummy()
> > >>> helper to allocate and initialize dummy devices.
> > >>>
> > >>> [1] https://lore.kernel.org/all/[email protected]/
> > >>>
> > >>> Signed-off-by: Breno Leitao <[email protected]>
> > >>
> > >> I think this patch should go via net-next tree, because wireless-next tree
> > >> doesn't have patch of dummy devices yet.
> > >>
> > >> Acked-by: Ping-Ke Shih <[email protected]>
> > >
> > > FWIW I sent the wireless-next pull request yesterday and once it pulled
> > > we will fast forward wireless-next to latest net-next.
> >
> > Oh, I just realised that this is not CCed to netdev so their patchwork
> > won't even see the patch. Ping, I recommend that you wait for the
> > dependency commits to trickle down to your tree and then apply the
> > patch. That's the simplest approach and no need to resend anything.
>
> Okay. If we don't hurry to get this patch merged, I will apply this patch
> to my tree.
There is no hurry to get this patch merged.
Out of curiosity, why don't you rebase your tree to net-next/linux-next
frequently?
Breno Leitao <[email protected]> wrote:
>
> On Thu, Apr 25, 2024 at 06:15:21AM +0000, Ping-Ke Shih wrote:
> > Kalle Valo <[email protected]> wrote:
> > > Kalle Valo <[email protected]> writes:
> > >
> > > > Ping-Ke Shih <[email protected]> writes:
> > > >
> > > >> Breno Leitao <[email protected]> wrote:
> > > >>> Embedding net_device into structures prohibits the usage of flexible
> > > >>> arrays in the net_device structure. For more details, see the discussion
> > > >>> at [1].
> > > >>>
> > > >>> Un-embed the net_device from the private struct by converting it
> > > >>> into a pointer. Then use the leverage the new alloc_netdev_dummy()
> > > >>> helper to allocate and initialize dummy devices.
> > > >>>
> > > >>> [1] https://lore.kernel.org/all/[email protected]/
> > > >>>
> > > >>> Signed-off-by: Breno Leitao <[email protected]>
> > > >>
> > > >> I think this patch should go via net-next tree, because wireless-next tree
> > > >> doesn't have patch of dummy devices yet.
> > > >>
> > > >> Acked-by: Ping-Ke Shih <[email protected]>
> > > >
> > > > FWIW I sent the wireless-next pull request yesterday and once it pulled
> > > > we will fast forward wireless-next to latest net-next.
> > >
> > > Oh, I just realised that this is not CCed to netdev so their patchwork
> > > won't even see the patch. Ping, I recommend that you wait for the
> > > dependency commits to trickle down to your tree and then apply the
> > > patch. That's the simplest approach and no need to resend anything.
> >
> > Okay. If we don't hurry to get this patch merged, I will apply this patch
> > to my tree.
>
> There is no hurry to get this patch merged.
I merged this patch today.
>
> Out of curiosity, why don't you rebase your tree to net-next/linux-next
> frequently?
My tree goes to wireless-next, so I think it should be always based on
wireless-next. Once wirelss-next rebase (ff-merge) net-next, my tree will
have them also.
Ping-Ke Shih <[email protected]> writes:
>> Out of curiosity, why don't you rebase your tree to net-next/linux-next
>> frequently?
>
> My tree goes to wireless-next, so I think it should be always based on
> wireless-next. Once wirelss-next rebase (ff-merge) net-next, my tree will
> have them also.
The simple answer about updating to net-next frequently: it's
complicated :)
The long answer is that the guidance from Linus is to avoid making
unnecessary merges so we fast forward wireless-next only after it's
pulled to net-next. And we can't rebase wireless-next due to downstream
trees Ping's rtw tree, besides rebasing public git trees is evil anyway.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On Thu, May 09, 2024 at 12:48:21PM +0300, Kalle Valo wrote:
> Ping-Ke Shih <[email protected]> writes:
>
> >> Out of curiosity, why don't you rebase your tree to net-next/linux-next
> >> frequently?
> >
> > My tree goes to wireless-next, so I think it should be always based on
> > wireless-next. Once wirelss-next rebase (ff-merge) net-next, my tree will
> > have them also.
>
> The simple answer about updating to net-next frequently: it's
> complicated :)
>
> The long answer is that the guidance from Linus is to avoid making
> unnecessary merges so we fast forward wireless-next only after it's
> pulled to net-next. And we can't rebase wireless-next due to downstream
> trees Ping's rtw tree, besides rebasing public git trees is evil anyway.
Thanks for the explanation!