netdev - Re: [net-next 2/2] net: dsa: realtek: load switch variants on demand

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231207170201.xq3it75hqqd6qnzj@skbuf>
Date: Thu, 7 Dec 2023 19:02:01 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Luiz Angelo Daros de Luca <luizluca@...il.com>
Cc: Alvin Šipraga <ALSI@...g-olufsen.dk>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"andrew@...n.ch" <andrew@...n.ch>,
	"f.fainelli@...il.com" <f.fainelli@...il.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"arinc.unal@...nc9.com" <arinc.unal@...nc9.com>
Subject: Re: [net-next 2/2] net: dsa: realtek: load switch variants on demand

On Mon, Nov 27, 2023 at 07:24:16PM -0300, Luiz Angelo Daros de Luca wrote:
> I'm not sure if getting/putting a module is a problem or if I can
> request it when missing. I would like some options on that specific
> topic from the experts. It seems to happen in many places, even in DSA
> tag code.
> 
> I wouldn't say it will invariably require both interface modules to be
> loaded. The dynamic load would be much simpler if variants request the
> interface module as we only have two (at most 3 with a future
> realtek-spi) modules. We would just need to call a
> realtek_interface_get() and realtek_interface_put() on each respective
> probe. The module names will be well-known with no issues with
> module_alias.
> 
> Thanks for your help, Alvin. I'll wait for a couple of more days for
> others to manifest.

I'm not an expert on this topic either, but Alvin's suggestion makes
sense to have the switch variant drivers be both platform and MDIO
device drivers, and call symbols exported by the interface drivers as
needed.

If you are able to make the variant driver depend on just the interface
driver in use based on some request_module() calls, I don't think that
will be a problem with Krzysztof either, since he just said to not
duplicate the MODULE_DEVICE_TABLE() functionality.

I think it's down to prototyping something and seeing what are the pros
and cons.