public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ben Warren <biggerbadderben@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] TSEC Ethernet driver patch - RFC
Date: Tue, 15 Jan 2008 22:48:14 -0500	[thread overview]
Message-ID: <478D7E7E.2040303@gmail.com> (raw)
In-Reply-To: <36D7B34A3A79F84F82FA0C154F299F250672DFC9@E03MVX1-UKDY.domain1.systemhost.net>

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

  reply	other threads:[~2008-01-16  3:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-08 16:18 [U-Boot-Users] Possible TSEC Ethernet driver patch michael.firth at bt.com
2008-01-08 16:42 ` Ben Warren
2008-01-09 20:26   ` [U-Boot-Users] TSEC Ethernet driver patch - RFC michael.firth at bt.com
2008-01-15  9:59     ` michael.firth at bt.com
2008-01-15 13:03       ` David Saada
2008-01-15 15:36       ` Ben Warren
2008-01-15 16:56     ` Andy Fleming
2008-01-15 21:14       ` michael.firth at bt.com
2008-01-16  3:48         ` Ben Warren [this message]
2008-01-08 16:48 ` [U-Boot-Users] Possible TSEC Ethernet driver patch David Saada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=478D7E7E.2040303@gmail.com \
    --to=biggerbadderben@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox