(adding devicetree@xxxxxxxxxxxxxxx) On Tue, Aug 13, 2013 at 11:42:36AM -0500, dinguyen@xxxxxxxxxx wrote: > From: Dinh Nguyen <dinguyen@xxxxxxxxxx> > > Convert the Micrel PHY driver to use OF. This initial patch is only > the beginning of an idea to convert the PHY driver to device tree. > > Signed-of-by: Dinh Nguyen <dinguyen@xxxxxxxxxx> > Cc: netdev@xxxxxxxxxxxxxxx > Cc: Richard Cochran <richardcochran@xxxxxxxxx> > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> > Cc: Felipe Balbi <balbi@xxxxxx> > Cc: David S. Miller <davem@xxxxxxxxxxxxx> > Cc: Giuseppe Cavallaro <peppe.cavallaro@xxxxxx> > Cc: Olof Johansson <olof@xxxxxxxxx> > Cc: Rob Herring <rob.herring@xxxxxxxxxxx> > > --- > Hello, > > I would like to solicit comments on the need to convert the ethernet PHY > drivers to use OF/device trees? For the platform that I'm interested in, > SOCFPGA, it is using the stmicro ethernet driver. It has a Micrel PHY > on the board. The only way that I know of how to change the skew settings > for the phy is through a board level initialization. > > One of the ARM maintainers suggested that perhaps refactoring the ethernet > driver to use device tree would be nice. But that would not help me with > configuring the PHY settings. > > So a little investigation led me to believe that refactoring the /net/phy > drivers into a device tree implementation would help greatly. I was thinking > it could be done like the pinctrl or some of the usb/phy driver. > > Since I am only familiar with the ARM SoC space, I want to make sure that > this idea is right approach. I can start with the micrel PHY driver > first, as that is the only HW I have access to. Hi, Sorry for the slow reply here. I don't think this is quite the right approach. What you want to do is to make the phy devices register based on device tree contents, which also means removing the run function, or rather moving it to a generic run function in the phy subsystem that acts based on device tree contents instead of a hard-coded per-board run function. It sounds like defining that binding might end up getting complicated. I suggest you consider recruiting some of the more seasoned devicetree folks on this endeavor. It's possible that you'll mostly have per-vendor/phy type properties to tune the various settings, but it's also likely that you will have some generic and shared (optional) properties such as gpios for resetting, or regulators for powering, the phy. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
