On Wed, 27 Jan 2010 13:36:12 +0100
Jan Andersson <jan@xxxxxxxxxxx> wrote:
> Anatolij Gustschin wrote:
> > @@ -259,6 +305,11 @@ static int ehci_fsl_setup(struct usb_hcd *hcd)
> > {
> > struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> > int retval;
> > + struct fsl_usb2_platform_data *pdata;
> > +
> > + pdata = hcd->self.controller->platform_data;
> > + ehci->big_endian_desc = pdata->big_endian_desc;
> > + ehci->big_endian_mmio = pdata->big_endian_mmio;
>
> I recently posted some questions to linux-usb@vger about big_endian_mmio
> and the definition of the HC_LENGTH and HC_VERSION macros. The thread
> can be found here: http://marc.info/?l=linux-usb&m=126441448626924&w=2
>
> The EHCI specification defines the CAPLENGTH register as an 8-bit
> register at byte offset 0 and HCIVERSION as a 16-bit register at byte
> offset 2. Performing a 32-bit read on a big endian system should
> therefore results in the following organisation (MSB .. LSB):
> CAPLENGTH : RESERVED : HCIVERSION
>
> The macros for reading CAPLENGTH and HCIVERSION (defined in
> include/linux/usb/ehci-def.h) look like:
>
> #define HC_LENGTH(p) (((p)>>00)&0x00ff) /* bits 7:0 */
> #define HC_VERSION(p) (((p)>>16)&0xffff) /* bits 31:16 */
>
> That is, they select the registers as they were organized within the
> word according to little endian. Is this not a problem for your
> controller/driver?
On this controller the CAPLENGTH register is an 8-bit regiser at
byte offset 3 and HCIVERSION register is a 16-bit register at
byte offset 0. Performing a 32-bit read results in:
HCIVERSION : RESERVED : CAPLENGTH
So it is not a problem for the driver.
Best regards,
Anatolij
--
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
