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]

Date: Tue, 21 Nov 2023 23:35:59 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Luiz Angelo Daros de Luca <luizluca@...il.com>
Cc: Vladimir Oltean <olteanv@...il.com>, netdev@...r.kernel.org,
 linus.walleij@...aro.org, alsi@...g-olufsen.dk, andrew@...n.ch,
 f.fainelli@...il.com, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, pabeni@...hat.com, arinc.unal@...nc9.com
Subject: Re: [net-next 2/2] net: dsa: realtek: load switch variants on demand

On 21/11/2023 23:15, Krzysztof Kozlowski wrote:
> How is this even related to the problem? Please respond with concise
> messages.
> 
>> the "XXXX" for modprobe. For DSA tags, module names are generated
>> according to a fixed rule based on the tag name. However, the switch
>> variants do not have a fixed relation between module name and switch
>> families (actually, there is not even a switch family name). I could
>> (and did in a previous RFC) use the match data to inform each module
>> name. However, it adds a non-obvious relation between the module name
>> (defined in Makefile) and a string in code. I was starting to
>> implement a lookup table to match compatible strings to their module
>> names when I realized that I was just mapping a string to a module
>> name, something like what module alias already does. That's when the
>> MODULE_ALIAS("<the compatible string>") was introduced.
>>
>> After this discussion, I have some questions:
>>
>> I'm declaring the of_device_id match table in realtek-common as it is
>> the same for both interfaces. I also moved MODULE_DEVICE_TABLE(of,
>> realtek_common_of_match) to realtek-common. Should I keep the
>> MODULE_DEVICE_TABLE() on each interface module (referencing the same
>> table), or is it okay to keep it in the realtek-common module? If I
> 
> Why would you have the same compatible entries in different modules? You
> do understand that device node will become populated on first bind (bind
> of the first device)?
> 
>> need to move it to each interface module, can I reuse a shared
>> of_device_id match table declared in realtek-common?
>>
>> If MODULE_ALIAS is not an acceptable solution, what would be the right
>> one? Go back to the static mapping between the compatible string and
>> the module name or is there a better solution?

Probably the solution is to make the design the same as for all other
complex drivers supporting more than one bus. If your ID table is
defined in modules A and B, then their loading should not depend on
aliases put in some additional "common" module. We solved this many
times for devices residing on multiple buses (e.g. I2C and SPI), so why
this has to be done in reverse order?

If you ask what would be the acceptable solution, then my answer is: do
the same as for most of other drivers, do not reinvent stuff like
putting same ID table or module alias in two modules. The table is
defined only once in each driver being loaded on uevent. From that
driver you probe whatever device you have, including calling any common
code, subprobes, subvariants etc.

Best regards,
Krzysztof