Message-ID: <66E0C71AC771CF4297D4A99D55E55AB84EA675CA@avsrvexchmbx2.microsemi.net>
Date:   Mon, 19 Sep 2016 08:46:16 +0000
From:   Allan Nielsen <Allan.Nielsen@...rosemi.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Raju Lakkaraju <Raju.Lakkaraju@...rosemi.com>
Subject: Requesting guidance on how to expose (new/exotic) PHY features to
 user-space 

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

Powered by blists - more mailing lists