>>> + Required properties: >>> + - device_type : should be "usb". >> No device_type please. The published USB binding doesn't define >> one on purpose. > > Could you please, explain why? > Sorry, I don't think I get the concept of device description here.
"device_type" is meant to be used only by OF for determining the OF programming model for a device. No such thing has been defined for USB busses, so the USB binding does not define a "device_type" either. Nothing in a flat device tree should ever define a device_type, except perhaps for compatibility with legacy kernel code. >>> + - compatible : should be "ehci". >> Just "ehci" isn't enough -- compare to OHCI, which is the name for >> a kind of USB host controller as well as for a kind of Firewire >> host controller. > > Actually, I though device type="usb" + compatible="ehci" would be > enough. "compatible" values are their own namespace, you should in principle be able to find a driver for a device with them without having to look at other properties. >> Maybe "usb-ehci" is best -- can anyone think of a better name? > > Again, why not type="usb", compatible="ehci"? Because an OF client (i.e., the Linux kernel) is not supposed to use "device_type" at all for its own driver matching. >>> + - interrupts : <a b> where a is the interrupt number and b is a >>> + field that represents an encoding of the sense and level >>> + information for the interrupt. >> This is incorrect; not all interrupt domains use two cells, and >> not all that do have this meaning for those cells. > > Well, this was just copied from other descriptions in > Documentation/powerpc/booting-without-of.txt > Do we need to fix them all? Sounds like it, yes. >>> + If device registers are implemented in big endian mode, the device >>> + node should have "big-endian" property. >>> + If controller implementation operates with big endian descriptors, >>> + compatible should also have "ehci-be-desc" >> Ah, I understand what this is about, finally. >> Don't put this in "compatible"; instead, do a "big-endian-descriptors" >> property similar to the "big-endian" property. That last one should >> maybe be "big-endian-registers" here then, to avoid confusion. >> Or make "big-endian" mean both big-endian registers *and* big-endian >> descriptors. > > But doesn't "big-endian" property actually mean "big-endian-registers"? > Do we have to overload property meaning in this case? It doesn't *have* a standard meaning, it is defined per device binding that uses it. Just make it mean whatever is most logical for this device. >> I have no opinion which is best; it depends on what configurations >> actually exist, and how popular those are. Segher _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
