On Wed, Mar 25, 2020 at 03:04:07PM -0700, Florian Fainelli wrote:

On 3/25/2020 2:55 PM, Andrew Lunn wrote:

quoted

quoted

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