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
