On 05/01/18 02:09, Troy Kisky wrote: > On 12/29/2017 3:34 AM, Marc Zyngier wrote: >> On Wed, 27 Dec 2017 20:37:07 +0000, >> Troy Kisky wrote: >>> >>> On 12/27/2017 2:37 AM, Marc Zyngier wrote: >>>> On Tue, 26 Dec 2017 21:57:58 +0000, >>>> Troy Kisky wrote: >>>>> >>>>> On 12/26/2017 1:52 PM, Troy Kisky wrote: >>>>>> On 12/25/2017 2:10 AM, Marc Zyngier wrote: >>>>>>> On Sun, 24 Dec 2017 23:01:33 +0000, >>>>>>> Troy Kisky wrote: >>>>>>>> >>>>>>>> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 >>>>>>>> Author: Marc Zyngier <marc.zyngier@xxxxxxx> >>>>>>>> Date: Tue Aug 1 20:11:08 2017 -0500 >>>>>>>> >>>>>>>> xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue >>>>>>>> ... >>>>>>>> ... >>>>>>>> ... >>>>>>>> --- a/drivers/usb/host/xhci-pci.c >>>>>>>> +++ b/drivers/usb/host/xhci-pci.c >>>>>>>> @@ -284,6 +284,13 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) >>>>>>>> >>>>>>>> driver = (struct hc_driver *)id->driver_data; >>>>>>>> >>>>>>>> + /* For some HW implementation, a XHCI reset is just not enough... */ >>>>>>>> + if (usb_xhci_needs_pci_reset(dev)) { >>>>>>>> + dev_info(&dev->dev, "Resetting\n"); >>>>>>>> + if (pci_reset_function_locked(dev)) >>>>>>>> + dev_warn(&dev->dev, "Reset failed"); >>>>>>>> + } >>>>>>>> + >>>>>>>> ________ >>>>>>>> >>>>>>>> >>>>>>>> This pci_reset_function_locked call, causes my i.mx6qp processor to >>>>>>>> hang. It no longer responds to the MAGIC_SYSRQ key (break on serial >>>>>>>> port). >>>>>>>> >>>>>>>> >>>>>>>> If I comment it out, things return to normal when testing on >>>>>>>> Linux-next (20171222). >>>>>>>> >>>>>>>> If you need more info, let me know. >>>>>>> >>>>>>> Well, for a start: >>>>>>> >>>>>>> - Does it fail with 4.13 or 4.14 too? >>>>>> >>>>>> v4.13-rc4 - good >>>>>> v4.13-rc5 - fail >>>>>> v4.13 - fail >>>>>> v4.14 - fail >>>>>> >>>>>> >>>>>> >>>>>>> - Can you work out where it is locking up exactly (going slightly >>>>>>> deeper than the pci_reset_function_locked() call)? >>>>>> >>>>>> With this patch >>>>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >>>>>> index 05104bd2b611..8782945a9f70 100644 >>>>>> --- a/drivers/usb/host/xhci.c >>>>>> +++ b/drivers/usb/host/xhci.c >>>>>> @@ -4808,8 +4808,10 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks) >>>>>> >>>>>> mutex_init(&xhci->mutex); >>>>>> xhci->cap_regs = hcd->regs; >>>>>> + pr_err("%s: 1\n", __func__); >>>>>> xhci->op_regs = hcd->regs + >>>>>> HC_LENGTH(readl(&xhci->cap_regs->hc_capbase)); >>>>>> + pr_err("%s: 2\n", __func__); >>>>>> xhci->run_regs = hcd->regs + >>>>>> (readl(&xhci->cap_regs->run_regs_off) & RTSOFF_MASK); >>>>>> /* Cache read-only capability registers */ >>>>>> _____________________ >>>>>> >>>>>> The last thing printed is >>>>>> [ OK ] Reached target System Initialization. >>>>>> [ OK ] Listening on D-Bus System Message Bus Socket. >>>>>> [ OK ] Reached target Sockets. >>>>>> [ OK ] Started Daily Cleanup of Temporary Directories. >>>>>> [ 15.770319] xhci_gen_setup: 1 >>>> >>>> OK, so it looks like the CPU is blocked reading from the >>>> device. Almost feels like the device is not clocked (that's about the >>>> only reason why the CPU would be stuck on such a read). >>>> >>>>>> >>>>>> >>>>>>> - Do you get the symptom at boot time? >>>>>> >>>>>> Boot >>>>>> >>>>>>> On resume? Is the USB driver >>>>>>> compiled as a module or built-in? >>>>>> >>>>>> INSTALL drivers/usb/host/xhci-hcd.ko >>>>>> INSTALL drivers/usb/host/xhci-pci.ko >>>>>> INSTALL drivers/usb/host/xhci-renesas.ko >>>>>> >>>>>>> - What is your exact platform (something a bit more precise than just >>>>>>> i.MX6...)? >>>>>> >>>>>> It is a custom board not in mainline. It does need to load firmware. >>>>>> >>>>>> I tried moving pci_reset_function_locked before renesas_check_if_fw_dl_is_needed >>>>>> but that did not help. >>>>>> >>>>> >>>>> >>>>> >>>>> Which I should say I also have this patch >>>>> >>>>> >>>>> commit 01ac5cfd811088b5fe8c97f28f96086e30393c66 >>>>> Author: Christian Lamparter <chunkeey@xxxxxxxxx> >>>>> Date: Wed Jun 8 00:14:57 2016 +0200 >>>>> >>>>> usb: xhci: handle uPD720201 and uPD720202 w/o ROM >>>>> >>>>> This patch adds a firmware check for the uPD720201K8-711-BAC-A >>>>> and uPD720202K8-711-BAA-A variant. Both of these chips are listed >>>>> in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as >>>>> devices which need a firmware in order to work as they do not have >>>>> support to load the firmware from an external ROM. >>>>> >>>>> __________ >>>>> >>>>> Sorry for not saying earlier. >>>> >>>> That's a very interesting piece of information. Looking at that >>>> patch[1], it doesn't provide any FW loader, and simply detects whether >>>> the firmware is correctly present and running. >>>> >>>> What is probably happening is that your bootloader loads the XHCI >>>> firmware, the driver resets the XHCI device, and the firmware is >>>> lost. Assuming my hunch is right, what would be required here is for >>>> the firmware to be loaded after the reset, but that'd require writing >>>> a firmware loader for xhci-pci (probably not a huge undertaking) >>>> >>>> Could you please investigate whether my hunch is correct or not? >>>> >>>> Thanks, >>>> >>>> M. >>>> >>>> [1]: https://patchwork.kernel.org/patch/9162693/ >>>> >>> >>> Hi Marc >>> >>> >>> It already had a firmware downloader, and I tried reset both before and after that. No change. >>> >>> >>> So, now I've tried the same thing with 0 patches to linux-next. A nitrogen6_max board >>> with a Renesas USB3.0 PCIe card that has a firmware ROM, and so does not need the extra patch. >>> >>> 01:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) >>> >>> It behaves identically to the other board. So, the firmware issue is a red herring. >>> >>> [ OK ] Found device /dev/ttymxc0. >>> [ OK ] Found device /dev/ttymxc1. >>> [ 11.916718] xhci_gen_setup: 1 >> >> Fair enough. Can you try reseting another endpoint? I'm trying to work >> out whether this is an iMX6 issue or something else. You should be >> able to unload/unbind the driver, reset the device by writing to >> /sys/bus/pci/devices/0000:01:00.0/reset (for example), and reload the driver. >> >> Thanks, >> >> M. >> > > That makes it hang as well... > > > root@nitrogen:/sys/bus/pci/devices/0000:01:00.0# echo 1 >reset > root@nitrogen:/sys/bus/pci/devices/0000:01:00.0# > root@nitrogen:/sys/bus/pci/devices/0000:01:00.0# > root@nitrogen:/sys/bus/pci/devices/0000:01:00.0# modprobe xhci_pci > [ 236.369271] xhci_hcd 0000:01:00.0: Resetting > [ 236.374916] xhci_hcd 0000:01:00.0: xHCI Host Controller > [ 236.380444] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2 But that's the same device right? Sorry if I was unclear, but I was hoping you could try with another device altogether (an Ethernet card, for example). Thanks, M. -- Jazz is not dead. It just smells funny... -- 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