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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.