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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240507111840.GK720810@ragnatech.se>
Date: Tue, 7 May 2024 13:18:40 +0200
From: Niklas Söderlund <niklas.soderlund+renesas@...natech.se>
To: Andrew Lunn <andrew@...n.ch>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, linux-renesas-soc@...r.kernel.org
Subject: Re: [net-next] net: ethernet: rtsn: Add support for Renesas
 Ethernet-TSN

HI Andrew and Geert,

On 2024-05-06 22:00:46 +0200, Andrew Lunn wrote:
> > 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.
> 
> That is not a good idea. It is better to create the MDIO bus at probe
> time. There are a few reasons for this.
> 
> 1) It takes while for the machinary to load the PHY driver, when it is
> a module. If it does not get time to do that, you end up with the
> generic PHY driver, even though there is a specific PHY driver, which
> becomes usable a little later in time. But your network is dead
> because the generic PHY drive is not sufficient.
> 
> 2) It is possible that creating the MDIO bus fails with
> EPROBE_DEFER. If this happens at ndo_open(), there is nothing you can
> do about it, other than return the error to user space. If it happens
> during probe, the driver core will handle it, and try to probe the
> driver again sometime later.

Thanks to both of you for your feedback in this review. I now have a way 
forward for this work.

I will drop the C45 read/write functions in the RTSN driver and rework 
the it to register the MDIO bus at probe time. As Geert then suggest I 
will need to state a PHY specific compatible which will solve my initial 
issue.

After this is done I will look to see if the PHY driver can be extended 
with more identification numbers so it can be probed on C22. But this 
will be done separate from my effort to enable the RTSN device.

Thanks again for all your help.

-- 
Kind Regards,
Niklas Söderlund