netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alvin Šipraga" <ALSI@bang-olufsen.dk>
To: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Cc: "Florian Fainelli" <f.fainelli@gmail.com>,
	"open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Vivien Didelot" <vivien.didelot@gmail.com>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Arınç ÜNAL" <arinc.unal@arinc9.com>
Subject: Re: [PATCH net-next] net: dsa: realtek: rtl8365mb: irq with realtek-mdio
Date: Thu, 10 Feb 2022 23:48:59 +0000	[thread overview]
Message-ID: <878ruil1ud.fsf@bang-olufsen.dk> (raw)
In-Reply-To: <CAJq09z7QJ9qXteGMFCjYOVanu7iAP6aNO3=5a8cjYMAe+7TQfQ@mail.gmail.com>       (Luiz Angelo Daros de Luca's message of "Thu, 10 Feb 2022 19:15:58   -0300")

Luiz Angelo Daros de Luca <luizluca@gmail.com> writes:

>> This assumes a 1:1 mapping between the port number and its PHY address
>> on the internal MDIO bus, is that always true?
>
> Thanks Florian,
>
> As far as I know, for supported models, yes. I'm not sure about models
> rtl8363nb and rtl8364nb because they have only 2 user ports at 1 and
> 3.
> Anyway, they are not supported yet.

I think the port number as defined in the device tree is always going to
be the same as its PHY address on the internal bus. I had a look at the
Realtek code and this seems to be the assumption there too.

>
>> It seems to me like we are resisting as much as possible the creating of
>> the MDIO bus using of_mdiobus_register() and that seems to be forcing
>> you to jump through hoops to get your per-port PHY interrupts mapped.
>>
>> Maybe this needs to be re-considered and you should just create that
>> internal MDIO bus without the help of the DSA framework and reap the
>> benefits? We could also change the DSA framework's way of creating the
>> MDIO bus so as to be OF-aware.
>
> That looks like a nice idea.
>
> I do not have any problem duplicating the mdio setup from realtek-smi
> into realtek-mdio.
> However, it is just 3 copies of the same code (and I believe there are
> a couple more of them):
>
> 1) dsa_switch_setup()+dsa_slave_mii_bus_init()
> 2) realtek_smi_setup_mdio()
> 3) realtek_mdio_setup_mdio() (NEW)
>
> And realtek_smi_setup_mdio only exists as a way to reference the
> OF-node. And OF-node is only needed because it needs to associate the
> interrupt-parent and interrupts with each phy.
> I think the best solution would be a way that the
> dsa_slave_mii_bus_init could look for a specific subnode. Something
> like:
>
> dsa_slave_mii_bus_init(struct dsa_switch *ds)
> {
>         struct device_node *dn;
> ...
>         dn = of_get_child_by_name(ds->dn, "slave_mii_bus");
>         if (dn) {
>                 ds->slave_mii_bus->dev.of_node = dn;
>         }
> ...
> }
>
> It would remove the realtek_smi_setup_mdio().

We are not the only ones doing this. mv88e6xxx is another example. So
Florian's suggestion seems like a good one, but we should be careful to
maintain compatibility with older device trees. In some cases it is
based on child node name (e.g. "mdio"), in others it is based on the
child node compatible string (e.g. "realtek,smi-mdio",
"marvell,mv88e6xxx-mdio-external"). 

>
> If possible, I would like to define safe default values (like assuming
> 1:1 mapping between the port number and its PHY address) for this
> driver when interrupt-controller is present but
> slave_mii_bus node is missing.

You could just require the phy nodes to be described in the device
tree. Then you don't need this extra port_setup code. Seems better IMO,
or am I missing something?

Kind regards,
Alvin

>
> Does it sound ok?
>
> --
> Luiz

  reply	other threads:[~2022-02-10 23:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09 22:45 [PATCH net-next] net: dsa: realtek: rtl8365mb: irq with realtek-mdio Luiz Angelo Daros de Luca
2022-02-10  3:30 ` Florian Fainelli
2022-02-10 22:15   ` Luiz Angelo Daros de Luca
2022-02-10 23:48     ` Alvin Šipraga [this message]
2022-02-11  4:51       ` Luiz Angelo Daros de Luca
2022-02-11  5:11         ` [PATCH net-next] net: dsa: OF-ware slave_mii_bus (RFC) Luiz Angelo Daros de Luca
2022-02-11  9:35           ` Alvin Šipraga
2022-02-12  3:39             ` Luiz Angelo Daros de Luca
2022-02-11  9:03         ` [PATCH net-next] net: dsa: realtek: rtl8365mb: irq with realtek-mdio Alvin Šipraga

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=878ruil1ud.fsf@bang-olufsen.dk \
    --to=alsi@bang-olufsen.dk \
    --cc=andrew@lunn.ch \
    --cc=arinc.unal@arinc9.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=luizluca@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=vivien.didelot@gmail.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).