[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <000001d8f20b$33f0f0e0$9bd2d2a0$@gmail.com>
Date: Sun, 6 Nov 2022 19:11:32 +0100
From: <piergiorgio.beruto@...il.com>
To: "'Andrew Lunn'" <andrew@...n.ch>
Cc: <netdev@...r.kernel.org>
Subject: RE: Adding IEEE802.3cg Clause 148 PLCA support to Linux
> I suggest you define new ethtool netlink messages. I don't think PHY tunables would make a good interface, since you have > multiple values which need configuring, and you also have some status information.
That sounds fair to me, thanks for your advice.
> So you probably want a message to set the configuration, and another to get the current configuration. For the set, you
> probably want an attribute per configuration value, and allow a subset of attributes to be included in the message. The get
> configuration should by default return all the attributes, but not enforce this, since some vendor will implement it wrong
> and miss something out.
Yes, that sounds about right. If you have any hint on where in the code to start looking at, I'll start from there.
> The get status message should return the PST value. This is something you might also want to append to the linkstate
> message, next to the SQI values.
Sure.
> What I don't see in the Open Alliance spec is anything about interrupts. It would be interesting to see if any vendor triggers
> an interrupt when PST changes. A PHY which has this should probably send a linkstate message to userspace reporting the
> state change. For PHYs without interrupts, phylib will poll the read_status method once per second. You probably want to
> check the PST bit during that poll. If EN is true, but PST is false, is the link considered down?
This is actually an interesting point. First of all, yes, vendors do have IRQs for the PST. At least, the products I'm working on do, including the already released NCN26010.
My thinking is that the PST should be taken into account to evaluate the status of the link. On a multi-drop network with no autoneg and no link training the link status would not make much sense anyway, just like the connected status of an UDP socket wouldn't make sense.
My thinking is that we should enable the PHY drivers to report a link status evaluating PST as well.
> I would also include a check in the phylib core. If the set request tries to set EN to true, check the current link mode and if it
> is not half duplex return -EINVAL. An extack messages would be good here as well.
Yes, that makes sense.
> For the interface between phylib and the PHY driver, you should probably add to the struct phy_driver a set configuration
> method, a get configuration method, and maybe a get status method. You can provide implementations for these methods
> in phy-c45.c which any PHY driver which conforms to the standard can use.
Roger, thanks for the hint!
Piergiorgio
Powered by blists - more mailing lists