From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Tue, 15 Jan 2008 22:48:14 -0500 Subject: [U-Boot-Users] TSEC Ethernet driver patch - RFC In-Reply-To: <36D7B34A3A79F84F82FA0C154F299F250672DFC9@E03MVX1-UKDY.domain1.systemhost.net> References: <36D7B34A3A79F84F82FA0C154F299F250672DFC9@E03MVX1-UKDY.domain1.systemhost.net> Message-ID: <478D7E7E.2040303@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Michael, michael.firth at bt.com wrote: >> -----Original Message----- >> From: Andy Fleming [mailto:afleming at gmail.com] >> Sent: 15 January 2008 16:56 >> To: Firth,MJC,Michael,DMJ R >> Cc: biggerbadderben at gmail.com; u-boot-users at lists.sourceforge.net >> Subject: Re: [U-Boot-Users] TSEC Ethernet driver patch - RFC >> >> On Jan 9, 2008 2:26 PM, wrote: >> >> So, for the most part, I'm happy with this change. I suspect >> that I over-engineered it, originally, anticipating the >> possibility that a future part might make use of the other >> mdio interfaces. >> >> The biggest problem I see is that the TBI PHYs, which are >> internal to each TSEC, are accessed through the other mdio >> interfaces. Right now this isn't really supported, but >> there's a desire to expose these, since they are used for >> SGMII configuration. I hadn't yet figured out the best way >> to do that, but this change would potentially make it more difficult. >> >> Ideally, we would stop referring to PHYs only by address on the bus. >> There could be multiple busses (and, in fact, there are), so >> the ideal solution would deal with that. But that's a hefty >> task (which I'm hoping Ben finds time for), so I'm not really >> suggesting that for the short term. For now it's probably >> fine as long as it doesn't make Ben's job harder. But it's >> not really changing the higher-level interface, so that >> should be ok, too. >> >> > I guess a middle option is to make the two options (multi MDIO bus > support versus > the ability to access all devices on a single MDIO bus) available via a > configuration option. > > I think the way to do this from my patch is to instead retain the > 'get_priv_for_phy' function > within a #ifdef for the configuration option, and select whether to call > the function or always > use the first TSEC instance, again based on the #define. > > Given that, as you said, several people, have suggested that the whole > PHY support in U-Boot > needs an overhaul, another question is whether any support for the > internal PHYs is likely to > be implemented before this overhaul. > > I guess that if the old functionality is still available within the > code, then, when the TBI > support is implemented then the person that does that has easy access to > all the code options. > > Regards > > Michael > > I like your patch as-is, and would like to apply it. Can you please re-send it properly formatted? I agree that we'll need to identify PHYs by more than just an address. In addition to the TBI example that Andy mentioned, MDIO can also be bit-banged and I don't see any reason to artificially limit how devices are accessed. Regarding the PHY overhaul, for various non-technical reasons it's going slower than I'd hoped. The plan is to make it part of the next release cycle, which I guess will close in a couple of months. Hopefully patches will dribble in over the next few weeks. thanks, Ben