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]
Date:   Wed, 11 Dec 2019 08:57:57 +0100
From:   Arnd Bergmann <>
To:     Vladimir Oltean <>
Cc:     Vladimir Oltean <>,
        Claudiu Manoil <>,
        "David S. Miller" <>,
        Andrew Lunn <>,
        Vivien Didelot <>,
        Florian Fainelli <>,
        netdev <>,
        lkml <>
Subject: Re: [PATCH] net: dsa: ocelot: add NET_VENDOR_MICROSEMI dependency

On Tue, Dec 10, 2019 at 11:33 PM Vladimir Oltean <> wrote:
> On Wed, 11 Dec 2019 at 00:04, Arnd Bergmann <> wrote:
> > On Tue, Dec 10, 2019 at 10:37 PM Vladimir Oltean <> wrote:
> > > Nonetheless, alternatives may be:
> > > - Move MSCC_OCELOT_SWITCH core option outside of the
> > > NET_VENDOR_MICROSEMI umbrella, and make it invisible to menuconfig,
> > > just selectable from the 2 driver instances (MSCC_OCELOT_SWITCH_OCELOT
> > > and NET_DSA_MSCC_FELIX). MSCC_OCELOT_SWITCH has no reason to be
> > > selectable by the user anyway.
> >
> > You still need 'depends on NETDEVICES' in that case, otherwise this sounds
> > like a good option.
> >
> I don't completely understand this. Looks like NETDEVICES is another
> one of those options that don't enable any code. I would have expected
> that NET_SWITCHDEV depended on it already? But anyway, it's still a
> small compromise and not a problem.

My mistake: When I had tried it, I did run into this problem, but it was

NET_SWITCHDEV depends only on INET, NET_DSA also depends on
NETDEVICES, but neither of them depends on ETHERNET, which
only controls drivers under drivers/net/ethernet, but not support for
ethernet itself.
> So, if you agree, I can take care of this tomorrow by reworking the
> Kconfig in the 1st proposed way. I hope you don't mind that I'm
> volunteering to do it, but the change will require a bit of explaining
> which is non-trivial, and I don't expect that you really want to know
> these details, just that it compiles with no issue from all angles.

Sounds good, thanks!

If you like, I can give your patch a spin on my randconfig build
system before you submit it for inclusion, in case there is another
problem we both missed.


Powered by blists - more mailing lists