[PATCH net-next RFC 0/5] net: phy: Introduce a port representation

[Andrew Lunn]

> What I think we both fear is having a complex DT description of a
> port that the kernel mostly ignores. While we can come out with the
> "but DT describes the hardware" claptrap, it's no good trying to
> describe the hardware in a firmware description unless there is some
> way to validate that the firmware description is correct - which
> means there must be something that depends on it in order to work.
> 
> If we describe stuff that doesn't get used, there's no way to know
> if it is actually correct. We then end up with a lot of buggy DT
> descriptions with properties that can't be relied upon to be
> correct, and that makes those properties utterly useless.

This is a real issue we have had in the past. A property which was
ignored, until it was not ignored, and then lots of boards broke
because they had the property wrong.

I would strongly recommend than any property you define is always
used, validated, and ideally will not work when wrong.

      Andrew