Re: TSI ethernet PHY question

[Segher Boessenkool <segher@kernel.crashing.org>]

> 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.

> 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.

> An option would be to instead use flags
> and have a piece of powerpc specific code that translates those
> device-tree properties into flags so that other archs can use the flags
> using their own ways of passing them in.

It really shouldn't ever be needed on any other board, but
sure.

> I'm not too hot with the flag stuff tho since those really need to be
> defined per PHY model/family. But I suppose that's fair enough.

Divide the flags arg into a generic and a chip-specific part?


Segher