From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Mon, 22 Oct 2012 11:48:29 -0600 Subject: [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver In-Reply-To: References: Message-ID: <508586ED.1010106@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 10/22/2012 11:34 AM, Alan Stern wrote: > On Mon, 22 Oct 2012, Stephen Warren wrote: > >> On 10/20/2012 04:10 PM, Tony Prisk wrote: >>> Add a binding document for ehci-platform driver. > >>> +Optional properties: >>> +- caps-offset : offset to the capabilities register (default = 0) >>> +- 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". >>> +- 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? 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? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver Date: Mon, 22 Oct 2012 11:48:29 -0600 Message-ID: <508586ED.1010106@wwwdotorg.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alan Stern Cc: Tony Prisk , Greg KH , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Florian Fainelli , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Rob Herring , Grant Likely List-Id: devicetree@vger.kernel.org On 10/22/2012 11:34 AM, Alan Stern wrote: > On Mon, 22 Oct 2012, Stephen Warren wrote: > >> On 10/20/2012 04:10 PM, Tony Prisk wrote: >>> Add a binding document for ehci-platform driver. > >>> +Optional properties: >>> +- caps-offset : offset to the capabilities register (default = 0) >>> +- 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". >>> +- 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? 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? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html