Thread (26 messages) 26 messages, 5 authors, 2023-08-17

Re: [RFC net-next 0/5] Support for PHY test modes

From: Florian Fainelli <f.fainelli@gmail.com>
Date: 2018-05-01 18:27:13
Also in: lkml

On 05/01/2018 10:47 AM, Andrew Lunn wrote:
On Tue, May 01, 2018 at 10:21:54AM -0700, Florian Fainelli wrote:
quoted
On 04/30/2018 04:24 PM, Andrew Lunn wrote:
quoted
quoted
Turning these tests on will typically result in the link partner
dropping the link with us, and the interface will be non-functional as
far as the data path is concerned (similar to an isolation mode). This
might warrant properly reporting that to user-space through e.g: a
private IFF_* value maybe?
Hi Florian

I think a IFF_* value would be a good idea. We want to give the user
some indicate why they don't have working networking. ip link show
showing PHY-TEST-MODE would help.
IF_OPER_TESTING as defined in RFC 2863 looks like the correct way to
signal that. I did a quick test and setting operstate to
IFF_OPER_TESTING seems to correctly get reflected by iproute2/ifconfig
which no longer see RUNNING though the interface is still UP.
Hi Florian

I should really play with this.... but is the opstate printed by ip
link show? Not showing RUNNING is not the best hint something else is
going on. Actually saying TESTING somewhere is much clearer.
The operstate is settable and gettable from iproute2:

# ip link show gphy
4: gphy@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
switchid 00000000 state UP mode DEFAULT group default qlen 1000

# ip link set gphy state testing

Although the kernel refuses to allow user space to set it to something
different from up or down AFAICT. With my local hack to allow setting
operstate from user-space through sysfs, we do see that iproute2
correctly show it:

# echo 4 > /sys/class/net/gphy/operstate
# ip link show gphy
4: gphy@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue switchid 00000000 state TESTING mode DEFAULT group default
qlen 1000
    link/ether 00:10:18:de:38:1f brd ff:ff:ff:ff:ff:ff

but not from ifconfig. I was not too keen on adding a new IFF_* flag
because it usually means there was nothing else that could be done, and
it is disruptive to include/uapi/linux/if.h which I am afraid to break
(especially for non glibc systems).

Do you think that is acceptable? There are lots of things ifconfig can't
report, but at least, the state of the interface would not be "UP".
-- 
Florian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help