> (2) Krzysztof pointed out that there is still the issue raised by
> Rob, that the schemas haven't any compatible and cannot be
> validated. I think that applies to all the network PHY bindings
> in the tree right now. I don't know how to fix them.
i've been offline for a while, i sabotaged my own mail server...
You can always add an unneeded compatible, using the PHY devices ID:
- pattern: "^ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$"
description:
If the PHY reports an incorrect ID (or none at all) then the
compatible list may contain an entry with the correct PHY ID
in the above form.
The first group of digits is the 16 bit Phy Identifier 1
register, this is the chip vendor OUI bits 3:18. The
second group of digits is the Phy Identifier 2 register,
this is the chip vendor OUI bits 19:24, followed by 10
bits of a vendor specific ID.
It would be fine to do this in the example in the binding, but i would
add a comment something like:
"Compatible generally only needed to make DT lint tools work. Mostly
not needed for real DT descriptions"
Examples often get cut/paste without thinking, and we don't really
want the compatible used unless it is really needed.
This is however a bigger problem than just PHYs. It applies to any
device which can be enumerated on a bus, e.g. USB, PCI. So maybe this
limitation of the DT linting tools should be fixed once at a higher
level?
> (3) The main problem with the broken interrupt handling of the PHY
> is that it will disturb other devices on that interrupt line.
> IOW if the interrupt line is shared the PHY should fall back
> to polling mode. I haven't found anything in the interrupt
> subsys to query if a line is shared and I guess it's also
> conceptually impossible to do such a thing, because there
> might be any driver probed at a later time which also uses
> that line.
> Rob had the idea to walk the device tree and determine if
> a particular interrupt is used by other devices, too. If
> feasable, this sounds like a good enough heuristic for our
> problem. Although there might be some edge cases, like
> DT overlays loaded at linux runtime (?!).
My humble opinion is that it is not worth the complexity for just one
PHY which should work in polling mode without problems. I think the
boolean property you propose is KISS and does what is needed.
Andrew
