netdev - Re: RFC: future of ethtool tunables (Re: [RFC][PATCH 1/2] ethtool: Add BroadRReach Master/Slave PHY tunable)

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: <20200325234230.GD31519@unicorn.suse.cz>
Date:   Thu, 26 Mar 2020 00:42:30 +0100
From:   Michal Kubecek <mkubecek@...e.cz>
To:     netdev@...r.kernel.org
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>, Marek Vasut <marex@...x.de>,
        o.rempel@...gutronix.de, Guenter Roeck <linux@...ck-us.net>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jean Delvare <jdelvare@...e.com>,
        Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>
Subject: Re: RFC: future of ethtool tunables (Re: [RFC][PATCH 1/2] ethtool:
 Add BroadRReach Master/Slave PHY tunable)

On Wed, Mar 25, 2020 at 03:04:07PM -0700, Florian Fainelli wrote:
> 
> 
> On 3/25/2020 2:55 PM, Andrew Lunn wrote:
> >> What might be useful, on the other hand, would be device specific
> >> tunables: an interface allowing device drivers to define a list of
> >> tunables and their types for each device. It would be a generalization
> >> of private flags. There is, of course, the risk that we could end up
> >> with multiple NIC vendors defining the same parameters, each under
> >> a different name and with slightly different semantics.
> >  
> > Hi Michal
> > 
> > I'm not too happy to let PHY drivers do whatever they want. So far,
> > all PHY tunables have been generic. Any T1 PHY can implement control
> > of master/slave, and there is no reason for each PHY to do it
> > different to any other PHY. Downshift is a generic concept, multiple
> > PHYs have implemented it, and they all implement it the same. Only
> > Marvell currently supports fast link down, but the API is generic
> > enough that other PHYs could implement it, if the hardware supports
> > it.
> > 
> > I don't however mind if it gets a different name, or a different tool,
> > etc.
> 
> BroadRReach is a standard feature that is available on other PHYs for
> instance (Broadcom at least has it too) so defining a common name for
> this particular tunable knob here would make sense.
> 
> If we are to create vendor/device specific tunables, can we agree on a
> namespace to use, something like:
> 
> <vendor>:<device>:<parameter name>

That's not exactly what wanted to know. From my point of view, the most
important question is if we want to preserve the concept of tunables as
assorted parameters of various types, add netlink requests for querying
and setting them (plus notifications) and keep adding new tunables. Or
if we rather see them as a temporary workaround for the lack of
extensibility and handle all future parameters through regular command
line arguments and netlink attributes.

For the record, I can imagine that the answer might be different for
(netdev) tunables and for PHY tunables.

Michal