Requesting guidance on how to expose (new/exotic) PHY features to user-space

Requesting guidance on how to expose (new/exotic) PHY features to user-space

[Allan Nielsen]

Hi Andrew,

I'm working with Raju to create Open Source driver (and to get them accepted
upstream) for Microsemi PHYs.

First of all, thanks a lot for all the comments and all the help you (and
others) are providing. It is hard to see such a community working without people
like you - you are doing a great job :-D

Both Raju and I are used to hacking the Linux kernel, but it we are not used to
getting drivers accepted upstream - so as you can see, we are learning...

I think that a bit general guidance could help us producing better patches, and
thereby also save some of your time.

Before jumping to the questions, I like to explain the context we are coming
from. MSCC is (among many other things) designing PHY's and Switch fabrics. We
are creating and supporting both drivers and "turn-key like" SW both for the
PHYs and switches. We have mainly been using eCos for a long time, but ~1 year
ago we replaced eCos with Linux.

In the current SW model, most SW runs in user-space and is proprietary. But we
are working more and more in the direction of Open Sourcing certain part of the
SW, and the company is becoming more and more aware of the advantage of doing
open-source SW and getting it accepted upstream. In recent events we have
released the API (driver layer) for the user-space application under the MIT
license (covering a large range of PHYs and Switches).

The project Raju is working on is about getting support for some of the PHYs
accepted upstream.

One of the challenges that Raju (and I) is facing is that the ambitions is to
implement the same set of features in the upstream Linux driver as we
currently support in the MIT and proprietary version.

Features that already exists in some of the drivers should be okay. In these
cases it is just about adjusting our implementation to use the existing
configuration channels (IOCTL, various structs in phy.h, device-tree etc).

But we also have a hand-full of features that is hard to fit in, and we are
seeking some advice on how to handle those.

It typically boils down to finding a good way of exposing such a feature to a
given user-space application.

A good example of this could be a feature that internally is being called
VeriPHY. The idea of this is that the PHY can run some diagnostic and figure out
if there is a damage to the cable, and it can estimate where the damage is.

What is the preferred way of exposing such a feature??

Here are some of the options we have considered:

- Keeping such "exotic" features in user-space. This will require register
  access to the PHY from user-space. And as this feature is using "non-standard"
  pages we need something similar to SIOCGMIIREG/SIOCSMIIREG, but which supports
  registers in different pages.
- Adding new IOCTL's for exposing this feature.
- Add a netlink interface
- Add a sysfs interface

Please let me know what you think...

Best regards
Allan W. Nielsen

Re: Requesting guidance on how to expose (new/exotic) PHY features to user-space

[Andrew Lunn]

> In the current SW model, most SW runs in user-space and is proprietary. But we
> are working more and more in the direction of Open Sourcing certain part of the
> SW, and the company is becoming more and more aware of the advantage of doing
> open-source SW and getting it accepted upstream. In recent events we have
> released the API (driver layer) for the user-space application under the MIT
> license (covering a large range of PHYs and Switches).

Great it is open source. However, as a general rule of thumb, user
space drivers will not be accepted. You need to push this into the
kernel. DSA or switchdev for the switches, and phylib for the PHYs.

> The project Raju is working on is about getting support for some of
> the PHYs accepted upstream.

Which is great, and we are here to help.
 
> But we also have a hand-full of features that is hard to fit in, and we are
> seeking some advice on how to handle those.

Good that you are asking. It should stop you going off in the wrong
direction. Often it is "show us the code", but if you have little
experience with the linux architecture and how things are doing,
getting guidance early will be useful.

> It typically boils down to finding a good way of exposing such a
> feature to a given user-space application.

We need to be precises here. You need to expose an API to control the
feature or report on the result. The driver code is in the kernel.

> A good example of this could be a feature that internally is being
> called VeriPHY. The idea of this is that the PHY can run some
> diagnostic and figure out if there is a damage to the cable, and it
> can estimate where the damage is.

O.K, nothing unique or exotic. Marvell and Intel PHYs also have these
sort of features, and i'm sure others do too. They have just not yet
been exposed in a sensible way.

> What is the preferred way of exposing such a feature??

You need to define an API for exposing the results of the cable test
to userspace. This API needs to work for all vendors. i.e, you
probably want to get hold of some Marvell and Intel datasheets, look
at the Marvell DSDT, the in kernel Intel code. Work out what is
similar and different. Look around at the current
infrastructure. Could ethtool --test be extended? Something similar
added but for the PHY level?

This is going to be made harder in that there is a call to stop adding
new features to ethtool. It should be re-written using netlink. So you
might want to follow that discussion, get involved in it, see if
others think netlink is the right way to go, and what will the
replacement for ethtool look like?

Just to repeat again, the cable test code itself goes in the kernel,
in the phy driver. The user space code should work for all PHY
vendors.

I've interest in seeing the Marvell PHYs support these features, so
you can expect me to implement the Marvell version.

This is another part of being in the community. You cannot focus
purely on your own chips, when it comes to features others have. You
need to work on the shared infrastructure. It can be hard for
Management to get this, if they are new to open source. Why should i
help my competitor by implementing something they can use. Yet it
probably was your competitors which implemented the basic PHY
infrastructure, and you are benefiting from that. So it is your turn
to help, for the benefit of all.

	   Andrew