netdev - Re: [PATCH net-next 1/2] ethtool: add PHY Fast Link Down support

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190326082438.GB31524@lunn.ch>
Date:   Tue, 26 Mar 2019 09:24:38 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Michal Kubecek <mkubecek@...e.cz>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>,
        "John W. Linville" <linville@...driver.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/2] ethtool: add PHY Fast Link Down support

> > +#define ETHTOOL_PHY_FAST_LINK_DOWN_ON	0
> > +#define ETHTOOL_PHY_FAST_LINK_DOWN_OFF	0xff
> > +
> >  enum phy_tunable_id {
> >  	ETHTOOL_PHY_ID_UNSPEC,
> >  	ETHTOOL_PHY_DOWNSHIFT,
> > +	ETHTOOL_PHY_FAST_LINK_DOWN,
> >  	/*
> >  	 * Add your fresh new phy tunable attribute above and remember to update
> >  	 * phy_tunable_strings[] in net/core/ethtool.c
> 
> It would be nice to have a short summary around here explaining how is
> the value interpreted. While it's obvious from the second patch, one
> shouldn't have to go into driver specific implementation to find out.
> 
> I also wonder if the range 0-254 ms is sufficient. Would it be possible
> that there is some other hardware which would support e.g. 300 ms?

The default, as defined by the 802.3 standard, is i think 750ms.

The Marvel PHY also supports 50ms, 20ms and 0ms, if i remember
correctly.

One problem we have here is discovery. How does the user find out the
values the driver supports. For a netlink socket API, extended errors
could be used to pass back a string indicating the supported
values. For the old ethtool, i think all we have is -EINVAL, which is
not very helpful.

	Andrew