TSI ethernet PHY question
Segher Boessenkool
segher at kernel.crashing.org
Sat May 26 00:24:10 EST 2007
>> However in this case you could put a property in the
>> PHY node, similar things have been done before. It's
>> ugly and doesn't solve any problem (it is just as much
>> work to parse the board model as to find this magic
>> property), and you *still* should pass in the flag
>> from the platform layer, and not have the phylib try
>> to handle it by itself.
>
> I disagree, it's not ugly and nicely solves the problem.
It doesn't solve the conceived problem that making this
a board-dependent workaround would be "too hard".
> For example, imagine you have 2 PHYs on a board and only one needs the
> workaround ? Really, the PHY node is the best place for it.
Then the board code will know that.
>> The ethernet driver is a powerpc-specific driver, that's
>> one thing. Also, the workaround should be initiated by
>> the platform code, so has to go through the ethernet driver
>> (since it instantiates the phylib driver).
>
> Still... it can be done via generic calls in powerpc ethernet drivers
> that set flags in phylib based on things in the device-tree.
Yes, exactly.
>> For many similar workarounds, the ethernet driver _does_ have
>> to cooperate in the workaround. For some other such workarounds,
>> the soc code has to be involved. Etc. etc.
>
>> You can do a quick "fix" now by doing this magic property
>> thing, and it sure is a *quick* fix; but later on you'll
>> have to do some other workarounds the proper way. And
>> you'll be stuck with the property forever. Not such a
>> big deal, sure; hey, I already _did_ say I'm okay with it,
>> right? It's just the "wrong" thing to do ;-)
>
> I have no bloody idea what you consider "the proper way"
Make board-specific workarounds triggered by the board code.
> I think it's the right thing to do.
And I don't :-) But I already said I'm okay with it, it's
only one property and it won't hurt anything else.
Segher
More information about the Linuxppc-dev
mailing list