All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	netdev <netdev@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] net: dsa: ocelot: add NET_VENDOR_MICROSEMI dependency
Date: Wed, 11 Dec 2019 00:32:51 +0200	[thread overview]
Message-ID: <CA+h21hp1gg2SNX3f-+3gG3au90XsrYkzjvWYXmHdiWv-Bu=KPQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2ONPojLz=REmbBMwnSsB3GVyqLYtCD28mmKk5qr3KpdQ@mail.gmail.com>

On Wed, 11 Dec 2019 at 00:04, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Dec 10, 2019 at 10:37 PM Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> > Hi Arnd,
> >
> > On Tue, 10 Dec 2019 at 22:37, Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > Selecting MSCC_OCELOT_SWITCH is not possible when NET_VENDOR_MICROSEMI
> > > is disabled:
> > >
> > > WARNING: unmet direct dependencies detected for MSCC_OCELOT_SWITCH
> > >   Depends on [n]: NETDEVICES [=y] && ETHERNET [=n] && NET_VENDOR_MICROSEMI [=n] && NET_SWITCHDEV [=y] && HAS_IOMEM [=y]
> > >   Selected by [m]:
> > >   - NET_DSA_MSCC_FELIX [=m] && NETDEVICES [=y] && HAVE_NET_DSA [=y] && NET_DSA [=y] && PCI [=y]
> > >
> > > Add a Kconfig dependency on NET_VENDOR_MICROSEMI, which also implies
> > > CONFIG_NETDEVICES.
> > >
> > > Fixes: 56051948773e ("net: dsa: ocelot: add driver for Felix switch family")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> >
> > This has been submitted before, here [0].
> >
> > It isn't wrong, but in principle I agree with David that it is strange
> > to put a "depends" relationship between a driver in drivers/net/dsa
> > and the Kconfig vendor umbrella from drivers/net/ethernet/mscc ("why
> > would the user care/need to enable NET_VENDOR_MICROSEMI to see the DSA
> > driver" is a valid point to me). This is mainly because I don't
> > understand the point of CONFIG_NET_VENDOR_* options, they're a bit
> > tribalistic to my ears.
> >
> > 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.

> > - Remove NET_VENDOR_MICROSEMI altogether. There is a single driver
> > under drivers/net/ethernet/mscc and it's already causing problems,
> > it's ridiculous.
>
> It's only there for consistency with the other directories under
> drivers/net/ethernet/.
>
> > - Leave it as it is. I genuinely ask: if the build system tells you
> > that the build dependencies are not met, does it matter if it compiles
> > or not?
>
> We try very hard to allow all randconfig builds to complete without
> any output from the build process when building with 'make -s'.
> Random warnings like this just clutter up the output, even if it's
> harmless there is a risk of missing something important.
>
> Yet another option is
> - Change NET_DSA_MSCC_FELIX to use 'depends on
>   MSCC_OCELOT_SWITCH' instead of 'select NET_DSA_MSCC_FELIX'.
>

That's strange too. MSCC_OCELOT_SWITCH just enables a common driver
core which is used by both NET_DSA_MSCC_FELIX and
MSCC_OCELOT_SWITCH_OCELOT (possibly by more in the future). I don't
see any reason why the common library (purely an implementation
detail) should even be user-visible, let alone why it should hide a
DSA driver.

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.

>
>      Arnd

Thanks,
-Vladimir

  reply	other threads:[~2019-12-10 22:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10 20:36 [PATCH] net: dsa: ocelot: add NET_VENDOR_MICROSEMI dependency Arnd Bergmann
2019-12-10 21:37 ` Vladimir Oltean
2019-12-10 22:04   ` Arnd Bergmann
2019-12-10 22:32     ` Vladimir Oltean [this message]
2019-12-11  7:57       ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+h21hp1gg2SNX3f-+3gG3au90XsrYkzjvWYXmHdiWv-Bu=KPQ@mail.gmail.com' \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.