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] [day] [month] [year] [list]

Message-ID: <CAJq09z6_nVvXsvL0KD9fYNELNkdFg+_dM95Umb4hJgrUP3H-5A@mail.gmail.com>
Date: Tue, 7 Nov 2023 10:54:58 -0300
From: Luiz Angelo Daros de Luca <luizluca@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
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

> > 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.

Without a text after the tristate, it will already be hidden. However,
we can still ask to build a module with no SMI and MDIO.

> > 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.

We already have this situation. As the interface module uses
rtl8366rb_variant and rtl8365mb_variant, we cannot select one or the
other at runtime.

rtl8365mb              14802  1 realtek_smi
rtl8366                20870  1 realtek_smi
tag_rtl4_a              1522  1

If we build it with support for both switches, both modules need to be
loaded together.

Somehow initializing the switch selectively autoloads the tag module.
Is it possible to have something like this for subdrivers?

> > 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.

It does work, even the tag module. As I mentioned, the tag modules are
even loaded on demand. You just need to load it in the correct
sequence.

>
> Yours,
> Linus Walleij