Hi Pali, While we are at it, this default should be changed in drivers/usb/host/Kconfig.
config USB_XHCI_MVEBU bool "MVEBU USB 3.0 support" default y Setting this default correctly will save a couple Kbytes for other boards. default y if ARCH_MVEBU Thanks, Tony On Fri, Nov 12, 2021 at 3:24 PM Tony Dinh <mibo...@gmail.com> wrote: > > On Fri, Nov 12, 2021 at 2:42 PM Pali Rohár <p...@kernel.org> wrote: > > > > On Friday 12 November 2021 13:46:29 Tony Dinh wrote: > > > 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. > > > > This is used for native USB 3.0 controller in Marvell SoC (connected via > > serdes). > > > > But you wrote and sent pci output, that you have PCIe-based USB > > controller connected via PCIe. > > Ah, got it. > > Thanks, > Tony > > > > So I'll need rebuild with "depends on (ARCH_MVEBU || ARCH_KIRKWOOD)" > > > and do some more testing. > > > > > > Thanks, > > > Tony > > > > > > > > > > > > > Thanks, > > > > > Stefan