Re: TSI ethernet PHY question

[Zang Roy-r61911 <tie-fei.zang@freescale.com>]

On Fri, 2007-05-25 at 10:00, David Gibson wrote:
> On Fri, May 25, 2007 at 01:54:35AM +0200, Segher Boessenkool wrote:
> > > For powerpc, I have a solution at hand, it's the device-tree :-)
> > >
> > > Any struct device in the system can have a device node pointer via
> the
> > > dev_sysdata thingy I added recently. So we can have some code for
> > > powerpc that properly hooks up the PHY to an (optional)
> device-node
> > > which can then contains properties describing what kind of
> workarounds
> > > need to be applied.
> > >
> > > For example, we can have a txc-rxc-delay-disable property on
> Holly.
> > 
> > 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.
> > 
> > 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.
> 
> Uh.. something to bear in mind is that although it is a board
> miswiring, it's of a type that it will plausibly occur in other
> boards.  IIRC, if a LED is attached to this PHY the workaround is
> necessary, or something similar.  So there is value in having a
> particular flag for this rather than just looking at the board model.
> 
But it is indeed a board specific issue. phylib is a good place. But we
should consider how can we pass this information to phylib. device tree
is a choice, but how about the platform not using device tree?

Roy