Fix problems with Holly's DT representation of ethernet PHYs

[Segher Boessenkool]

>>> Not that there's anything wrong with your
>>> reasoning.  Just seems like we're trying really hard to define
>>> something
>>> "correctly" when we control what's on both sides :).
>>
>> Right now, and in your case, you do.  OTOH, the
>> goal is to have the DTS be a well-established
>> stable interface between the firmware/bootloader/
>> bootwrapper and the kernel; there is no room for
>> either side of that interface playing dirty tricks,
>> not on any board ;-)
>>
>> Also, the DTS files in the kernel source tree should
>> server as a best-of-breed example for people doing
>> custom device trees for their own boards.  We better
>> whip them into good shape or we'll all look foolish...
>
> Yeah, I know.  Ignore my earlier email.  I blame it on lack of sleep.
>
> The only issue we might have in the future is if DT capable firmware 
> for
> these boards shows up and does something completely different.

Yeah, that's exactly the same problem as we would have
if we would code our device trees without trying to at
least create an informal binding for the nodes in question:
total chaos.

> Hopefully that won't happen.

Hopefully, indeed.

If a third party constructs a board with some weird
device tree, then they probably have a big set of Linux
patches to go with that.  Now either they work with the
kernel community to get that integrated into mainline
(which means they need to do a lot of changes to the DTS
as well if it indeed is weird / wrong, so they better
start doing that *before* selling the boards); or they
can happily maintain their own kernel fork, like so many
companies already do.

I don't see a problem here :-)


Segher