From mboxrd@z Thu Jan 1 00:00:00 1970 From: plagnioj@jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD) Date: Tue, 17 Jul 2012 12:41:06 +0200 Subject: [PATCH V2 6/7] ARM: SPEAr13xx: Add auxdata for Ethernet controller. In-Reply-To: <50053DB5.1010704@st.com> References: <214127499f10b0099e6f3542e1e879fdd8c1bdcf.1342171151.git.vipulkumar.samar@st.com> <201207131422.26274.arnd@arndb.de> <50053DB5.1010704@st.com> Message-ID: <20120717104106.GA2629@game.jcrosoft.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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.