[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8fd9f2bc-f8a2-4290-8e52-17a39175b3d7@lunn.ch>
Date: Tue, 5 Sep 2023 22:29:51 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Richard Cochran <richardcochran@...il.com>,
Köry Maincent <kory.maincent@...tlin.com>,
Vladimir Oltean <vladimir.oltean@....com>,
"Russell King (Oracle)" <linux@...linux.org.uk>,
netdev@...r.kernel.org, glipus@...il.com,
maxime.chevallier@...tlin.com, vadim.fedorenko@...ux.dev,
gerhard@...leder-embedded.com, thomas.petazzoni@...tlin.com,
krzysztof.kozlowski+dt@...aro.org, robh+dt@...nel.org
Subject: Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping
layers to user space.
> Maybe we should try to enumerate the use cases, I don't remember now
> but I think the concern was that there may be multiple PHYs?
You often see a Marvell 10G PHY between a MAC and an SFP cage. You can
then get a copper SFP module which has a PHY in it.
So:
"Linux" NIC: [DMA MAC][PHY][PHY]
And just to make it more interesting, you sometimes see:
[MAC] - MII MUX -+---[PHY][PHY]
|
+---[PHY]
This is currently not supported, but there is work in progress to
address this, by giving each PHY and ID, and extending the netlink
ethtool so you can enumerate PHYs and individually configure them.
And i pointed out maybe the worst case scenario:
[MAC][PHY][PHY][MAC]switch core[MAC][PHY][PHY]
Andrew
Powered by blists - more mailing lists