From: Christian Marangi <ansuelsmth@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
upstream@airoha.com
Subject: Re: [net-next PATCH v9 3/4] net: dsa: Add Airoha AN8855 5-Port Gigabit DSA Switch driver
Date: Sat, 7 Dec 2024 13:11:23 +0100 [thread overview]
Message-ID: <67543b6f.df0a0220.3bd32.6d5d@mx.google.com> (raw)
In-Reply-To: <20241205235709.pa5shi7mh26cnjhn@skbuf>
On Fri, Dec 06, 2024 at 01:57:09AM +0200, Vladimir Oltean wrote:
> On Thu, Dec 05, 2024 at 08:36:30PM +0100, Christian Marangi wrote:
> > > I guess the non-hack solution would be to permit MDIO buses to have
> > > #size-cells = 1, and MDIO devices to acquire a range of the address
> > > space, rather than just one address. Though take this with a grain of
> > > salt, I have a lot more to learn.
> >
> > I remember this was an idea when PHY Package API were proposed and was
> > rejected as we wanted PHY to be single reg.
>
> Would that effort have helped with MDIO devices, in the way it was proposed?
> Why did it die out?
>
> > > If neither of those are options, in principle the hack with just
> > > selecting, randomly, one of the N internal PHY addresses as the central
> > > MDIO address should work equally fine regardless of whether we are
> > > talking about the DSA switch's MDIO address here, or the MFD device's
> > > MDIO address.
> > >
> > > With MFD you still have the option of creating a fake MDIO controller
> > > child device, which has mdio-parent-bus = <&host_bus>, and redirecting
> > > all user port phy-handles to children of this bus. Since all regmap I/O
> > > of this fake MDIO bus goes to the MFD driver, you can implement there
> > > your hacks with page switching etc etc, and it should be equally
> > > safe.
> >
> > I wonder if a node like this would be more consistent and descriptive?
> >
> > mdio_bus: mdio-bus {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > ...
> >
> > mfd@1 {
> > compatible = "airoha,an8855-mfd";
> > reg = <1>;
> >
> > nvmem_node {
> > ...
> > };
> >
> > switch_node {
> > ports {
> > port@0 {
> > phy-handle = <&phy>;
> > };
> >
> > port@1 {
> > phy-handle = <&phy_2>;
> > }
> > };
> > };
> >
> > phy: phy_node {
> >
> > };
> > };
> >
> > phy_2: phy@2 {
> > reg = <2>;
> > }
> >
> > phy@3 {
> > reg = <3>;
> > }
> >
> > ..
> > };
> >
> > No idea how to register that single phy in mfd... I guess a fake mdio is
> > needed anyway... What do you think of this node example? Or not worth it
> > and better have the fake MDIO with all the switch PHY in it?
>
> Could you work with something like this? dtc seems to swallow it without
> any warnings...
>
> mdio_bus: mdio {
> #address-cells = <1>;
> #size-cells = <0>;
>
> soc@1 {
> compatible = "airoha,an8855";
> reg = <1>, <2>, <3>, <4>;
> reg-names = "phy0", "phy1", "phy2", "phy3";
>
> nvmem {
> compatible = "airoha,an8855-nvmem";
> };
>
> ethernet-switch {
> compatible = "airoha,an8855-switch";
>
> ethernet-ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> ethernet-port@0 {
> reg = <0>;
> phy-handle = <&phy0>;
> phy-mode = "internal";
> };
>
> ethernet-port@1 {
> reg = <1>;
> phy-handle = <&phy1>;
> phy-mode = "internal";
> };
>
> ethernet-port@2 {
> reg = <2>;
> phy-handle = <&phy2>;
> phy-mode = "internal";
> };
>
> ethernet-port@3 {
> reg = <3>;
> phy-handle = <&phy3>;
> phy-mode = "internal";
> };
> };
> };
>
> mdio {
> compatible = "airoha,an8855-mdio";
> mdio-parent-bus = <&host_mdio>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> phy0: ethernet-phy@1 {
> reg = <1>;
> };
>
> phy1: ethernet-phy@2 {
> reg = <2>;
> };
>
> phy2: ethernet-phy@3 {
> reg = <3>;
> };
>
> phy3: ethernet-phy@4 {
> reg = <4>;
> };
> };
> };
> };
I finished testing and this works, I'm not using mdio-parent-bus tho as
the mdio-mux driver seems overkill for the task and problematic for PAGE
handling. (mdio-mux doesn't provide a way to give the current addr that
is being accessed)
My big concern is dt_binding_check and how Rob might take this
implementation. We recently had another case with a MFD node and Rob
found some problems in having subnode with compatible but maybe for this
particular complex case it will be O.K.
Still have to check if it's ok to have multiple reg in the mfd root node
(for mdio schema)
--
Ansuel
next prev parent reply other threads:[~2024-12-07 12:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 14:51 [net-next PATCH v9 0/4] net: dsa: Add Airoha AN8855 support Christian Marangi
2024-12-05 14:51 ` [net-next PATCH v9 1/4] net: dsa: add devm_dsa_register_switch() Christian Marangi
2024-12-05 16:03 ` Vladimir Oltean
2024-12-05 14:51 ` [net-next PATCH v9 2/4] dt-bindings: net: dsa: Add Airoha AN8855 Gigabit Switch documentation Christian Marangi
2024-12-05 14:51 ` [net-next PATCH v9 3/4] net: dsa: Add Airoha AN8855 5-Port Gigabit DSA Switch driver Christian Marangi
2024-12-05 16:12 ` Russell King (Oracle)
2024-12-05 17:44 ` Christian Marangi
2024-12-05 16:27 ` Vladimir Oltean
2024-12-05 17:17 ` Christian Marangi
2024-12-05 18:05 ` Vladimir Oltean
2024-12-05 18:29 ` Christian Marangi
2024-12-05 18:50 ` Vladimir Oltean
2024-12-05 19:36 ` Christian Marangi
2024-12-05 23:57 ` Vladimir Oltean
2024-12-07 12:11 ` Christian Marangi [this message]
2024-12-10 20:31 ` Vladimir Oltean
2024-12-10 20:56 ` Christian Marangi
2024-12-05 17:06 ` Vladimir Oltean
2024-12-05 17:26 ` Christian Marangi
2024-12-05 18:34 ` Vladimir Oltean
2024-12-05 19:16 ` Christian Marangi
2024-12-05 14:51 ` [net-next PATCH v9 4/4] net: phy: Add Airoha AN8855 Internal Switch Gigabit PHY Christian Marangi
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=67543b6f.df0a0220.3bd32.6d5d@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=upstream@airoha.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;
as well as URLs for NNTP newsgroup(s).