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
| ||
|
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.
Powered by blists - more mailing lists