[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <353752b143bca56f79035635808e8e30@kernel.org>
Date: Mon, 26 Jun 2023 08:31:26 +0200
From: Michael Walle <mwalle@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Yisen Zhuang <yisen.zhuang@...wei.com>,
Salil Mehta <salil.mehta@...wei.com>,
Florian Fainelli <florian.fainelli@...adcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Marek BehĂșn <kabel@...nel.org>,
Xu Liang <lxu@...linear.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 04/10] net: phy: replace is_c45 with
phy_accces_mode
Am 2023-06-23 21:54, schrieb Andrew Lunn:
> On Fri, Jun 23, 2023 at 07:34:22PM +0200, Andrew Lunn wrote:
>> > @@ -131,9 +131,11 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
>> >
>> > is_c45 = fwnode_device_is_compatible(child, "ethernet-phy-ieee802.3-c45");
>> > if (is_c45 || fwnode_get_phy_id(child, &phy_id))
>> > - phy = get_phy_device(bus, addr, is_c45);
>> > + phy = get_phy_device(bus, addr,
>> > + is_c45 ? PHY_ACCESS_C45 : PHY_ACCESS_C22);
>> > else
>> > - phy = phy_device_create(bus, addr, phy_id, 0, NULL);
>> > + phy = phy_device_create(bus, addr, phy_id, PHY_ACCESS_C22,
>> > + NULL);
>>
>> Documentation/devicetree/bindings/net/ethernet-phy.yaml says:
>>
>> compatible:
>> oneOf:
>> - const: ethernet-phy-ieee802.3-c22
>> description: PHYs that implement IEEE802.3 clause 22
>> - const: ethernet-phy-ieee802.3-c45
>> description: PHYs that implement IEEE802.3 clause 45
>>
>> It would be nice to make this documentation more specific. It now
>> refers to 'bus transaction', so maybe we want to append that to these
>> lines?
>
> Humm, looking at patch 9, maybe i got this wrong. Patch 9 seems to
> suggest ethernet-phy-ieee802.3-c45 means c45 register space, and it is
> upto the core to figure out how to access that register space, either
> using c45 transactions, or C45 over C22.
Yes. And I think the core has all information to determine what mode
should be used. Use C45 transfers first and iff that's not possible
switch to C45-over-C22. Therefore, there isn't really a choice. It's
either "it will work" or "it won't work at all".
For all supported C45 PHYs right now, the mode should stay with C45
because, that was the only supported mode. Except, if a C45 PHY was
probed as a C22 PHY and stayed that way. With this patchset they
would now be probed a PHY with C45 registers and using C45-over-C22.
But I'm not sure if that's a thing.
-michael
Powered by blists - more mailing lists