On Mon, 22 Oct 2012, Stephen Warren wrote: > >>> +- has-tt : controller has transaction translator(s). > >>> +- has-synopsys-hc-bug : controller has the synopsys hc bug > >> > >> That would normally be determined by the driver based on the particular > >> compatible value that is in device tree. > > > > I don't understand this comment. Isn't "has-synopsys-hc-bug" the > > compatible value in question? > > "compatible value" in this context means that value of the property > named "compatible". I see. But why would it be done this way instead having a separate property? And doesn't the same reasoning apply to has-tt? Doesn't that mean the driver would have to match four different hardware types? What happens if a third characteristic like these comes around; would the driver then have to check against eight different types? > >>> +- big-endian : descriptors and registers are both big endian. This > >>> + is the equivalent of specifying big-endian-desc and big-endian-regs. > >>> +OR > >>> +- big-endian-desc : descriptors are in big-endian format > >>> +- big-endian-regs : mmio is in big-endian format > >> > >> Hmmm. That looks odd. Presumably if those properties aren't specified, > >> the default is little-endian? Shouldn't this be a tri-state: big, > >> little, native, with default native? I don't know what the EHCI > >> specification mandates here (and if it does mandate something, the > >> default should match the specification). Isn't this something that > >> readl/writel would take care of, or are there cases where the register > >> endianness of just this one HW block mismatches all other HW blocks? > > > > The EHCI spec assumes a PCI implementation; it doesn't consider other > > sorts. And it doesn't say anything about the endianness of multi-byte > > descriptors in memory. > > OK, so does this binding default to assuming little-endian (which I > assume matches PCI), unless the big-endian properties are given? Yes, that is the intention. The ehci-hcd driver works the same way; it assumes little-endian unless USB_EHCI_BIG_ENDIAN_DESC or USB_EHCI_BIG_ENDIAN_MMIO is set. (That will have to change in the future, though.) > Is the > case of little-endian EHCI registers on a big-endian CPU a common enough > thing that adding a third state native-endian wouldn't be useful? I'm not sure how to answer. Little-endian EHCI registers are very common, even among big-endian CPUs (they are probably the majority, in fact). I don't see how adding native-endian would help; the readl() function always assumes the values it reads are little-endian, so in that sense little-endian _is_ the native state. Also, as far as I know there aren't any examples of big-endian EHCI registers on systems with little-endian CPUs. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
