linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] ARM: mvebu: NETGEAR ReadyNAS 104 .dts file cleanup
Date: Tue, 03 Dec 2013 21:31:03 -0600	[thread overview]
Message-ID: <529EA1F7.7040201@gmail.com> (raw)
In-Reply-To: <20131122213610.GC30358@obsidianresearch.com>

On 11/22/2013 03:36 PM, Jason Gunthorpe wrote:
> On Fri, Nov 22, 2013 at 09:07:01PM +0100, Arnaud Ebalard wrote:
>>  			mdio {
>>  				phy0: ethernet-phy at 0 {
>> +					compatible = "marvell,88e1318s";
>>  					reg = <0>;
>>  				};
>>  
>>  				phy1: ethernet-phy at 1 {
>> +					compatible = "marvell,88e1318s";
>>  					reg = <1>;
>>  				};
>>  			};
> 
> Just an inquiry, are these compatible strings OK?
> 
> Documentation/devicetree/bindings/net/phy.txt doesn't really give
> guidance.
> 
> For self-discoverable busses I would expect to see a structured
> compatible string, or property, that encodes the phy-id - such as what
> the PCI binding does with vid/did:
> 
> "compatible" Construct a list of names in most-specific to
>              least-specific order. The names shall be derived from
> 	     values of the Vendor ID, Device ID, Subsystem Vendor ID,
> 	     Subsystem ID, Revision ID and Class Code bytes, and shall
>              have the following form, and be placed in the list in the
>              following order:
> 
>   pciVVVV,DDDD.SSSS.ssss.RR (1)
> 
> So, I would think something like this:
> 
> compatible = "ethernet-phy-id0141,0e90"; /* Marvell 88E1318 */
> 
> ?
> 
> A big rational for this is that the kernel already has complete
> infrastructure for matching drivers to the numeric phy-id.
>
> I have a small patch to make the OF mdio bus scanner get the phy-id
> from DT. I didn't use compatible string in this patch, but it would be
> easy to change, and this demonstrates what we could do with a
> structured compatible string (attached).
> 
> Grant? Rob? I could make some patches for this if you agree.

Seems like a reasonable approach.

Rob

> 
> Regards,
> Jason
> 
> From 1aab2047b6dfb8b814673718dfa7ef0ea0c7a0ef Mon Sep 17 00:00:00 2001
> From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> Date: Thu, 12 Sep 2013 17:36:13 -0600
> Subject: [PATCH] of_mdio: Allow the DT to specify the phy ID and avoid
>  autoprobing
> 
> This makes the generic of_mdiobus_register parse the DT property
> 'phy-id'. If present it should be the numeric constant that matches the
> phy-id register normally readable through MDIO.
> 
> When the ID is given the phy autoprobing is defeated and the phy is
> created directly.
> 
> This is necessary to support phy's that cannot be autoprobed when
> of_mdiobus_register is called. Specifically, my case has the phy in
> reset at that time, the reset is only released once the ethernet
> driver starts.
> 
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
>  drivers/of/of_mdio.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index d5a57a9..dbe6932 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -81,7 +81,12 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
>  
>  		is_c45 = of_device_is_compatible(child,
>  						 "ethernet-phy-ieee802.3-c45");
> -		phy = get_phy_device(mdio, addr, is_c45);
> +		paddr = of_get_property(child, "phy-id", &len);
> +		if (paddr && len <= sizeof(*paddr) && !is_c45)
> +			phy = phy_device_create(mdio, addr, be32_to_cpup(paddr),
> +						0, NULL);
> +		else
> +			phy = get_phy_device(mdio, addr, is_c45);
>  
>  		if (!phy || IS_ERR(phy)) {
>  			dev_err(&mdio->dev,
> 

  parent reply	other threads:[~2013-12-04  3:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-22 20:04 [PATCH 0/4] ARM: mvebu/kirkwood: NETGEAR ReadyNAS .dts files cleanup Arnaud Ebalard
2013-11-22 20:05 ` [PATCH 1/4] kirkwood: NETGEAR ReadyNAS Duo v2 .dts file cleanup Arnaud Ebalard
2013-11-22 20:06 ` [PATCH 2/4] ARM: mvebu: NETGEAR ReadyNAS 102 " Arnaud Ebalard
2013-11-22 20:07 ` [PATCH 3/4] ARM: mvebu: NETGEAR ReadyNAS 104 " Arnaud Ebalard
2013-11-22 21:36   ` Jason Gunthorpe
2013-11-22 22:22     ` Arnaud Ebalard
2013-11-25 19:41       ` Jason Gunthorpe
2013-11-25 22:03         ` Arnaud Ebalard
2013-11-25 22:08           ` Jason Gunthorpe
2013-12-04  3:31     ` Rob Herring [this message]
2013-11-22 20:07 ` [PATCH 4/4] ARM: NETGEAR ReadyNAS Duo v2 and RN102 .dts file whitespace cleanup Arnaud Ebalard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=529EA1F7.7040201@gmail.com \
    --to=robherring2@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).