On Wed, Mar 4, 2009 at 3:38 AM, Anton Vorontsov
<avoront...@ru.mvista.com> wrote:
> Currently it doesn't matter where the mdio nodes are placed, but with
> power management support (i.e. when sleep = <> properties will take
> effect), mdio nodes placement will become important: mdio controller
> is a part of the ethernet block, so the mdio nodes should be placed
> correctly. Otherwise we may wrongly assume that MDIO controllers are
> available during sleep.
>
> Suggested-by: Scott Wood <scottw...@freescale.com>
> Signed-off-by: Anton Vorontsov <avoront...@ru.mvista.com>
> ---
>
> On Tue, Mar 03, 2009 at 12:39:38PM -0600, Scott Wood wrote:
>> Anton Vorontsov wrote:
>>> On Tue, Mar 03, 2009 at 11:57:46AM -0600, Scott Wood wrote:
>>>> On Tue, Mar 03, 2009 at 07:02:01PM +0300, Anton Vorontsov wrote:
>>>>> m...@24520 {
>>>>> @@ -226,6 +244,8 @@
>>>>> interrupt-parent = <&ipic>;
>>>>> tbi-handle = <&tbi0>;
>>>>> phy-handle = <&phy2>;
>>>>> + sleep = <&pmc 0xc0000000>;
>>>>> + fsl,magic-packet;
>>>>> };
>>>> Note that this makes it look to the kernel like enet0 can be put to sleep
>>>> without putting the mdio (which is shared with enet1) to sleep. This is
>>>> why I moved mdio under the ethernet node on 8313erdb.
>>>
>>> And that isn't absolutely correct either, since enet1 depends on
>>> net0... If enet0's mdio goes into sleep mode before enet1, then
>>> enet1 will fail to send power-down command to its PHY...
>>
>> But the kernel knows that enet1 depends on mdio0. Getting the kernel to
>> act on that knowledge isn't the device tree's problem.
>
> Well, that makes sense. I'd like to move mdio nodes in a separate
> patch though, since the original patch becomes difficult to review
> because of too many changes...
>
> A question though... do we want real addr translation via ranges, or
> the dummy "ranges;" are OK?
>
> Here is the RFC. It's tested to work on MPC8377-RDB.
Last time I brought up a similar issue with a MPC8313 patch. Looks
like the consensus is that we shouldn't use compatible = "simple-bus"
for gianfar nodes.
- Leo
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
