Re: [RFC] phy: micrel: Convert micrel PHY driver to use OF

Re: [RFC] phy: micrel: Convert micrel PHY driver to use OF

[Linus Walleij]

On Tue, Aug 13, 2013 at 6:42 PM,  <dinguyen@altera.com> wrote:

> From: Dinh Nguyen <dinguyen@altera.com>
>
> 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@altera.com>

This is full of device tree stuff so please copy it to
devicetree@vger.kernel.org.

It seems to add quite a few compatible strings so these should
be added to the bindings doc, or is it already?

Yours,
Linus Walleij

Re: [RFC] phy: micrel: Convert micrel PHY driver to use OF

[Dinh Nguyen]

On Thu, 2013-08-15 at 21:55 +0200, Linus Walleij wrote:
> On Tue, Aug 13, 2013 at 6:42 PM,  <dinguyen@altera.com> wrote:
> 
> > From: Dinh Nguyen <dinguyen@altera.com>
> >
> > 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@altera.com>
> 
> This is full of device tree stuff so please copy it to
> devicetree@vger.kernel.org.
> 
> It seems to add quite a few compatible strings so these should
> be added to the bindings doc, or is it already?

No, there is not a bindings doc yet. I was just trying to see if this is
the right approach..

Thanks,
Dinh
> 
> Yours,
> Linus Walleij
> 

Re: [RFC] phy: micrel: Convert micrel PHY driver to use OF

[Olof Johansson]

(adding devicetree@vger.kernel.org)


On Tue, Aug 13, 2013 at 11:42:36AM -0500, dinguyen@altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
> 
> 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@altera.com>
> Cc: netdev@vger.kernel.org
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Rob Herring <rob.herring@calxeda.com>
> 
> ---
> 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

Re: [RFC] phy: micrel: Convert micrel PHY driver to use OF

[Sascha Hauer]

On Wed, Aug 21, 2013 at 10:13:47PM -0700, Olof Johansson wrote:
> (adding devicetree@vger.kernel.org)
> 
> 
> On Tue, Aug 13, 2013 at 11:42:36AM -0500, dinguyen@altera.com wrote:
> > ---
> > 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.

This patch recently was merged:

http://patchwork.ozlabs.org/patch/268661/

It solves exactly the same problem of specifying the skew settings.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] phy: micrel: Convert micrel PHY driver to use OF

[Dinh Nguyen]

On Thu, 2013-08-22 at 08:34 +0200, Sascha Hauer wrote:
> On Wed, Aug 21, 2013 at 10:13:47PM -0700, Olof Johansson wrote:
> > (adding devicetree@vger.kernel.org)
> > 
> > 
> > On Tue, Aug 13, 2013 at 11:42:36AM -0500, dinguyen@altera.com wrote:
> > > ---
> > > 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.
> 
> This patch recently was merged:
> 
> http://patchwork.ozlabs.org/patch/268661/
> 
> It solves exactly the same problem of specifying the skew settings.

Thanks for the information. This is great stuff!

Dinh
> 
> Sascha
>