On 1/5/2018 1:10 AM, Marc Zyngier wrote:
> 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.
>
That worked for iwlwifi
root@nitrogen:~# cd /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# echo 1 >reset
root@nitrogen:/sys/bus/pci/devices/0000:01:00.0#
root@nitrogen:/sys/bus/pci/devices/0000:01:00.0# modprobe iwlwifi
[ 200.072710] Intel(R) Wireless WiFi driver for Linux
[ 200.077744] Copyright(c) 2003- 2015 Intel Corporation
[ 200.084309] iwlwifi 0000:01:00.0: pci_enable_msi failed - -22
[ 200.096066] iwlwifi 0000:01:00.0: loaded firmware version 8.83.5.1 build 33692 op_mode iwldvm
root@nitrogen:/sys/bus/pci/devices/0000:01:00.0# [ 200.139120] iwlwifi 0000:01:00.0:
CONFIG_IWLWIFI_DEBUG disabled
[ 200.145273] iwlwifi 0000:01:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[ 200.151392] iwlwifi 0000:01:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[ 200.158266] iwlwifi 0000:01:00.0: Detected Intel(R) Ultimate N WiFi Link 5300 AGN, REV=0x24
[ 200.261129] iwlwifi 0000:01:00.0 wlp1s0: renamed from wlan1
[ 200.410310] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
root@nitrogen:/sys/bus/pci/devices/0000:01:00.0# cd /
root@nitrogen:/# lspci
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01)
01:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300
root@nitrogen:/#
--
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
