Hi Stefan & Pali, On Fri, Nov 12, 2021 at 7:06 AM Pali Rohár <p...@kernel.org> wrote: > > On Friday 12 November 2021 15:36:31 Stefan Roese wrote: > > On 11/11/21 22:10, Pali Rohár wrote: > > > On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote: > > > > I've also tried mdelay(3000), just to be sure. The result was the same > > > > hang in 'usb start'. > > > > > > Ok. So put pci_init() into board_late_init(). > > > > > > There are some more cleanup and fixes patches for pci_mvebu.c on mailing > > > list. After they are merged I will prepare and send final PCI Kirkwood > > > patch for testing. > > > > Chiming in a bit late in this discussion: > > > > Is an explicit call to pci_init() necessary in this Kirwood case? IIRC, > > the DM infrastructure should make sure that all device are probed - but > > only when really needed. So if you don't need PCI in the boot process > > at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this > > will be done always. Then there should be no need for the additional > > "pci enum". > > CONFIG_PCI_PNP probe and initialize all devices behind host bridge. > CONFIG_PCI_INIT_R probe and initialize host bridge (this is done by > calling pci_init()). Based on tests (see discussion in this thread) it > looks like that CONFIG_PCI_INIT_R calls pci_init() too early and > initialization is failing. So unsetting CONFIG_PCI_INIT_R and calling > pci_init() manually from board_late_init() (which is called later than > CONFIG_PCI_INIT_R) seems to fix these issues. No idea why... > > I might be missing something - did not check in depth.
I think this must be the problem. Sorry I've missed this: config USB_XHCI_MVEBU bool "MVEBU USB 3.0 support" default y depends on ARCH_MVEBU select DM_REGULATOR help Choose this option to add support for USB 3.0 driver on mvebu SoCs, which includes Armada8K, Armada3700 and other Armada family SoCs. So I'll need rebuild with "depends on (ARCH_MVEBU || ARCH_KIRKWOOD)" and do some more testing. Thanks, Tony > > > > Thanks, > > Stefan