netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Fleming Andy-AFLEMING <afleming@freescale.com>
Cc: John Linn <John.Linn@xilinx.com>,
	devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
	netdev <netdev@vger.kernel.org>,
	Scott Wood <scottwood@freescale.com>
Subject: Re: phy address in the device tree, vs auto probing
Date: Wed, 10 Feb 2010 12:20:14 -0700	[thread overview]
Message-ID: <fa686aa41002101120v56ef5e7cm64e5505cc7bedc1d@mail.gmail.com> (raw)
In-Reply-To: <AE7D03BA-0763-42F3-A27B-A6214CE7249E@freescale.com>

On Wed, Feb 10, 2010 at 11:40 AM, Fleming Andy-AFLEMING
<afleming@freescale.com> wrote:
>
>
> On Feb 10, 2010, at 12:15, "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
>> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@xilinx.com> wrote:
>>>>
>>>> -----Original Message-----
>>>> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
>>>> Grant Likely
>>>> Sent: Wednesday, February 10, 2010 9:44 AM
>>>> To: John Linn; devicetree-discuss; netdev
>>>> Subject: Re: phy address in the device tree, vs auto probing
>>>>
>>>> (cc'ing devicetree-discuss and netdev mailing lists)
>>>>
>>>> On Tue, Feb 9, 2010 at 4:23 PM, John Linn <John.Linn@xilinx.com> wrote:
>>>>>
>>>>> Hi Grant,
>>>>>
>>>>> I notice that the OF driver for the mdio bus is not doing auto probing.
>>>>>
>>>>> As we start putting in the phy layer in the emac drivers, the device
>>>>> trees tend to have the phy address in them, but we're not sure we
>>>>> really
>>>>> like that.
>>>>>
>>>>> We really think that being able to let the kernel find the phy address
>>>>> is a big benefit, otherwise this is one other piece of info the user
>>>>> has
>>>>> to know and get right.
>>>>>
>>>>> Am I missing something here?
>>>>
>>>> No, you're not really missing something, but there is an inherent
>>>> complexity in what you're wanting to do.  Like i2c, MDIO is one of
>>>> those busses that is hard to probe reliable.  Some PHYs respond on
>>>> more than one address, and there is no way to determine which MAC a
>>>> PHY is wired up to.  Many PHYs can live on a single MDIO bus.  MACs
>>>> with their own MDIO busses may still get wired to a PHY on a different
>>>> bus.
>>>>
>>>> In the simple case where there is a one:one:one relationship between
>>>> MAC, MDIO bus and PHY, then it should be okay to probe the PHY,
>>>> correct?  The question then must be asked; how does the kernel
>>>> determine that it can use the simple case?  Nobody has yet defined a
>>>> way to describe that in the device tree; mostly because nobody has
>>>> needed to yet.
>>>>
>>>> So, it is possible to do what you want, but you need a way to
>>>> *explicitly* ask for that behaviour.  ie, some way to indicate in a
>>>> MAC node which MDIO bus the phy is on, and that the phy needs to be
>>>> probed for.  I think this should only be an option when the MDIO bus
>>>> has only one PHY.  Come up with a proposal and post it to the
>>>> devicetree-discuss mailing list.
>>>
>>> Here's a couple ideas. See what everyone thinks as I'm not stuck on
>>> either.
>>>
>>> Thanks,
>>> John
>>>
>>> 1. What if we just don't specific a phy address with a reg property which
>>> would specify to auto probe it and find the phy as illustrated below?
>>>
>>>
>>>               Ethernet_MAC: ethernet@81000000 {
>>>                       #address-cells = <1>;
>>>                       #size-cells = <1>;
>>>                       phy-handle = <&phy0>;
>>>                       mdio {
>>>                               #address-cells = <1>;
>>>                               #size-cells = <0>;
>>>                               phy0: phy@7 {
>>>                               } ;
>>>                       } ;
>>>
>>> 2. Or a special value (-1 or something not 0 - 31) in the phy address
>>> that specifies to auto probe as illustrated below.
>>>                               phy0: phy@7 {
>>>                                       reg = <-1>;
>>>                               } ;
>>
>> I don't like abusing the reg property in this way.  I wonder if a new
>> empty property would be a better way to indicate this.  Maybe
>> "phy-probe-address;"?  It would also be important to specify in the
>> binding that only one phy node is allowed when phy-probe-address is
>> used.
>
> I don't think it's necessary that only one phy node is there.  I don't think
> the of mdio layer should set policy, here.  Some drivers hard code their
> addresses.  Some drivers assume (foolishly, I think) that the PHYs are in
> order.  Many assume there's only one PHY.  I think the mdio driver should
> set policy, so of_mdio should just allow for PHYs to be probed.  I'm
> actually not sure that requires any changes.  Quite possibly this just means
> that of_mdio is not appropriate for such a driver.   The standard PHY code
> supports this sort of thing.

That still doesn't solve the problem of matching PHYs to MACs.

Consider this example:  2 MACs, 2 PHYs.  mac_a--> phy_a and mac_b -->
phy_b.  Both phys on the same mdio bus, described thus:

               eth_a: ethernet@81000000 {
                       #address-cells = <1>;
                       #size-cells = <1>;
                       phy-handle = <&phy_a>;
                       mdio {
                               #address-cells = <1>;
                               #size-cells = <0>;
                               phy_a: phy_a {
                               } ;
                               phy_b: phy_b {
                               } ;
                       } ;
               } ;
               eth_b: ethernet@82000000 {
                       #address-cells = <1>;
                       #size-cells = <1>;
                       phy-handle = <&phy_b>;
               } ;

In this example, the kernel knows it has two phys, and probing
confirms this (say at phy addresses 3 and 7).  How does the kernel
know which address phy_a responds to?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2010-02-10 19:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Acqp3tpO+gBYUakZQ7SaeBzVIkh6WA==>
     [not found] ` <4dfe033d-c308-45e0-9c7e-9fc60c6cad8f@SG2EHSMHS013.ehs.local>
     [not found]   ` <4dfe033d-c308-45e0-9c7e-9fc60c6cad8f-RaUQJvECHivT7m58JnLnSLjjLBE8jN/0@public.gmane.org>
2010-02-10 16:43     ` phy address in the device tree, vs auto probing Grant Likely
2010-02-10 16:52       ` John Linn
2010-02-10 18:14         ` Grant Likely
     [not found]           ` <fa686aa41002101014s43682e3cra55854b82a40bb5f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-02-10 18:28             ` Scott Wood
     [not found]               ` <4B72FAB2.5000804-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2010-02-10 18:37                 ` M. Warner Losh
2010-02-10 19:12                   ` Grant Likely
2010-02-10 19:24                     ` Mark Brown
2010-02-10 18:30           ` Mitch Bradley
     [not found]             ` <4B72FB38.7080909-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2010-02-10 18:35               ` Mitch Bradley
2010-02-10 18:40           ` Fleming Andy-AFLEMING
2010-02-10 19:20             ` Grant Likely [this message]
2010-02-10 19:46               ` Andy Fleming
2010-02-10 19:57                 ` Grant Likely

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=fa686aa41002101120v56ef5e7cm64e5505cc7bedc1d@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=John.Linn@xilinx.com \
    --cc=afleming@freescale.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=scottwood@freescale.com \
    /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).