mbox series

[net-next,v3,0/5] allocate dummy device dynamically

Message ID 20240404114854.2498663-1-leitao@debian.org (mailing list archive)
Headers show
Series allocate dummy device dynamically | expand

Message

Breno Leitao April 4, 2024, 11:48 a.m. UTC
struct net_device shouldn't be embedded into any structure, instead,
the owner should use the private space to embed their state into
net_device.

But, in some cases the net_device is embedded inside the private
structure, which blocks the usage of zero-length arrays inside
net_device.

Create a helper to allocate a dummy device at dynamically runtime, and
move the Ethernet devices to use it, instead of embedding the dummy
device inside the private structure.

This fixes all the network cases except for wireless drivers.

PS: Due to lack of hardware, unfortunately all these patches are
compiled tested only.

---
Changelog:

v1:
	* https://lore.kernel.org/all/20240327200809.512867-1-leitao@debian.org/

v2:
	* Patch 1: Use a pre-defined name ("dummy#") for the dummy
	  net_devices.
	* Patch 2-5: Added users for the new helper.
v3:
	* Use free_netdev() instead of kfree() as suggested by Jakub.
	* Change the free_netdev() place in ipa driver, as suggested by
	  Alex Elder.
	* Set err in the error path in the Marvell driver, as suggested
	  by Simon Horman.

Breno Leitao (5):
  net: create a dummy net_device allocator
  net: marvell: prestera: allocate dummy net_device dynamically
  net: mediatek: mtk_eth_sock: allocate dummy net_device dynamically
  net: ipa: allocate dummy net_device dynamically
  net: ibm/emac: allocate dummy net_device dynamically

 drivers/net/ethernet/ibm/emac/mal.c           | 13 +++--
 drivers/net/ethernet/ibm/emac/mal.h           |  2 +-
 .../ethernet/marvell/prestera/prestera_rxtx.c | 15 ++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 17 ++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h   |  2 +-
 drivers/net/ipa/gsi.c                         | 12 +++--
 drivers/net/ipa/gsi.h                         |  2 +-
 include/linux/netdevice.h                     |  3 ++
 net/core/dev.c                                | 54 ++++++++++++-------
 9 files changed, 85 insertions(+), 35 deletions(-)

Comments

Breno Leitao April 4, 2024, 2:22 p.m. UTC | #1
Hello Kalle,

On Thu, Apr 04, 2024 at 02:59:59PM +0300, Kalle Valo wrote:
> Breno Leitao <leitao@debian.org> writes:
> 
> > struct net_device shouldn't be embedded into any structure, instead,
> > the owner should use the private space to embed their state into
> > net_device.
> >
> > But, in some cases the net_device is embedded inside the private
> > structure, which blocks the usage of zero-length arrays inside
> > net_device.
> >
> > Create a helper to allocate a dummy device at dynamically runtime, and
> > move the Ethernet devices to use it, instead of embedding the dummy
> > device inside the private structure.
> >
> > This fixes all the network cases except for wireless drivers.
> >
> > PS: Due to lack of hardware, unfortunately all these patches are
> > compiled tested only.
> 
> BTW if it helps, and if you have an ath10k or ath11k patch already, I
> can run a quick test on real hardware.

That would be very much appreciated! Thanks!

I don't have them ready yet, but, I will work on them soon and I will
send it to you probably tomorrow.

Should I send them as RFC, or as a regular patch, and we iterate over?
What would you prefer?

Thanks!
Kalle Valo April 4, 2024, 3:01 p.m. UTC | #2
Breno Leitao <leitao@debian.org> writes:

> Hello Kalle,
>
> On Thu, Apr 04, 2024 at 02:59:59PM +0300, Kalle Valo wrote:
>> Breno Leitao <leitao@debian.org> writes:
>> 
>> > struct net_device shouldn't be embedded into any structure, instead,
>> > the owner should use the private space to embed their state into
>> > net_device.
>> >
>> > But, in some cases the net_device is embedded inside the private
>> > structure, which blocks the usage of zero-length arrays inside
>> > net_device.
>> >
>> > Create a helper to allocate a dummy device at dynamically runtime, and
>> > move the Ethernet devices to use it, instead of embedding the dummy
>> > device inside the private structure.
>> >
>> > This fixes all the network cases except for wireless drivers.
>> >
>> > PS: Due to lack of hardware, unfortunately all these patches are
>> > compiled tested only.
>> 
>> BTW if it helps, and if you have an ath10k or ath11k patch already, I
>> can run a quick test on real hardware.
>
> That would be very much appreciated! Thanks!
>
> I don't have them ready yet, but, I will work on them soon and I will
> send it to you probably tomorrow.
>
> Should I send them as RFC, or as a regular patch, and we iterate over?
> What would you prefer?

A regular patch, like you did last time with ath11k, is fine for me. But
please do add a lore or patchwork link to the depency patchset so that
I'm testing with correct patches.