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?
Best regards,
Jan
--
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
