netdev - Re: [PATCH net-next v2 3/3] net: dsa: realtek: support reset controller

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CACRpkdaBC7GeeGYoZ+CYjSVV657yFm=B2L6U2mNyh+AVsLbnsA@mail.gmail.com>
Date: Tue, 7 Nov 2023 09:03:48 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Luiz Angelo Daros de Luca <luizluca@...il.com>
Cc: Vladimir Oltean <olteanv@...il.com>, netdev@...r.kernel.org, alsi@...g-olufsen.dk, 
	andrew@...n.ch, vivien.didelot@...il.com, f.fainelli@...il.com, 
	davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, robh+dt@...nel.org, 
	krzk+dt@...nel.org, arinc.unal@...nc9.com
Subject: Re: [PATCH net-next v2 3/3] net: dsa: realtek: support reset controller

On Mon, Nov 6, 2023 at 11:37 PM Luiz Angelo Daros de Luca
<luizluca@...il.com> wrote:

> Your proposed Kconfig does not attempt to avoid a realtek-interface
> without both interfaces or without support for both switch families.
> Is it possible in Kconfig to force it to, at least, select one of the
> interfaces and one of the switches? Is it okay to leave it
> unconstrained?

Can't you just remove the help text under
NET_DSA_REALTEK_INTERFACE so it becomes a hidden
option? The other options just select it anyway.

> If merging the modules is the accepted solution, it makes me wonder if
> rtl8365mb.ko and rtl8366.ko should get merged as well into a single
> realtek-switch.ko. They are a hard dependency for realtek-interface.ko
> (previously on each interface module). If the kernel is custom-built,
> it would still be possible to exclude one switch family at build time.

That's not a good idea, because we want to be able to load
a single module into the kernel to support a single switch
family at runtime. If you have a kernel that boots on several
systems and some of them have one of the switches and
some of them have another switch, I think you see the problem
with this approach.

> I'll use these modules in OpenWrt, which builds a single kernel for a
> bunch of devices. Is there a way to weakly depend on a module,
> allowing the system to load only a single subdriver? Is it worth it?

Last time I looked actually having DSA:s as loadable modules
didn't work so well, so they are all compiled in. In OpenWrt
I didn't find any DSA modules packaged as modules. But maybe
I didn't try hard enough. IIRC the problem is that it needs to
also have a tag module (for NET_DSA_TAG_*) and that didn't
modularize so well.

Yours,
Linus Walleij