Re: TSI ethernet PHY question

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

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