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
| ||
|
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
Powered by blists - more mailing lists