public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Arnd Bergmann <arnd@arndb.de>, Arnd Bergmann <arnd@kernel.org>,
	Andrew Lunn <andrew@lunn.ch>, Vladimir Oltean <olteanv@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Netdev <netdev@vger.kernel.org>,
	linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org
Subject: Re: [PATCH] net: dsa: MxL862xx: don't force-enable MAXLINEAR_GPHY
Date: Sat, 21 Feb 2026 02:05:27 +0000	[thread overview]
Message-ID: <aZkS585QOq6g7Ax-@makrotopia.org> (raw)
In-Reply-To: <9d7aee5a-ac46-47d9-ac26-0f3a63b6a8ab@roeck-us.net>

On Fri, Feb 20, 2026 at 05:25:06PM -0800, Guenter Roeck wrote:
> On 2/16/26 08:27, Arnd Bergmann wrote:
> > On Mon, Feb 16, 2026, at 17:22, Daniel Golle wrote:
> > > On Mon, Feb 16, 2026 at 08:20:41AM -0800, Guenter Roeck wrote:
> > > > On 2/16/26 07:34, Arnd Bergmann wrote:
> > > > > On Mon, Feb 16, 2026, at 16:17, Guenter Roeck wrote:
> > > > > > On 2/16/26 04:15, Daniel Golle wrote:
> > > > > > 
> > > > > > Technically, with "select MAXLINEAR_GPHY", NET_DSA_MXL862 should depend
> > > > > > on "depends on HWMON || HWMON=n". That would prevent NET_DSA_MXL862=y
> > > > > > and with it MAXLINEAR_GPHY=y.
> > > > > > 
> > > > > > Maybe it is time to implement dummy functions for hwmon API calls
> > > > > > to avoid all this.
> > 
> > I think I misread this bit earlier, sorry
> > 
> > > > > I had considered this when I found the build failure, but
> > > > > I think removing the 'select' here is much better: this
> > > > > simplifies the dependencies, and allows a valid configuration
> > > > > with hwmon and gphy support in a loadable module that would
> > > > > otherwise be impossible.
> > > > > 
> > > > 
> > > > Makes sense. I think I'll move forward with the dummy functions anyway
> > > > because with that the #ifdefs in drivers are no longer necessary
> > > > and the "depends on HWMON || HWMON=n" becomes optional.
> > > 
> > > Yes, that would be great and eliminate that whole class of obstacles
> > > with some inline no-op stubs in the header.
> > 
> > What I meant above is that I had considered and rejected the extra
> > dependencies in the ethernet driver. I don't think there is a good
> > way to add inline helpers. Technically, one could use IS_REACHABLE()
> > here, to stub out the functions when the caller is built-in, but
> > I find that even worse because it replaces a trivial build-time
> > failure with very subtle runtime bug.
> > 
> 
> Lots of kernel APIs have dummy implementations. hwmon isn't really that
> different to those. Also, arguably, that would not be a subtle runtime
> bug but a feature.
> 
> In this context:
> 
> If NET_DSA_MXL862 is enabled but MAXLINEAR_GPHY isn't, does the system
> still work ?

The switches supported by NET_DSA_MXL862 come with 5 or 8 twistedpair
ports provided by built-in PHYs. For the ports to (fully) work the
MAXLINEAR_GPHY driver is required, as without it they would be detected
as "Generic PHY".

This is similar to the situation on other DSA switches, and there is
apparently no clear rule whether this (runtime) dependency should be
treated as depedency in Kconfig which is typically used only to express
linking dependencies.

  reply	other threads:[~2026-02-21  2:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-16 10:55 [PATCH] net: dsa: MxL862xx: don't force-enable MAXLINEAR_GPHY Arnd Bergmann
2026-02-16 12:15 ` Daniel Golle
2026-02-16 12:26   ` Arnd Bergmann
2026-02-16 15:17   ` Guenter Roeck
2026-02-16 15:34     ` Arnd Bergmann
2026-02-16 16:20       ` Guenter Roeck
2026-02-16 16:22         ` Daniel Golle
2026-02-16 16:27           ` Arnd Bergmann
2026-02-21  1:25             ` Guenter Roeck
2026-02-21  2:05               ` Daniel Golle [this message]
2026-02-21 14:24               ` Arnd Bergmann
2026-02-18  1:20 ` patchwork-bot+netdevbpf

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=aZkS585QOq6g7Ax-@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox