Alan Stern [stern@xxxxxxxxxxxxxxxxxxx] wrote:
>On Mon, 23 Jan 2012, Jayachandran C. wrote:
>
>> From: Jayachandran C <jayachandranc@xxxxxxxxxxxxxxxxx>
>>
>> The USB driver code usually uses readl() to read the EHCI register
>> space to support chips which does not allow 8/16 bit access to the
>> EHCI registers.
>>
>> But in the PCI USB quirk code (drivers/usb/host/pci-quirks.c),
> readb() is used in one place. Convert this to use readl as well.
>>
>> Signed-off-by: Jayachandran C <jayachandranc@xxxxxxxxxxxxxxxxx>
>> ---
>>
>> [ The Netlogic XLP patches I plan to submit is dependent on this,
>> otherwise we will need to fix this up with a custom Cache error
>> handler. Let me know if this is not the right approach. - Thanks.]
>>
>> drivers/usb/host/pci-quirks.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
>> index caf8742..ea7edfe 100644
>> --- a/drivers/usb/host/pci-quirks.c
>> +++ b/drivers/usb/host/pci-quirks.c
>> @@ -630,7 +630,7 @@ static void __devinit quirk_usb_disable_ehci(struct pci_dev *pdev)
>> if (base == NULL)
>> return;
>>
>> - cap_length = readb(base);
>> + cap_length = readl(base) & 0xff;
>> op_reg_base = base + cap_length;
>>
>> /* EHCI 0.96 and later may have "extended capabilities"
>
> This is potentially dangerous, because it involves byte-ordering within
> a word. See the comment in include/linux/usb/ehci_def.h where
> hc_capbase is defined, and the comment in ehci.h where
> ehci_big_endian_capbase is defined.
>
> Fortunately the only driver that sets the big_endian_capbase flag is
> ehci-grlib, which isn't PCI. So there shouldn't be any problem.
> However you might want to mention these issues in the patch
> description, and maybe even as a comment in the quirk_usb_disable_ehci
> code.
>
> In theory, big-endian PCI controllers all do this the wrong way. That
> is, since CAPLENGTH is specified as occupying the byte at the lowest
> address in the word, it should end up as the highest-order byte of a
> big-endian value. I guess people discovered that if they followed the
> spec in this regard, their controllers wouldn't work with regular PCI
> drivers.
Yes. I just replicated the HC_LENGTH logic here.It seemed to me
that the USB PCI quirk code did not try to handle the big-endian cases
at all.
After reading the code again, it looks like another solution is to just
avoid the whole quirk_usb_early_handoff() function for our
MIPS cpu - which does not have PC style firmware, and handoff
is not necessary.
quirk_usb_early_handoff() is declared as a fixup for PCI_ANY_ID,
PCI_ANY_ID, so a patch that just skips Netlogic devices in
quirk_usb_early_handoff looks like this: (will be white-space damaged,
I will send out a proper one if it is okay.)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index caf8742..20e0e46 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -867,6 +867,10 @@ hc_init:
static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
{
+ /* Skip Netlogic mips SoC's internal PCI USB controller */
+ if (pdev->vendor == 0x184e)
+ return;
+
if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
quirk_usb_handoff_uhci(pdev);
else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
JC.
--
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
