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

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:55 Tue 17 Jul     , deepaksi wrote:
> 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.
this is not spear related but IP related this need to move the stmmac

IIRC I see it on other ST SoC

Best Regards,
J.