From: Kumar Gala <galak@kernel.crashing.org>
To: David Gibson <david@gibson.dropbear.id.au>,
Andy Fleming <afleming@freescale.com>
Cc: "linuxppc-dev@ozlabs.org list" <linuxppc-dev@ozlabs.org>,
Yoder Stuart-B08248 <stuart.yoder@freescale.com>
Subject: MDIO & phy device tree bindings (was Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port)
Date: Wed, 12 Sep 2007 10:08:53 -0500 [thread overview]
Message-ID: <E7F0FE04-5200-4295-9950-ECE387EB65C0@kernel.crashing.org> (raw)
In-Reply-To: <20070912035351.GF20218@localhost.localdomain>
David,
I'm splitting this up since the mdio & phy comments are more general
that the 8572.dts
>>> [snip]
>>>> + mdio@24520 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + device_type = "mdio";
>>>
>>> I don't think we actually have an mdio device_type binding defined.
>>
>> We've had this on 83xx/85xx/86xx device trees for a far amount of
>> time now. Look at section 2a in booting-without-of.txt
>
> Ah, so we have; sorry. Although the binding as it is currently
> written is pretty much pointless - it should actually define some
> mappings between dt properties / addresses and the standards defining
> the MDIO bus.x
that's a doc issue at this point
>>>> + compatible = "gianfar";
>>>
>>> This needs to be more specific. And it certainly shouldn't be the
>>> same compatible string as the ethernet MACs have.
>>
>> Why not its the same controller? Again, we've been doing this for
>> some period of time already.
>
> Yes you have, but it's still crap. 'compatible' should be sufficient
> to distinguish the driver needed for device nodes, but the MACs and
> MDIO should clearly have different drivers (or at least, different
> parts of a driver).
don't disagree will see about coming up with a better name, and
deprecating 'gianfar'.
>>>> + reg = <24520 20>;
>>>> + phy0: ethernet-phy@0 {
>>>> + interrupt-parent = <&mpic>;
>>>> + interrupts = <a 1>;
>>>> + reg = <0>;
>>>> + device_type = "ethernet-phy";
>>>
>>> Do we actually have an ethernet-phy device_type binding? If not, we
>>> should kill this. 'compatible' properties for phys would
>>> probably be
>>> a good idea, though (giving the actual phy model).
>>
>> Look section 2c in booting-without-of.txt
>
> Ah, yes. That one's a rather less redeemable pointless device_type
> binding. We should kill it from booting-without-of.txt.
agreed, will poke andy on this.
- k
next prev parent reply other threads:[~2007-09-12 15:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-11 19:37 [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port Kumar Gala
2007-09-12 3:11 ` David Gibson
2007-09-12 3:33 ` Kumar Gala
2007-09-12 3:53 ` David Gibson
2007-09-12 14:00 ` Segher Boessenkool
2007-09-12 15:08 ` Kumar Gala [this message]
2007-09-12 15:13 ` Kumar Gala
2007-09-12 14:10 ` Segher Boessenkool
2007-09-13 3:27 ` Kumar Gala
2007-09-12 13:36 ` Segher Boessenkool
2007-09-13 3:28 ` Kumar Gala
2007-09-13 4:21 ` David Gibson
2007-09-13 17:06 ` Segher Boessenkool
2007-09-13 18:24 ` Kumar Gala
2007-09-13 22:30 ` Segher Boessenkool
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=E7F0FE04-5200-4295-9950-ECE387EB65C0@kernel.crashing.org \
--to=galak@kernel.crashing.org \
--cc=afleming@freescale.com \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.org \
--cc=stuart.yoder@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).