[U-Boot-Users] TSEC Ethernet driver patch - RFC

Ben Warren
2008-01-16T03:48:14Z

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, <michael.firth@bt.com> 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