From: Andrew Lunn <andrew@lunn.ch>
To: Vasilij Strassheim <v.strassheim@linutronix.de>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Eric Dumazet <edumazet@kernel.org>, Lee Jones <lee@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, mfd@lists.linux.dev,
Martin Kaistra <martin.kaistra@linutronix.de>,
Benedikt Spranger <b.spranger@linutronix.de>
Subject: Re: [PATCH net-next v4 4/8] dt-bindings: mfd: Add SoC-e SWIP parent
Date: Fri, 13 Nov 2026 21:48:27 +0100 [thread overview]
Message-ID: <e4417d39-390d-4ece-bb2d-5f1745185d37@lunn.ch> (raw)
In-Reply-To: <5a6183e3480a0d910e275acf591e2db8700da827.camel@linutronix.de>
> > Given the MDIO bus and mux registers are adjacent, I don't know that
> > putting the mux into its own node and driver really buys you anything.
> > Can't your MDIO driver handle the muxing directly? mdio-mux-mmioreg was
> > created for when you have mux registers in some completely unrelated
> > block.
> >
>
> What it buys me is less custom code to maintain for bus selection and
> selector-value validation.
>
> The MDIO controller and mux were combined in a previous version.
> Following Andrew's suggestion [1], I moved the controller into its own
> driver and stacked mdio-mux-mmioreg on top of it.
> Sure, the selector is part of the same MDIO control register. But the
> generic driver already provides the masked register update and
> selector-value checks. My preference is to keep the current approach
> to reuse existing code, even if it requires some integration and
> documentation efforts.
Since you have both implementations. Did the lines of code go down
when you reused the existing mux?
> The IP core can also include an I2C master for accessing external
> devices as a synthesis option.
SFP cage being the obvious thing.
It will need to be a Linux I2C master in order that phylink can use
it. And i would not be too surprised if the existing I2C drivers can
drive it, it will be licensed IP. So an MFD will make it easier to
instantiate.
Andrew
next prev parent reply other threads:[~2026-11-13 20:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 14:16 [PATCH net-next v4 0/8] net: dsa: Add support for SoC-e Ethernet switch IP cores Vasilij Strassheim
2026-11-05 14:16 ` [PATCH net-next v4 1/8] dt-bindings: vendor-prefixes: Add soce Vasilij Strassheim
2026-11-05 14:16 ` [PATCH net-next v4 2/8] dt-bindings: net: Add SoC-e SWIP MDIO controller Vasilij Strassheim
2026-11-05 14:16 ` [PATCH net-next v4 3/8] dt-bindings: net: dsa: Add SoC-e SWIP switch function Vasilij Strassheim
2026-11-12 10:33 ` Krzysztof Kozlowski
2026-11-13 19:07 ` Vasilij Strassheim
2026-11-05 14:16 ` [PATCH net-next v4 4/8] dt-bindings: mfd: Add SoC-e SWIP parent Vasilij Strassheim
2026-11-06 11:13 ` Krzysztof Kozlowski
2026-11-06 21:51 ` Vasilij Strassheim
2026-11-10 16:10 ` Vasilij Strassheim
2026-11-10 19:21 ` Rob Herring
2026-11-13 18:58 ` Vasilij Strassheim
2026-11-13 20:48 ` Andrew Lunn [this message]
2026-11-05 14:16 ` [PATCH net-next v4 5/8] net: dsa: Add tag handling for SoC-e switches Vasilij Strassheim
2026-11-05 14:16 ` [PATCH net-next v4 6/8] net: mdio: Add SoC-e SWIP MDIO controller driver Vasilij Strassheim
2026-11-05 14:16 ` [PATCH net-next v4 7/8] net: dsa: soce: Add basic support for SoC-e switch IP cores Vasilij Strassheim
2026-11-05 14:16 ` [PATCH net-next v4 8/8] net: dsa: soce: Add VLAN membership table support Vasilij Strassheim
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=e4417d39-390d-4ece-bb2d-5f1745185d37@lunn.ch \
--to=andrew@lunn.ch \
--cc=andrew+netdev@lunn.ch \
--cc=b.spranger@linutronix.de \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=horms@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=kuba@kernel.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=martin.kaistra@linutronix.de \
--cc=mfd@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=v.strassheim@linutronix.de \
/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
all inboxes | Powered by JetHome®