Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

[Troy Kisky]

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 +,
>>>>>>>> Troy Kisky wrote:
>>>>>>>>>
>>>>>>>>> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
>>>>>>>>> Author: Marc Zyngier <marc.zyng...@arm.com>
>>>>>>>>> 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, "Resetting\n");
>>>>>>>>> +   if (pci_reset_function_locked(dev))
>>>>>>>>> +   dev_warn(>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(>mutex);
>>>>>>> xhci->cap_regs = hcd->regs;
>>>>>>> +   pr_err("%s: 1\n", __func__);
>>>>>>> xhci->op_regs = hcd->regs +
>>>>>>> HC_LENGTH(readl(>cap_regs->hc_capbase));
>>>>>>> +   pr_err("%s: 2\n", __func__);
>>>>>>> xhci->run_regs = hcd->regs +
>>>>>>> (readl(>cap_regs->run_regs_off) & RTSOFF_MASK);
>>>>>>> /* Cache read-only capability registers */
>>>>>>> _
>

Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

[Troy Kisky]

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 +,
>>>>>>>> Troy Kisky wrote:
>>>>>>>>>
>>>>>>>>> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
>>>>>>>>> Author: Marc Zyngier <marc.zyng...@arm.com>
>>>>>>>>> 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, "Resetting\n");
>>>>>>>>> +   if (pci_reset_function_locked(dev))
>>>>>>>>> +   dev_warn(>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(>mutex);
>>>>>>> xhci->cap_regs = hcd->regs;
>>>>>>> +   pr_err("%s: 1\n", __func__);
>>>>>>> xhci->op_regs = hcd->regs +
>>>>>>> HC_LENGTH(readl(>cap_regs->hc_capbase));
>>>>>>> +   pr_err("%s: 2\n", __func__);
>>>>>>> xhci->run_regs = hcd->regs +
>>>>>>> (readl(>cap_regs->run_regs_off) & RTSOFF_MASK);
>>>>>>> /* Cache read-only capability registers */
>>>>>>> _
>

Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

[Troy Kisky]

On 12/29/2017 3:34 AM, Marc Zyngier wrote:
> On Wed, 27 Dec 2017 20:37:07 +,
> Troy Kisky wrote:
>>
>> On 12/27/2017 2:37 AM, Marc Zyngier wrote:
>>> On Tue, 26 Dec 2017 21:57:58 +,
>>> 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 +,
>>>>>> Troy Kisky wrote:
>>>>>>>
>>>>>>> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
>>>>>>> Author: Marc Zyngier <marc.zyng...@arm.com>
>>>>>>> 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, "Resetting\n");
>>>>>>> +   if (pci_reset_function_locked(dev))
>>>>>>> +   dev_warn(>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(>mutex);
>>>>> xhci->cap_regs = hcd->regs;
>>>>> +   pr_err("%s: 1\n", __func__);
>>>>> xhci->op_regs = hcd->regs +
>>>>> HC_LENGTH(readl(>cap_regs->hc_capbase));
>>>>> +   pr_err("%s: 2\n", __func__);
>>>>> xhci->run_regs = hcd->regs +
>>>>> (readl(>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 

Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

[Troy Kisky]

On 12/27/2017 2:37 AM, Marc Zyngier wrote:
> On Tue, 26 Dec 2017 21:57:58 +,
> 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 +,
>>>> Troy Kisky wrote:
>>>>>
>>>>> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
>>>>> Author: Marc Zyngier <marc.zyng...@arm.com>
>>>>> 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, "Resetting\n");
>>>>> +   if (pci_reset_function_locked(dev))
>>>>> +   dev_warn(>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(>mutex);
>>> xhci->cap_regs = hcd->regs;
>>> +   pr_err("%s: 1\n", __func__);
>>> xhci->op_regs = hcd->regs +
>>> HC_LENGTH(readl(>cap_regs->hc_capbase));
>>> +   pr_err("%s: 2\n", __func__);
>>> xhci->run_regs = hcd->regs +
>>> (readl(>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 01ac5cfd811088

Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

[Troy Kisky]

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 +,
>> Troy Kisky wrote:
>>>
>>> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
>>> Author: Marc Zyngier <marc.zyng...@arm.com>
>>> 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, "Resetting\n");
>>> +   if (pci_reset_function_locked(dev))
>>> +   dev_warn(>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(>mutex);
> xhci->cap_regs = hcd->regs;
> +   pr_err("%s: 1\n", __func__);
> xhci->op_regs = hcd->regs +
> HC_LENGTH(readl(>cap_regs->hc_capbase));
> +   pr_err("%s: 2\n", __func__);
> xhci->run_regs = hcd->regs +
> (readl(>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
> 
> 
>> - 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 <chunk...@gmail.com>
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.


Troy
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

[Troy Kisky]

On 12/25/2017 2:10 AM, Marc Zyngier wrote:
> On Sun, 24 Dec 2017 23:01:33 +,
> Troy Kisky wrote:
>>
>> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
>> Author: Marc Zyngier <marc.zyng...@arm.com>
>> 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, "Resetting\n");
>> +   if (pci_reset_function_locked(dev))
>> +   dev_warn(>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(>mutex);
xhci->cap_regs = hcd->regs;
+   pr_err("%s: 1\n", __func__);
xhci->op_regs = hcd->regs +
HC_LENGTH(readl(>cap_regs->hc_capbase));
+   pr_err("%s: 2\n", __func__);
xhci->run_regs = hcd->regs +
(readl(>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


> - 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.


> 
> Thanks,
> 
>   M.
> 
Thanks for looking at it.

Troy

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

[Troy Kisky]

commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
Author: Marc Zyngier 
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, "Resetting\n");
+   if (pci_reset_function_locked(dev))
+   dev_warn(>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.

Thanks
Troy
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html