[PATCH V2 6/7] ARM: SPEAr13xx: Add auxdata for Ethernet controller.

[deepaksi]

Hi Arnd,


On 7/13/2012 7:52 PM, Arnd Bergmann wrote:
> On Friday 13 July 2012, viresh kumar wrote:
>> Adding Stefan and Peppe.
>>
>> I understand why you can't send all platform data from DT.
>> Let me elaborate the problem statement
>>
>> stmmac is used by platforms with and without DT.
>> - Without DT will pass platform data directly, without any issues.
>> - With DT have to pass all data, some of that via DT and other without
>> DT, like routines
>>    (atleast for now)
>>
>> For now what I suggest is, update DT support for whatever we can..
>> i.e. support Maximum
>> properties there. As finally we will support everything via DT, no
>> platform data.
>>
>> Whatever is left, that can't be passed via DT, like routine, pass it
>> from platform data
>> and merge both these versions of platform data in driver, keeping DT
>> ones in priority.
>>
>> i.e. Whatever is defined in DT properties must come from there and
>> left outs from
>> platform data.
> Absolutely agreed.
>
> The one part I think you both have wrong is the idea that the
> spear13xx_eth_phy_clk_cfg function is needed.
>
> I believe the correct answer for this is to introduce a driver for
> the phy in drivers/net/phy/, and have the phy be described correctly
> in the device tree and referenced found using the of_phy_find_device()
> function.

SPEAr platform has been using the generic phy framework, and it just 
requires a register into mdio
bus and provide the necessary callback w.r.t mdio read and write. These 
mdio read and write are more
into the GMAC registers, and hence a part of stmmac driver.

As far as my understanding is concerned, addition to the phy framework 
could have been done had it been
some phy from stmicro, which requires some special addressing to be done.
The function we are talking about is more related to handling the 
interface that phy has. The stmmac core has
been configured as rmii/smii/rgmii and requires the system to generate 
corresponding clock to support data
transfers over PHY.
This was specifically the reason of aligning the phy clock configuration 
function with stmmac driver, and could
well be taken as functional interface clock for mac core.
I do think that we should not add a new driver for aligning the clock 
settings of the interfaces.


Regards
Deepak



>
> 	Arnd
> .
>