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.
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.