>>> 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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
