Re: [net-next] net: ethernet: rtsn: Add support for Renesas Ethernet-TSN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert,

On 2024-05-06 19:43:55 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Mon, May 6, 2024 at 4:05 PM Niklas Söderlund
> <niklas.soderlund+renesas@xxxxxxxxxxxx> wrote:
> > On 2024-05-06 03:51:45 +0200, Andrew Lunn wrote:
> > > What PHY is this? Does it have C22 registers? Can it be identified via
> > > C22 registers 2 and 3?
> >
> > The PHY in question is mv88q2110 (drivers/net/phy/marvell-88q2xxx.c),
> > unfortunately I do not have a datasheet for it so I can't tell you much
> > about it.
> >
> > <snip>
> >
> > >
> > > So i would drop the compatible. See if C22 is sufficient to get the
> > > correct driver loaded.
> >
> > - Remove C45 compatible; Remove C45 read/write in driver
> >
> >   The PHY is identified as "Generic PHY", and the correct PHY driver is
> >   not used. I can't test more than that as the generic PHY driver do not
> >   implement some quirks I need to get the link up.
> >
> > - Remove C45 compatible; Keep C45 read/write in driver
> >
> >   The correct PHY driver is used and everything works.
> 
> Does it still work after kexec, or after device unbind/rebind?
> According to [1], the PHY node has a reset-gpios property, so you may
> need to specify the exact PHY model to identify the PHY model at any
> time, regardless of the state of the PHY reset line.

With the "ethernet-phy-ieee802.3-c45" compat in place (and C45 
read/write in the driver) I can bind/unbind the device without issue and 
then operate it as expected. My preferred way forward is to keep the 
compatible for C45 in place so I have not tested without it. However I 
see no reason why it should not work with "Remove C45 compatible; Keep 
C45 read/write in driver" mode.

Note that this driver differs a bit from RAVB for which [2] targets. The 
RAVB driver creates the MDIO bus at probe time, this drivers creates and 
destroys the MDIO bus in sync with the interface state using ndo_open 
and ndo_stop. So the reset is issued correctly no matter what happened 
before and the PHY can be probed.

> 
> Perhaps that issue does not happen when using the mdio subnode, cfr. [3]?
> 
> [1] https://lore.kernel.org/all/20240122160441.759620-3-niklas.soderlund+renesas@xxxxxxxxxxxx/
> [2] 722d55f3a9bd810f ("arm64: dts: renesas: Add compatible properties
> to KSZ9031Ethernet PHYs")
> [3] 8da891720cd407ed ("dt-bindings: net: renesas,ethertsn: Create
> child-node for MDIO bus") in net-next (next-20240405 and later).
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

-- 
Kind Regards,
Niklas Söderlund




[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux