TSI ethernet PHY question
Benjamin Herrenschmidt
benh at kernel.crashing.org
Fri May 25 10:01:11 EST 2007
On Fri, 2007-05-25 at 01:54 +0200, Segher Boessenkool wrote:
> This is equivalent to the ethernet driver passing this information
> to phylib via the init arguments.
>
> You still have the same problems as Andy described where the
> necessary workaround is not something local to phylib, but
> needs cooperation of the ethernet code or the soc code or
> some other platform code.
If it's in the PHY device node, the ethernet driver doesn't need to be
involved more than calling some generic helper that finds the right
node, parses it and generates known flags.
> Since the specific bug we're talking about here is not a
> problem with the PHY, but a miswiring on the board, I wouldn't
> put a flag for the workaround in the phy node in the device
> tree. It certainly is an option though.
Why ? That's the perfect place to put it in !
> > The problem is that of course the PHY driver will need some powerpc
> > specific code to go fetch that.
>
> The ethernet driver can handle it, instead.
I don't understand why you want to involve the ethernet driver in
something that doesn't have much to do with it. A pin of the PHY is
miswired causing something to be enabled that shouldn't be. Ok, there is
indeed the fact that the problem is partially related to the TSI
ethernet not supporting when that PHY feature is "enabled" but still...
it's a PHY setting, totally specific to a given PHY revision, I'm not
sure there's much point in having it in the eth driver.
Ben.
More information about the Linuxppc-dev
mailing list