Re: [PATCH v2 2/2] sh_eth: add device tree support

[Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>]

Hello.

On 09/11/2013 12:07 AM, Stephen Warren wrote:

>>>>> Do you need any clocks properties, IP block reset signals, power
>>>>> domains?

>>>>      Currently not.

>>> What does "currently" mean? Does that mean that the Linux driver simply
>>> doesn't touch those entities at present?

>>     There's Ether clock but the driver doesn't manipulate it directly,
>> assumingly it does this thru the runtime PM interface. As for the
>> others, I simply don't know.

> If there's a clock, it should be represented in DT, even if the kernel
> somehow gets access to the clock through some means other than parsing DT.

    Frankly speaking, I don't see the point.

>>> If so, that's not enough to say
>>> that those entities should not be described in the DT binding. We should
>>> strive to make the binding completely describe all aspects of the HW,
>>> irrespective of whether a particular driver happens to use that
>>> information at present.

>>     There's no DT representation for the clocks in SH-Mobile subarch yet.
>> The same applies to the other entities you mentioned.

> You can still write the binding to say that the appropriate clock
> property must be present; the overall format of this property won't be
> affected by the representation chosen for the SH-Mobile clocks.

    Where can I find an example of such property, independent of the parent 
clock node? All I could find with quick search refers with a phandle to a 
clock node (we don't have now).

> It seems like it'd be best to get the basic resources (like clocks)
> represented in DT before trying to build blocks that use them.

    We don't use them directly. And we need the Ether device tree support 
*now*, while clock-related work will probably take months (there are plans to 
switch Sh-Mobile to CCF in like 6 months).

WBR, Sergei