Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

>>> I think problem is caused by access to OHCI regs from PCI quirks - before
>>> driver was initialized. ULI1553 southbridge chip could be in strange state
>>> at this point.
>>
>> If that is the cause, we ought to be able to see it from the values
>> printed out by the debugging statements.  And if that is so, it's a
>> serious problem.  The southbridge chip really should be working at this
>> point, because the quirk_usb_handoff_* routines need to be able to
>> communicate with the host controllers.
> 
> In this case, communication looks possible.
> However, read of OHCI_FMINTERVAL register somehow breaks it.

I realized that source of the problem is elsewhere.

P2020DS board's USB connectors are not connected to ULI1553 USB.
These are connected to P2020 SOC's USB, handled by fsl-ehci driver (even
for USB 1.1 devices)
As for ULI1553 USB - it is not wired.
But - due to hardware misfeature - ULI1553 USB is not hardware-masked,
and with mainline kernel it visible on the bus:

root@freescale-p2020ds:~# lspci
0000:00:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 10)
0001:02:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 10)
0001:03:00.0 PCI bridge: ULi Electronics Inc. M5249 HTT to PCI Bridge
0001:04:1c.0 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)
0001:04:1c.1 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)
0001:04:1c.2 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)
0001:04:1c.3 USB controller: ULi Electronics Inc. USB 2.0 Controller (rev 01)
0001:04:1e.0 ISA bridge: ULi Electronics Inc. M1575 South Bridge
0001:04:1e.1 Bridge: ULi Electronics Inc. M7101 Power Management Controller [PMU]
0001:04:1f.0 IDE interface: ULi Electronics Inc. M5229 IDE (rev c8)
0001:04:1f.1 IDE interface: ULi Electronics Inc. ULi M5288 SATA (rev 10)
0002:05:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 10)

I forgot about that when checking our local tree for mainlineable commits.
Sorry.

I don't know how linux usb subsystem should behave against such
"half-existing" hardware. Perhaps hanging is not the best idea...
but maybe it should be fixed elsewhere, e.g. by masking non-wired
devices in platform PCI setup. Perhaps controlled by some device-tree
key.

Nikita
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/