netdev - Re: [RFC PATCH net-next 8/8] dt-bindings: net: fsl,backplane-anlt: new binding document

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: <20230906140210.sfyiohp3cxf3epuc@skbuf>
Date: Wed, 6 Sep 2023 17:02:10 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Rob Herring <robh@...nel.org>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-phy@...ts.infradead.org,
	"Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Madalin Bucur <madalin.bucur@....com>,
	Ioana Ciornei <ioana.ciornei@....com>,
	Camelia Groza <camelia.groza@....com>, Li Yang <leoyang.li@....com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor@...nel.org>,
	Sean Anderson <sean.anderson@...o.com>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Vinod Koul <vkoul@...nel.org>,
	Kishon Vijay Abraham I <kishon@...nel.org>
Subject: Re: [RFC PATCH net-next 8/8] dt-bindings: net: fsl,backplane-anlt:
 new binding document

Hi Andrew and phylib/phylink maintainers in general,

On Tue, Aug 22, 2023 at 04:10:45PM +0200, Andrew Lunn wrote:
> For C22 PHYs, the ID registers are only used to ask user space to load
> a driver which supports that ID, and then used to match a device to a
> driver. We often say that if the ID registers don't actually contain
> an ID, or the wrong ID, use ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$
> to let the subsystem know the correct ID.
> 
> The device you are trying to support has the same problem, invalid
> IDs, but its C45.
> 
> C45 IDs however work slightly differently. An C45 package can have
> multiple devices in it, up to 32. Each device has its own ID
> registers. So there can be up to 32 different IDs for one package. The
> core will try to determine which of the 32 devices are actually in the
> package, and if they are, what the ID is. It then asks user space to
> load a driver for all the IDs it finds. And when matching devices to
> drivers, it sees if any of the ID of the package matches the IDs the
> driver says it supports. If a match is found, that one driver is
> expected to drive all the devices in that one package.
> 
> I don't see a need for ethernet-phy-ieee802.3-c45-idXXXX.XXXX,
> ethernet-phy-ieee802.3-idXXXX.XXXX should be sufficient, since all you
> are doing it matching the ID against the driver. That matching does
> not differ between C22 and C45. 
> 
> Saying "ethernet-phy-ieee802.3-c45" might be useful, because at the
> moment we have a mixup between C45 register space and C45 bus
> transactions. The drive is free to access C22 and/or C45 registers,
> since it should know what the device actually has. But some of the
> core might get the wrong idea without "ethernet-phy-ieee802.3-c45".
> 
> O.K, that the background now:
> 
> > First: Compatible strings per C45 MMD? Drivers per C45 MMD
> 
> So far, nobody has needed that. All current drivers are package
> drivers, they drive all the devices in the package. At least for a
> PHY, there is close integration between devices in a package. Russell
> has commented that the Marvell 10G PHY does appear to contain a number
> of licensed devices, but so far, we have not noticed the same licensed
> device used by multiple vendors. So there has not been any need to
> reuse code.
> 
> However, it sounds like the package you are trying to support does
> contain multiple independent devices. So from an architecture
> perspective, having multiple drivers would make sense, even if there
> is no reuse. But are the devices PHY? Everything i've said so far
> applies to PHYs. It does not apply to a PCS, etc.
> 
> 	Andrew

I don't know if the devices qualify as phy_device structures according
to the opinion of the maintainers, and that is one of the fundamental
aspects I would like this RFC to clarify, before I proceed to request
NXP to allocate a new PHY ID that I can put in the compatible string.

If the backplane AN/LT block is not a phy_device structure, my
imagination will need a bit of help on how to integrate it, as a raw
mdio_device, with phylink or with the consumer MAC drivers directly.