[PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

Somehow starting with v4.9-rc7 there have been imprecise
external aborts on omap5-uevm dwc3 controller. I have not been
able to bisect what exactly triggered this as it does not always
happen. It seems that something changed with probing that
now exposes the issue:

Unhandled fault: imprecise external abort (0x1406) at 0x00000000
...
PC is at dwc3_omap_interrupt_thread+0x20/0x80
LR is at irq_thread_fn+0x1c/0x54
...
[<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>]
(irq_thread_fn+0x1c/0x54)
[<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
[<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
[<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
...

Unable to handle kernel paging request at virtual address ffffffec
...
Internal error: Oops: 37 [#2] SMP ARM
PC is at kthread_data+0x4/0xc
LR is at irq_thread_dtor+0x28/0xd0
...
[<c035e0b4>] (kthread_data) from [<c038a5dc>] (irq_thread_dtor+0x28/0xd0)
[<c038a5dc>] (irq_thread_dtor) from [<c035bef0>] (task_work_run+0xb8/0xdc)
[<c035bef0>] (task_work_run) from [<c03448d4>] (do_exit+0x314/0xa20)
[<c03448d4>] (do_exit) from [<c030bea8>] (die+0x410/0x474)
[<c030bea8>] (die) from [<c0301350>] (do_DataAbort+0xb4/0xb8)
[<c0301350>] (do_DataAbort) from [<c030c578>] (__dabt_svc+0x58/0x80)
Exception stack(0xee777ec8 to 0xee777f10)
7ec0:                   0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00
7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18
7f00: c038a4d8 c0989fa8 60000013 ffffffff
[<c030c578>] (__dabt_svc) from [<c0989fa8>] (dwc3_omap_interrupt_thread+0x20/0x80)
[<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>] (irq_thread_fn+0x1c/0x54)
[<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
[<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
[<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)

Fix the issue by making sure the dwc3 interrupts are disabled
before we call devm_request_threaded_irq().

Note that there does not seem to be issues with the dwc3 wrapper
accessing these registers even before the dwc3 core is probed.
If some of these registers are specific to the dwc3 core, we can
have IRQ disabled with irq_set_status_flags(omap->irq, IRQ_NOAUTOEN)
on start-up instead of accessing the dwc3 registers.

Reported-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
 drivers/usb/dwc3/dwc3-omap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -511,6 +511,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
 	/* check the DMA Status */
 	reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
 
+	dwc3_omap_disable_irqs(omap);
+
 	ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
 					dwc3_omap_interrupt_thread, IRQF_SHARED,
 					"dwc3-omap", omap);
-- 
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]


Hi,

Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> Somehow starting with v4.9-rc7 there have been imprecise

There's nothing touching dwc3 since v4.9-rc5.

> external aborts on omap5-uevm dwc3 controller. I have not been
> able to bisect what exactly triggered this as it does not always
> happen. It seems that something changed with probing that
> now exposes the issue:
>
> Unhandled fault: imprecise external abort (0x1406) at 0x00000000

hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all.

> ...
> PC is at dwc3_omap_interrupt_thread+0x20/0x80
> LR is at irq_thread_fn+0x1c/0x54
> ...
> [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>]
> (irq_thread_fn+0x1c/0x54)
> [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> ...
>
> Unable to handle kernel paging request at virtual address ffffffec
> ...
> Internal error: Oops: 37 [#2] SMP ARM
> PC is at kthread_data+0x4/0xc
> LR is at irq_thread_dtor+0x28/0xd0
> ...
> [<c035e0b4>] (kthread_data) from [<c038a5dc>] (irq_thread_dtor+0x28/0xd0)
> [<c038a5dc>] (irq_thread_dtor) from [<c035bef0>] (task_work_run+0xb8/0xdc)
> [<c035bef0>] (task_work_run) from [<c03448d4>] (do_exit+0x314/0xa20)
> [<c03448d4>] (do_exit) from [<c030bea8>] (die+0x410/0x474)
> [<c030bea8>] (die) from [<c0301350>] (do_DataAbort+0xb4/0xb8)
> [<c0301350>] (do_DataAbort) from [<c030c578>] (__dabt_svc+0x58/0x80)
> Exception stack(0xee777ec8 to 0xee777f10)
> 7ec0:                   0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00
> 7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18
> 7f00: c038a4d8 c0989fa8 60000013 ffffffff
> [<c030c578>] (__dabt_svc) from [<c0989fa8>] (dwc3_omap_interrupt_thread+0x20/0x80)
> [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>] (irq_thread_fn+0x1c/0x54)
> [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
>
> Fix the issue by making sure the dwc3 interrupts are disabled
> before we call devm_request_threaded_irq().

that should already be the case. Are you sure that register isn't zero
in probe?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 01:45]:
> 
> Hi,
> 
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> > Somehow starting with v4.9-rc7 there have been imprecise
> 
> There's nothing touching dwc3 since v4.9-rc5.

Right, nothing obvious has changed. I think it's just a slight timing
change in the code that started triggering it.

> > external aborts on omap5-uevm dwc3 controller. I have not been
> > able to bisect what exactly triggered this as it does not always
> > happen. It seems that something changed with probing that
> > now exposes the issue:
> >
> > Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> 
> hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all.

It does for the interconnect target module clkctrl register via PM
runtime. That's the "usb_otg_ss" module.

> > ...
> > PC is at dwc3_omap_interrupt_thread+0x20/0x80
> > LR is at irq_thread_fn+0x1c/0x54
> > ...
> > [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>]
> > (irq_thread_fn+0x1c/0x54)
> > [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> > [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> > [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> > ...
> >
> > Unable to handle kernel paging request at virtual address ffffffec
> > ...
> > Internal error: Oops: 37 [#2] SMP ARM
> > PC is at kthread_data+0x4/0xc
> > LR is at irq_thread_dtor+0x28/0xd0
> > ...
> > [<c035e0b4>] (kthread_data) from [<c038a5dc>] (irq_thread_dtor+0x28/0xd0)
> > [<c038a5dc>] (irq_thread_dtor) from [<c035bef0>] (task_work_run+0xb8/0xdc)
> > [<c035bef0>] (task_work_run) from [<c03448d4>] (do_exit+0x314/0xa20)
> > [<c03448d4>] (do_exit) from [<c030bea8>] (die+0x410/0x474)
> > [<c030bea8>] (die) from [<c0301350>] (do_DataAbort+0xb4/0xb8)
> > [<c0301350>] (do_DataAbort) from [<c030c578>] (__dabt_svc+0x58/0x80)
> > Exception stack(0xee777ec8 to 0xee777f10)
> > 7ec0:                   0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00
> > 7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18
> > 7f00: c038a4d8 c0989fa8 60000013 ffffffff
> > [<c030c578>] (__dabt_svc) from [<c0989fa8>] (dwc3_omap_interrupt_thread+0x20/0x80)
> > [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>] (irq_thread_fn+0x1c/0x54)
> > [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> > [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> > [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> >
> > Fix the issue by making sure the dwc3 interrupts are disabled
> > before we call devm_request_threaded_irq().
> 
> that should already be the case. Are you sure that register isn't zero
> in probe?

Looks like irq0_status = 0 and irqmisc_status = 0x2121. Also just
clearing irqmisc with dwc3_omap_write_irqmisc_clr(omap, 0xffffffff)
stops the issue from happening.

There is some deferred probing happening but irqmisc is always 0x2121.

Regards,

Tony

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Felipe Balbi]

Hi,

Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 01:45]:
>> 
>> Hi,
>> 
>> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
>> > Somehow starting with v4.9-rc7 there have been imprecise
>> 
>> There's nothing touching dwc3 since v4.9-rc5.
>
> Right, nothing obvious has changed. I think it's just a slight timing
> change in the code that started triggering it.

could be

>> > external aborts on omap5-uevm dwc3 controller. I have not been
>> > able to bisect what exactly triggered this as it does not always
>> > happen. It seems that something changed with probing that
>> > now exposes the issue:
>> >
>> > Unhandled fault: imprecise external abort (0x1406) at 0x00000000
>> 
>> hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all.
>
> It does for the interconnect target module clkctrl register via PM
> runtime. That's the "usb_otg_ss" module.

but that's all hidden in omap_device.c, we don't touch it from driver
perspective.

>> > ...
>> > PC is at dwc3_omap_interrupt_thread+0x20/0x80
>> > LR is at irq_thread_fn+0x1c/0x54
>> > ...
>> > [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>]
>> > (irq_thread_fn+0x1c/0x54)
>> > [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
>> > [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
>> > [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
>> > ...
>> >
>> > Unable to handle kernel paging request at virtual address ffffffec
>> > ...
>> > Internal error: Oops: 37 [#2] SMP ARM
>> > PC is at kthread_data+0x4/0xc
>> > LR is at irq_thread_dtor+0x28/0xd0
>> > ...
>> > [<c035e0b4>] (kthread_data) from [<c038a5dc>] (irq_thread_dtor+0x28/0xd0)
>> > [<c038a5dc>] (irq_thread_dtor) from [<c035bef0>] (task_work_run+0xb8/0xdc)
>> > [<c035bef0>] (task_work_run) from [<c03448d4>] (do_exit+0x314/0xa20)
>> > [<c03448d4>] (do_exit) from [<c030bea8>] (die+0x410/0x474)
>> > [<c030bea8>] (die) from [<c0301350>] (do_DataAbort+0xb4/0xb8)
>> > [<c0301350>] (do_DataAbort) from [<c030c578>] (__dabt_svc+0x58/0x80)
>> > Exception stack(0xee777ec8 to 0xee777f10)
>> > 7ec0:                   0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00
>> > 7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18
>> > 7f00: c038a4d8 c0989fa8 60000013 ffffffff
>> > [<c030c578>] (__dabt_svc) from [<c0989fa8>] (dwc3_omap_interrupt_thread+0x20/0x80)
>> > [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>] (irq_thread_fn+0x1c/0x54)
>> > [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
>> > [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
>> > [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
>> >
>> > Fix the issue by making sure the dwc3 interrupts are disabled
>> > before we call devm_request_threaded_irq().
>> 
>> that should already be the case. Are you sure that register isn't zero
>> in probe?
>
> Looks like irq0_status = 0 and irqmisc_status = 0x2121. Also just
> clearing irqmisc with dwc3_omap_write_irqmisc_clr(omap, 0xffffffff)
> stops the issue from happening.
>
> There is some deferred probing happening but irqmisc is always 0x2121.

some spurious irq status from ROM code, perhaps? Are you not resetting
usb_otg_ss hwmod? We shouldn't have any pending interrupts when we get
to probe(), if we do have them, then we need an erratum for it.

You could try making usb_otg_ss is reset by hwmod. It would also be good
to check other OMAP-ish devices sporting dwc3 (DRA7x, AM437x, AM57x) if
they have the same behavior.

Adding Nishanth to the loop too for reference.

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 09:52]:
> 
> Hi,
> 
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> > * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 01:45]:
> >> 
> >> Hi,
> >> 
> >> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> >> > Somehow starting with v4.9-rc7 there have been imprecise
> >> 
> >> There's nothing touching dwc3 since v4.9-rc5.
> >
> > Right, nothing obvious has changed. I think it's just a slight timing
> > change in the code that started triggering it.
> 
> could be
> 
> >> > external aborts on omap5-uevm dwc3 controller. I have not been
> >> > able to bisect what exactly triggered this as it does not always
> >> > happen. It seems that something changed with probing that
> >> > now exposes the issue:
> >> >
> >> > Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> >> 
> >> hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all.
> >
> > It does for the interconnect target module clkctrl register via PM
> > runtime. That's the "usb_otg_ss" module.
> 
> but that's all hidden in omap_device.c, we don't touch it from driver
> perspective.

The call to pm_runtime_get_sync() in dwc3_omap_probe() will use it.

Is there also some dwc3 internal clock? If we assume the usb_otg_ss
module is properly enabled it could be some dwc3 internal clock not
enabled?

We do have a srst_udelay needed for enabling musb controller for some
SoCs, I'll check if that's the case here.

> >> > ...
> >> > PC is at dwc3_omap_interrupt_thread+0x20/0x80
> >> > LR is at irq_thread_fn+0x1c/0x54
> >> > ...
> >> > [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>]
> >> > (irq_thread_fn+0x1c/0x54)
> >> > [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> >> > [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> >> > [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> >> > ...
> >> >
> >> > Unable to handle kernel paging request at virtual address ffffffec
> >> > ...
> >> > Internal error: Oops: 37 [#2] SMP ARM
> >> > PC is at kthread_data+0x4/0xc
> >> > LR is at irq_thread_dtor+0x28/0xd0
> >> > ...
> >> > [<c035e0b4>] (kthread_data) from [<c038a5dc>] (irq_thread_dtor+0x28/0xd0)
> >> > [<c038a5dc>] (irq_thread_dtor) from [<c035bef0>] (task_work_run+0xb8/0xdc)
> >> > [<c035bef0>] (task_work_run) from [<c03448d4>] (do_exit+0x314/0xa20)
> >> > [<c03448d4>] (do_exit) from [<c030bea8>] (die+0x410/0x474)
> >> > [<c030bea8>] (die) from [<c0301350>] (do_DataAbort+0xb4/0xb8)
> >> > [<c0301350>] (do_DataAbort) from [<c030c578>] (__dabt_svc+0x58/0x80)
> >> > Exception stack(0xee777ec8 to 0xee777f10)
> >> > 7ec0:                   0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00
> >> > 7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18
> >> > 7f00: c038a4d8 c0989fa8 60000013 ffffffff
> >> > [<c030c578>] (__dabt_svc) from [<c0989fa8>] (dwc3_omap_interrupt_thread+0x20/0x80)
> >> > [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>] (irq_thread_fn+0x1c/0x54)
> >> > [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> >> > [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> >> > [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> >> >
> >> > Fix the issue by making sure the dwc3 interrupts are disabled
> >> > before we call devm_request_threaded_irq().
> >> 
> >> that should already be the case. Are you sure that register isn't zero
> >> in probe?
> >
> > Looks like irq0_status = 0 and irqmisc_status = 0x2121. Also just
> > clearing irqmisc with dwc3_omap_write_irqmisc_clr(omap, 0xffffffff)
> > stops the issue from happening.
> >
> > There is some deferred probing happening but irqmisc is always 0x2121.
> 
> some spurious irq status from ROM code, perhaps? Are you not resetting
> usb_otg_ss hwmod? We shouldn't have any pending interrupts when we get
> to probe(), if we do have them, then we need an erratum for it.

I have u-boot use it to download the kernel and that is probably using
the ROM code USB support.

> You could try making usb_otg_ss is reset by hwmod. It would also be good
> to check other OMAP-ish devices sporting dwc3 (DRA7x, AM437x, AM57x) if
> they have the same behavior.

It should be reset by default by hwmod.

> Adding Nishanth to the loop too for reference.

Regards,

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161208 10:25]:
> * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 09:52]:
> > 
> > Hi,
> > 
> > Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> > > * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 01:45]:
> > >> 
> > >> Hi,
> > >> 
> > >> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> > >> > Somehow starting with v4.9-rc7 there have been imprecise
> > >> 
> > >> There's nothing touching dwc3 since v4.9-rc5.
> > >
> > > Right, nothing obvious has changed. I think it's just a slight timing
> > > change in the code that started triggering it.
> > 
> > could be
> > 
> > >> > external aborts on omap5-uevm dwc3 controller. I have not been
> > >> > able to bisect what exactly triggered this as it does not always
> > >> > happen. It seems that something changed with probing that
> > >> > now exposes the issue:
> > >> >
> > >> > Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> > >> 
> > >> hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all.
> > >
> > > It does for the interconnect target module clkctrl register via PM
> > > runtime. That's the "usb_otg_ss" module.
> > 
> > but that's all hidden in omap_device.c, we don't touch it from driver
> > perspective.
> 
> The call to pm_runtime_get_sync() in dwc3_omap_probe() will use it.
> 
> Is there also some dwc3 internal clock? If we assume the usb_otg_ss
> module is properly enabled it could be some dwc3 internal clock not
> enabled?
> 
> We do have a srst_udelay needed for enabling musb controller for some
> SoCs, I'll check if that's the case here.

If there are no dwc3 internal clocks that may be causing the imprecise
external abort, then most likely we should apply the following change
for srst_udelay. Looks like srst_udelay value of 2 is not enough here
but 3 seems to do the job.

The issue of the spurious interrupts on dwc3 probe remains though.

Regards,

Tony

8< ------------------------------------
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1952,6 +1952,7 @@ static struct omap_hwmod omap54xx_usb_tll_hs_hwmod = {
 static struct omap_hwmod_class_sysconfig omap54xx_usb_otg_ss_sysc = {
 	.rev_offs	= 0x0000,
 	.sysc_offs	= 0x0010,
+	.srst_udelay	= 3,
 	.sysc_flags	= (SYSC_HAS_DMADISABLE | SYSC_HAS_MIDLEMODE |
 			   SYSC_HAS_SIDLEMODE),
 	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161208 10:45]:
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161208 10:25]:
> > * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 09:52]:
> > > 
> > > Hi,
> > > 
> > > Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> > > > * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 01:45]:
> > > >> 
> > > >> Hi,
> > > >> 
> > > >> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> > > >> > Somehow starting with v4.9-rc7 there have been imprecise
> > > >> 
> > > >> There's nothing touching dwc3 since v4.9-rc5.
> > > >
> > > > Right, nothing obvious has changed. I think it's just a slight timing
> > > > change in the code that started triggering it.
> > > 
> > > could be
> > > 
> > > >> > external aborts on omap5-uevm dwc3 controller. I have not been
> > > >> > able to bisect what exactly triggered this as it does not always
> > > >> > happen. It seems that something changed with probing that
> > > >> > now exposes the issue:
> > > >> >
> > > >> > Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> > > >> 
> > > >> hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all.
> > > >
> > > > It does for the interconnect target module clkctrl register via PM
> > > > runtime. That's the "usb_otg_ss" module.
> > > 
> > > but that's all hidden in omap_device.c, we don't touch it from driver
> > > perspective.
> > 
> > The call to pm_runtime_get_sync() in dwc3_omap_probe() will use it.
> > 
> > Is there also some dwc3 internal clock? If we assume the usb_otg_ss
> > module is properly enabled it could be some dwc3 internal clock not
> > enabled?
> > 
> > We do have a srst_udelay needed for enabling musb controller for some
> > SoCs, I'll check if that's the case here.
> 
> If there are no dwc3 internal clocks that may be causing the imprecise
> external abort, then most likely we should apply the following change
> for srst_udelay. Looks like srst_udelay value of 2 is not enough here
> but 3 seems to do the job.
> 
> The issue of the spurious interrupts on dwc3 probe remains though.

And for doing the reset looks like USBOTGSS_SYSCONFIG needs custom
handling as it's type2 byt with reset register in bit 17.

Anyways, for a minimal fix below is probably corrent if there are
no dw3 internal clocks to consider.

Regards,

Tony


> 8< ------------------------------------
> --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> @@ -1952,6 +1952,7 @@ static struct omap_hwmod omap54xx_usb_tll_hs_hwmod = {
>  static struct omap_hwmod_class_sysconfig omap54xx_usb_otg_ss_sysc = {
>  	.rev_offs	= 0x0000,
>  	.sysc_offs	= 0x0010,
> +	.srst_udelay	= 3,
>  	.sysc_flags	= (SYSC_HAS_DMADISABLE | SYSC_HAS_MIDLEMODE |
>  			   SYSC_HAS_SIDLEMODE),
>  	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Felipe Balbi]

Hi,

Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
>> Is there also some dwc3 internal clock? If we assume the usb_otg_ss
>> module is properly enabled it could be some dwc3 internal clock not
>> enabled?
>> 
>> We do have a srst_udelay needed for enabling musb controller for some
>> SoCs, I'll check if that's the case here.
>
> If there are no dwc3 internal clocks that may be causing the imprecise
> external abort, then most likely we should apply the following change
> for srst_udelay. Looks like srst_udelay value of 2 is not enough here
> but 3 seems to do the job.
>
> The issue of the spurious interrupts on dwc3 probe remains though.
>
> Regards,
>
> Tony
>
> 8< ------------------------------------
> --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> @@ -1952,6 +1952,7 @@ static struct omap_hwmod omap54xx_usb_tll_hs_hwmod = {
>  static struct omap_hwmod_class_sysconfig omap54xx_usb_otg_ss_sysc = {
>  	.rev_offs	= 0x0000,
>  	.sysc_offs	= 0x0010,
> +	.srst_udelay	= 3,

nothing against it. Would be nice if TI could confirm this is needed and
check if other families might also need it.

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 11:19]:
> 
> Hi,
> 
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> >> Is there also some dwc3 internal clock? If we assume the usb_otg_ss
> >> module is properly enabled it could be some dwc3 internal clock not
> >> enabled?
> >> 
> >> We do have a srst_udelay needed for enabling musb controller for some
> >> SoCs, I'll check if that's the case here.
> >
> > If there are no dwc3 internal clocks that may be causing the imprecise
> > external abort, then most likely we should apply the following change
> > for srst_udelay. Looks like srst_udelay value of 2 is not enough here
> > but 3 seems to do the job.
> >
> > The issue of the spurious interrupts on dwc3 probe remains though.
> >
> > Regards,
> >
> > Tony
> >
> > 8< ------------------------------------
> > --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> > @@ -1952,6 +1952,7 @@ static struct omap_hwmod omap54xx_usb_tll_hs_hwmod = {
> >  static struct omap_hwmod_class_sysconfig omap54xx_usb_otg_ss_sysc = {
> >  	.rev_offs	= 0x0000,
> >  	.sysc_offs	= 0x0010,
> > +	.srst_udelay	= 3,
> 
> nothing against it. Would be nice if TI could confirm this is needed and
> check if other families might also need it.

But as we currently are not using the WRAPRESET bit, the reset
function is nop except for the delay. So this just papers over
the problem with the delay. We are not really resetting anything
until WRAPRESET and probably also CORE_SW_RESET reset are used.

I'm now thinking the original $subject patch for dwc3-omap.c
is the way to go for the fix. Or possibly even writing to the
CORE_SW_RESET bit in dwc3-omap.c probe. The driver needs to be
able to initialize the hardware no matter what it's state is
in probe :)

Then later on we can add separate resets for the wrapper module
and dwc3 core. But that's way too intrusive for a fix for sure.

Regards,

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Felipe Balbi]

Hi,

Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
>> nothing against it. Would be nice if TI could confirm this is needed and
>> check if other families might also need it.
>
> But as we currently are not using the WRAPRESET bit, the reset
> function is nop except for the delay. So this just papers over
> the problem with the delay. We are not really resetting anything
> until WRAPRESET and probably also CORE_SW_RESET reset are used.
>
> I'm now thinking the original $subject patch for dwc3-omap.c
> is the way to go for the fix. Or possibly even writing to the
> CORE_SW_RESET bit in dwc3-omap.c probe. The driver needs to be
> able to initialize the hardware no matter what it's state is
> in probe :)

in theory, yeah. In practice, this doesn't work always. For starters,
we'd probably loose connection to host while handing over IP from
e.g. u-boot to kernel.

Not to mention tht with dwc3 we can't simply read EP registers and
figure out what's the state of the EP. EP registers are a command
interface to some HW-based command parser/processor. IOW, we can't
extrapolate internal state machine from a read of the registers.

All this to say, that we rely on properly reset HW from probe(). At
least in the context of dwc3 :-)

> Then later on we can add separate resets for the wrapper module
> and dwc3 core. But that's way too intrusive for a fix for sure.

yeah, that's something for v4.11. Let's go with your fix that just
clears interrupts early on. Once proper resets are added, then we should
revert that change.

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 12:10]:
> 
> Hi,
> 
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> >> nothing against it. Would be nice if TI could confirm this is needed and
> >> check if other families might also need it.
> >
> > But as we currently are not using the WRAPRESET bit, the reset
> > function is nop except for the delay. So this just papers over
> > the problem with the delay. We are not really resetting anything
> > until WRAPRESET and probably also CORE_SW_RESET reset are used.
> >
> > I'm now thinking the original $subject patch for dwc3-omap.c
> > is the way to go for the fix. Or possibly even writing to the
> > CORE_SW_RESET bit in dwc3-omap.c probe. The driver needs to be
> > able to initialize the hardware no matter what it's state is
> > in probe :)
> 
> in theory, yeah. In practice, this doesn't work always. For starters,
> we'd probably loose connection to host while handing over IP from
> e.g. u-boot to kernel.
> 
> Not to mention tht with dwc3 we can't simply read EP registers and
> figure out what's the state of the EP. EP registers are a command
> interface to some HW-based command parser/processor. IOW, we can't
> extrapolate internal state machine from a read of the registers.
> 
> All this to say, that we rely on properly reset HW from probe(). At
> least in the context of dwc3 :-)

Yeah I agree we should reset it properly also from PM point of view
to get things into sane state after the bootloader.

> > Then later on we can add separate resets for the wrapper module
> > and dwc3 core. But that's way too intrusive for a fix for sure.
> 
> yeah, that's something for v4.11. Let's go with your fix that just
> clears interrupts early on. Once proper resets are added, then we should
> revert that change.

OK

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Felipe Balbi]

Hi,

Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 09:52]:
>> 
>> Hi,
>> 
>> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
>> > * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 01:45]:
>> >> 
>> >> Hi,
>> >> 
>> >> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
>> >> > Somehow starting with v4.9-rc7 there have been imprecise
>> >> 
>> >> There's nothing touching dwc3 since v4.9-rc5.
>> >
>> > Right, nothing obvious has changed. I think it's just a slight timing
>> > change in the code that started triggering it.
>> 
>> could be
>> 
>> >> > external aborts on omap5-uevm dwc3 controller. I have not been
>> >> > able to bisect what exactly triggered this as it does not always
>> >> > happen. It seems that something changed with probing that
>> >> > now exposes the issue:
>> >> >
>> >> > Unhandled fault: imprecise external abort (0x1406) at 0x00000000
>> >> 
>> >> hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all.
>> >
>> > It does for the interconnect target module clkctrl register via PM
>> > runtime. That's the "usb_otg_ss" module.
>> 
>> but that's all hidden in omap_device.c, we don't touch it from driver
>> perspective.
>
> The call to pm_runtime_get_sync() in dwc3_omap_probe() will use it.

right, but there's no runtime suspend until ->remove(). IOW, after
pm_runtime_get_sync(), all necessary clocks should already be
enabled. If they aren't, there's either an erratum or a bug in drivers/clk/ti/

> Is there also some dwc3 internal clock? If we assume the usb_otg_ss
> module is properly enabled it could be some dwc3 internal clock not
> enabled?

no extra clocks.

> We do have a srst_udelay needed for enabling musb controller for some
> SoCs, I'll check if that's the case here.

okay

>> >> > Fix the issue by making sure the dwc3 interrupts are disabled
>> >> > before we call devm_request_threaded_irq().
>> >> 
>> >> that should already be the case. Are you sure that register isn't zero
>> >> in probe?
>> >
>> > Looks like irq0_status = 0 and irqmisc_status = 0x2121. Also just
>> > clearing irqmisc with dwc3_omap_write_irqmisc_clr(omap, 0xffffffff)
>> > stops the issue from happening.
>> >
>> > There is some deferred probing happening but irqmisc is always 0x2121.
>> 
>> some spurious irq status from ROM code, perhaps? Are you not resetting
>> usb_otg_ss hwmod? We shouldn't have any pending interrupts when we get
>> to probe(), if we do have them, then we need an erratum for it.
>
> I have u-boot use it to download the kernel and that is probably using
> the ROM code USB support.

is IRQ status already 0x2121 from u-boot prompt?

>> You could try making usb_otg_ss is reset by hwmod. It would also be good
>> to check other OMAP-ish devices sporting dwc3 (DRA7x, AM437x, AM57x) if
>> they have the same behavior.
>
> It should be reset by default by hwmod.

in which case, IRQ status should be reset to 0.

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 11:17]:
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> > The call to pm_runtime_get_sync() in dwc3_omap_probe() will use it.
> 
> right, but there's no runtime suspend until ->remove(). IOW, after
> pm_runtime_get_sync(), all necessary clocks should already be
> enabled. If they aren't, there's either an erratum or a bug in drivers/clk/ti/

I think it's some dependency to the dwc3 core probe. That's because I'm
able to read and print out the wrapper interrupt registers just fine
before the imprecise external abort happens in probe. So that means it's
something dwc3 specific after the TI wrapper module clckctl bit.

> > Is there also some dwc3 internal clock? If we assume the usb_otg_ss
> > module is properly enabled it could be some dwc3 internal clock not
> > enabled?
> 
> no extra clocks.

It seems that if we get an interrupt before dwc3 core has probed with
of_platform_populate(), we get the imprecise external abort.

> is IRQ status already 0x2121 from u-boot prompt?

Yes md 0x4A020034 shows 0x2121.

Regards,

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Felipe Balbi]

Hi,

Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 11:17]:
>> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
>> > The call to pm_runtime_get_sync() in dwc3_omap_probe() will use it.
>> 
>> right, but there's no runtime suspend until ->remove(). IOW, after
>> pm_runtime_get_sync(), all necessary clocks should already be
>> enabled. If they aren't, there's either an erratum or a bug in drivers/clk/ti/
>
> I think it's some dependency to the dwc3 core probe. That's because I'm
> able to read and print out the wrapper interrupt registers just fine
> before the imprecise external abort happens in probe. So that means it's
> something dwc3 specific after the TI wrapper module clckctl bit.
>
>> > Is there also some dwc3 internal clock? If we assume the usb_otg_ss
>> > module is properly enabled it could be some dwc3 internal clock not
>> > enabled?
>> 
>> no extra clocks.
>
> It seems that if we get an interrupt before dwc3 core has probed with
> of_platform_populate(), we get the imprecise external abort.

that's pretty odd. hwmod doesn't know about dwc3 core device, only
usb_otg_ss (dwc3-omap.c).

>> is IRQ status already 0x2121 from u-boot prompt?
>
> Yes md 0x4A020034 shows 0x2121.

okay, so maybe something left from even earlier? OMAP5 can boot off USB
peripheral.

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 12:12]:
> 
> Hi,
> 
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> > * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 11:17]:
> >> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> >> > The call to pm_runtime_get_sync() in dwc3_omap_probe() will use it.
> >> 
> >> right, but there's no runtime suspend until ->remove(). IOW, after
> >> pm_runtime_get_sync(), all necessary clocks should already be
> >> enabled. If they aren't, there's either an erratum or a bug in drivers/clk/ti/
> >
> > I think it's some dependency to the dwc3 core probe. That's because I'm
> > able to read and print out the wrapper interrupt registers just fine
> > before the imprecise external abort happens in probe. So that means it's
> > something dwc3 specific after the TI wrapper module clckctl bit.
> >
> >> > Is there also some dwc3 internal clock? If we assume the usb_otg_ss
> >> > module is properly enabled it could be some dwc3 internal clock not
> >> > enabled?
> >> 
> >> no extra clocks.
> >
> > It seems that if we get an interrupt before dwc3 core has probed with
> > of_platform_populate(), we get the imprecise external abort.
> 
> that's pretty odd. hwmod doesn't know about dwc3 core device, only
> usb_otg_ss (dwc3-omap.c).

It's probably the dwc3_core_soft_reset() that needs to happen before
we enable interrupts.

> >> is IRQ status already 0x2121 from u-boot prompt?
> >
> > Yes md 0x4A020034 shows 0x2121.
> 
> okay, so maybe something left from even earlier? OMAP5 can boot off USB
> peripheral.

I guess yeah it could be :)

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Grygorii Strashko]

Hi Tony,

On 12/08/2016 09:37 AM, Tony Lindgren wrote:
> * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 01:45]:
>> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
>>> Somehow starting with v4.9-rc7 there have been imprecise
>>
>> There's nothing touching dwc3 since v4.9-rc5.
> 
> Right, nothing obvious has changed. I think it's just a slight timing
> change in the code that started triggering it.
> 
>>> external aborts on omap5-uevm dwc3 controller. I have not been
>>> able to bisect what exactly triggered this as it does not always
>>> happen. It seems that something changed with probing that
>>> now exposes the issue:
>>>
>>> Unhandled fault: imprecise external abort (0x1406) at 0x00000000
>>
>> hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all.
> 
> It does for the interconnect target module clkctrl register via PM
> runtime. That's the "usb_otg_ss" module.
> 
>>> ...
>>> PC is at dwc3_omap_interrupt_thread+0x20/0x80
>>> LR is at irq_thread_fn+0x1c/0x54
>>> ...
>>> [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>]
>>> (irq_thread_fn+0x1c/0x54)
>>> [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
>>> [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
>>> [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
>>> ...
>>>
>>> Unable to handle kernel paging request at virtual address ffffffec
>>> ...
>>> Internal error: Oops: 37 [#2] SMP ARM
>>> PC is at kthread_data+0x4/0xc
>>> LR is at irq_thread_dtor+0x28/0xd0
>>> ...
>>> [<c035e0b4>] (kthread_data) from [<c038a5dc>] (irq_thread_dtor+0x28/0xd0)
>>> [<c038a5dc>] (irq_thread_dtor) from [<c035bef0>] (task_work_run+0xb8/0xdc)
>>> [<c035bef0>] (task_work_run) from [<c03448d4>] (do_exit+0x314/0xa20)
>>> [<c03448d4>] (do_exit) from [<c030bea8>] (die+0x410/0x474)
>>> [<c030bea8>] (die) from [<c0301350>] (do_DataAbort+0xb4/0xb8)
>>> [<c0301350>] (do_DataAbort) from [<c030c578>] (__dabt_svc+0x58/0x80)
>>> Exception stack(0xee777ec8 to 0xee777f10)
>>> 7ec0:                   0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00
>>> 7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18
>>> 7f00: c038a4d8 c0989fa8 60000013 ffffffff
>>> [<c030c578>] (__dabt_svc) from [<c0989fa8>] (dwc3_omap_interrupt_thread+0x20/0x80)
>>> [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>] (irq_thread_fn+0x1c/0x54)
>>> [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
>>> [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
>>> [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
>>>
>>> Fix the issue by making sure the dwc3 interrupts are disabled
>>> before we call devm_request_threaded_irq().
>>
>> that should already be the case. Are you sure that register isn't zero
>> in probe?
> 
> Looks like irq0_status = 0 and irqmisc_status = 0x2121. Also just
> clearing irqmisc with dwc3_omap_write_irqmisc_clr(omap, 0xffffffff)
> stops the issue from happening.
> 
> There is some deferred probing happening but irqmisc is always 0x2121.
> 

My assumption is that you have race here between IRQ handler and PM runtime
in error handling path during deferred probing.

 Will below change fix issue for you?

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 29e80cc..dbc21bc 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -517,12 +517,12 @@ static int dwc3_omap_probe(struct platform_device *pdev)
        if (ret) {
                dev_err(dev, "failed to request IRQ #%d --> %d\n",
                                omap->irq, ret);
-               goto err1;
+               goto err11;
        }
 
        ret = dwc3_omap_extcon_register(omap);
        if (ret < 0)
-               goto err1;
+               goto err11;
 
        ret = of_platform_populate(node, NULL, NULL, dev);
        if (ret) {
@@ -538,6 +538,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
        extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
        extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
 
+err11:
+       disable_irq(omap->irq);
 err1:
        pm_runtime_put_sync(dev);
        pm_runtime_disable(dev);


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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org> [161208 13:54]:
> Hi Tony,
> 
> On 12/08/2016 09:37 AM, Tony Lindgren wrote:
> > * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 01:45]:
> >> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
> >>> Somehow starting with v4.9-rc7 there have been imprecise
> >>
> >> There's nothing touching dwc3 since v4.9-rc5.
> > 
> > Right, nothing obvious has changed. I think it's just a slight timing
> > change in the code that started triggering it.
> > 
> >>> external aborts on omap5-uevm dwc3 controller. I have not been
> >>> able to bisect what exactly triggered this as it does not always
> >>> happen. It seems that something changed with probing that
> >>> now exposes the issue:
> >>>
> >>> Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> >>
> >> hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all.
> > 
> > It does for the interconnect target module clkctrl register via PM
> > runtime. That's the "usb_otg_ss" module.
> > 
> >>> ...
> >>> PC is at dwc3_omap_interrupt_thread+0x20/0x80
> >>> LR is at irq_thread_fn+0x1c/0x54
> >>> ...
> >>> [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>]
> >>> (irq_thread_fn+0x1c/0x54)
> >>> [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> >>> [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> >>> [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> >>> ...
> >>>
> >>> Unable to handle kernel paging request at virtual address ffffffec
> >>> ...
> >>> Internal error: Oops: 37 [#2] SMP ARM
> >>> PC is at kthread_data+0x4/0xc
> >>> LR is at irq_thread_dtor+0x28/0xd0
> >>> ...
> >>> [<c035e0b4>] (kthread_data) from [<c038a5dc>] (irq_thread_dtor+0x28/0xd0)
> >>> [<c038a5dc>] (irq_thread_dtor) from [<c035bef0>] (task_work_run+0xb8/0xdc)
> >>> [<c035bef0>] (task_work_run) from [<c03448d4>] (do_exit+0x314/0xa20)
> >>> [<c03448d4>] (do_exit) from [<c030bea8>] (die+0x410/0x474)
> >>> [<c030bea8>] (die) from [<c0301350>] (do_DataAbort+0xb4/0xb8)
> >>> [<c0301350>] (do_DataAbort) from [<c030c578>] (__dabt_svc+0x58/0x80)
> >>> Exception stack(0xee777ec8 to 0xee777f10)
> >>> 7ec0:                   0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00
> >>> 7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18
> >>> 7f00: c038a4d8 c0989fa8 60000013 ffffffff
> >>> [<c030c578>] (__dabt_svc) from [<c0989fa8>] (dwc3_omap_interrupt_thread+0x20/0x80)
> >>> [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>] (irq_thread_fn+0x1c/0x54)
> >>> [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> >>> [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> >>> [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> >>>
> >>> Fix the issue by making sure the dwc3 interrupts are disabled
> >>> before we call devm_request_threaded_irq().
> >>
> >> that should already be the case. Are you sure that register isn't zero
> >> in probe?
> > 
> > Looks like irq0_status = 0 and irqmisc_status = 0x2121. Also just
> > clearing irqmisc with dwc3_omap_write_irqmisc_clr(omap, 0xffffffff)
> > stops the issue from happening.
> > 
> > There is some deferred probing happening but irqmisc is always 0x2121.
> > 
> 
> My assumption is that you have race here between IRQ handler and PM runtime
> in error handling path during deferred probing.
> 
>  Will below change fix issue for you?

I think you figured out why it behaves that way :)

Seems to work based on few boot tests. Probably both should be applied,
my original patch to prevent spurious interrupts before things are
initialized, this to disable interrupts before pm_runtime_suspend()
on exit path:

Tested-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>


> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index 29e80cc..dbc21bc 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -517,12 +517,12 @@ static int dwc3_omap_probe(struct platform_device *pdev)
>         if (ret) {
>                 dev_err(dev, "failed to request IRQ #%d --> %d\n",
>                                 omap->irq, ret);
> -               goto err1;
> +               goto err11;
>         }
>  
>         ret = dwc3_omap_extcon_register(omap);
>         if (ret < 0)
> -               goto err1;
> +               goto err11;
>  
>         ret = of_platform_populate(node, NULL, NULL, dev);
>         if (ret) {
> @@ -538,6 +538,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
>         extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
>         extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
>  
> +err11:
> +       disable_irq(omap->irq);
>  err1:
>         pm_runtime_put_sync(dev);
>         pm_runtime_disable(dev);
> 
> 
> -- 
> regards,
> -grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Grygorii Strashko]

On 12/08/2016 04:57 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org> [161208 13:54]:
>> Hi Tony,
>>
>> On 12/08/2016 09:37 AM, Tony Lindgren wrote:
>>> * Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161208 01:45]:
>>>> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
>>>>> Somehow starting with v4.9-rc7 there have been imprecise
>>>>
>>>> There's nothing touching dwc3 since v4.9-rc5.
>>>
>>> Right, nothing obvious has changed. I think it's just a slight timing
>>> change in the code that started triggering it.
>>>
>>>>> external aborts on omap5-uevm dwc3 controller. I have not been
>>>>> able to bisect what exactly triggered this as it does not always
>>>>> happen. It seems that something changed with probing that
>>>>> now exposes the issue:
>>>>>
>>>>> Unhandled fault: imprecise external abort (0x1406) at 0x00000000
>>>>
>>>> hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all.
>>>
>>> It does for the interconnect target module clkctrl register via PM
>>> runtime. That's the "usb_otg_ss" module.
>>>
>>>>> ...
>>>>> PC is at dwc3_omap_interrupt_thread+0x20/0x80
>>>>> LR is at irq_thread_fn+0x1c/0x54
>>>>> ...
>>>>> [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>]
>>>>> (irq_thread_fn+0x1c/0x54)
>>>>> [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
>>>>> [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
>>>>> [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
>>>>> ...
>>>>>
>>>>> Unable to handle kernel paging request at virtual address ffffffec
>>>>> ...
>>>>> Internal error: Oops: 37 [#2] SMP ARM
>>>>> PC is at kthread_data+0x4/0xc
>>>>> LR is at irq_thread_dtor+0x28/0xd0
>>>>> ...
>>>>> [<c035e0b4>] (kthread_data) from [<c038a5dc>] (irq_thread_dtor+0x28/0xd0)
>>>>> [<c038a5dc>] (irq_thread_dtor) from [<c035bef0>] (task_work_run+0xb8/0xdc)
>>>>> [<c035bef0>] (task_work_run) from [<c03448d4>] (do_exit+0x314/0xa20)
>>>>> [<c03448d4>] (do_exit) from [<c030bea8>] (die+0x410/0x474)
>>>>> [<c030bea8>] (die) from [<c0301350>] (do_DataAbort+0xb4/0xb8)
>>>>> [<c0301350>] (do_DataAbort) from [<c030c578>] (__dabt_svc+0x58/0x80)
>>>>> Exception stack(0xee777ec8 to 0xee777f10)
>>>>> 7ec0:                   0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00
>>>>> 7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18
>>>>> 7f00: c038a4d8 c0989fa8 60000013 ffffffff
>>>>> [<c030c578>] (__dabt_svc) from [<c0989fa8>] (dwc3_omap_interrupt_thread+0x20/0x80)
>>>>> [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>] (irq_thread_fn+0x1c/0x54)
>>>>> [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
>>>>> [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
>>>>> [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
>>>>>
>>>>> Fix the issue by making sure the dwc3 interrupts are disabled
>>>>> before we call devm_request_threaded_irq().
>>>>
>>>> that should already be the case. Are you sure that register isn't zero
>>>> in probe?
>>>
>>> Looks like irq0_status = 0 and irqmisc_status = 0x2121. Also just
>>> clearing irqmisc with dwc3_omap_write_irqmisc_clr(omap, 0xffffffff)
>>> stops the issue from happening.
>>>
>>> There is some deferred probing happening but irqmisc is always 0x2121.
>>>
>>
>> My assumption is that you have race here between IRQ handler and PM runtime
>> in error handling path during deferred probing.
>>
>>  Will below change fix issue for you?
>
> I think you figured out why it behaves that way :)

just followed the code and your bug report:) not tested by my self.

>
> Seems to work based on few boot tests. Probably both should be applied,
> my original patch to prevent spurious interrupts before things are
> initialized,

you patch - do you mean disable irq  or clean up
irq status regs before requesting irq? for me, more logical is to
clean up irq status regs.

this to disable interrupts before pm_runtime_suspend()
> on exit path:
>
> Tested-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

So, you wanna me to send this as patch or wish to squash in yours?
(I'll be able to do this only tomorrow)

>
>
>> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
>> index 29e80cc..dbc21bc 100644
>> --- a/drivers/usb/dwc3/dwc3-omap.c
>> +++ b/drivers/usb/dwc3/dwc3-omap.c
>> @@ -517,12 +517,12 @@ static int dwc3_omap_probe(struct platform_device *pdev)
>>         if (ret) {
>>                 dev_err(dev, "failed to request IRQ #%d --> %d\n",
>>                                 omap->irq, ret);
>> -               goto err1;
>> +               goto err11;
>>         }
>>
>>         ret = dwc3_omap_extcon_register(omap);
>>         if (ret < 0)
>> -               goto err1;
>> +               goto err11;
>>
>>         ret = of_platform_populate(node, NULL, NULL, dev);
>>         if (ret) {
>> @@ -538,6 +538,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
>>         extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
>>         extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
>>
>> +err11:
>> +       disable_irq(omap->irq);
>>  err1:
>>         pm_runtime_put_sync(dev);
>>         pm_runtime_disable(dev);
>>
>>
>> --
>> regards,
>> -grygorii

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org> [161208 15:38]:
> On 12/08/2016 04:57 PM, Tony Lindgren wrote:
> > Seems to work based on few boot tests. Probably both should be applied,
> > my original patch to prevent spurious interrupts before things are
> > initialized,
> 
> you patch - do you mean disable irq  or clean up
> irq status regs before requesting irq? for me, more logical is to
> clean up irq status regs.

What I originally posted in this thread, clear irq registers
before requesting irq.

> this to disable interrupts before pm_runtime_suspend()
> > on exit path:
> > 
> > Tested-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> 
> So, you wanna me to send this as patch or wish to squash in yours?
> (I'll be able to do this only tomorrow)

I think this should be a separate patch for the exit path.

Regards,

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Grygorii Strashko]

On 12/08/2016 05:55 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org> [161208 15:38]:
>> On 12/08/2016 04:57 PM, Tony Lindgren wrote:
>>> Seems to work based on few boot tests. Probably both should be applied,
>>> my original patch to prevent spurious interrupts before things are
>>> initialized,
>>
>> you patch - do you mean disable irq  or clean up
>> irq status regs before requesting irq? for me, more logical is to
>> clean up irq status regs.
> 
> What I originally posted in this thread, clear irq registers
> before requesting irq.
> 
>> this to disable interrupts before pm_runtime_suspend()
>>> on exit path:
>>>
>>> Tested-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>>
>> So, you wanna me to send this as patch or wish to squash in yours?
>> (I'll be able to do this only tomorrow)
> 
> I think this should be a separate patch for the exit path.
> 

Actually, It seems correct solution will be to switch back from
devm_request_threaded_irq() to just request_threaded_irq(), because
similar problem can happen with dwc3_omap_remove() - there are no guarantee
that there will be no IRQ handler running when dwc3_omap_remove()
is executed and dwc3_omap_disable_irqs() will not help with that.


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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Roger Quadros]

Hi Tony,

On 08/12/16 05:21, Tony Lindgren wrote:
> Somehow starting with v4.9-rc7 there have been imprecise
> external aborts on omap5-uevm dwc3 controller. I have not been
> able to bisect what exactly triggered this as it does not always
> happen. It seems that something changed with probing that
> now exposes the issue:
> 
> Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> ...
> PC is at dwc3_omap_interrupt_thread+0x20/0x80
> LR is at irq_thread_fn+0x1c/0x54
> ...
> [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>]
> (irq_thread_fn+0x1c/0x54)
> [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> ...
> 
> Unable to handle kernel paging request at virtual address ffffffec
> ...
> Internal error: Oops: 37 [#2] SMP ARM
> PC is at kthread_data+0x4/0xc
> LR is at irq_thread_dtor+0x28/0xd0
> ...
> [<c035e0b4>] (kthread_data) from [<c038a5dc>] (irq_thread_dtor+0x28/0xd0)
> [<c038a5dc>] (irq_thread_dtor) from [<c035bef0>] (task_work_run+0xb8/0xdc)
> [<c035bef0>] (task_work_run) from [<c03448d4>] (do_exit+0x314/0xa20)
> [<c03448d4>] (do_exit) from [<c030bea8>] (die+0x410/0x474)
> [<c030bea8>] (die) from [<c0301350>] (do_DataAbort+0xb4/0xb8)
> [<c0301350>] (do_DataAbort) from [<c030c578>] (__dabt_svc+0x58/0x80)
> Exception stack(0xee777ec8 to 0xee777f10)
> 7ec0:                   0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00
> 7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18
> 7f00: c038a4d8 c0989fa8 60000013 ffffffff
> [<c030c578>] (__dabt_svc) from [<c0989fa8>] (dwc3_omap_interrupt_thread+0x20/0x80)
> [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>] (irq_thread_fn+0x1c/0x54)
> [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> 
> Fix the issue by making sure the dwc3 interrupts are disabled
> before we call devm_request_threaded_irq().
> 
> Note that there does not seem to be issues with the dwc3 wrapper
> accessing these registers even before the dwc3 core is probed.
> If some of these registers are specific to the dwc3 core, we can
> have IRQ disabled with irq_set_status_flags(omap->irq, IRQ_NOAUTOEN)
> on start-up instead of accessing the dwc3 registers.
> 
> Reported-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Cc: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
>  drivers/usb/dwc3/dwc3-omap.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -511,6 +511,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
>  	/* check the DMA Status */
>  	reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
>  
> +	dwc3_omap_disable_irqs(omap);
> +
>  	ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
>  					dwc3_omap_interrupt_thread, IRQF_SHARED,
>  					"dwc3-omap", omap);
> 

I'm not able to see this issue on my omap5-uevm or dra7-evm on v4.9-rc8.
What u-boot are you using? Are you using usb gadget in u-boot?

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [161209 08:09]:
> Hi Tony,
> 
> On 08/12/16 05:21, Tony Lindgren wrote:
> > Somehow starting with v4.9-rc7 there have been imprecise
> > external aborts on omap5-uevm dwc3 controller. I have not been
> > able to bisect what exactly triggered this as it does not always
> > happen. It seems that something changed with probing that
> > now exposes the issue:
> > 
> > Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> > ...
> > PC is at dwc3_omap_interrupt_thread+0x20/0x80
> > LR is at irq_thread_fn+0x1c/0x54
> > ...
> > [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>]
> > (irq_thread_fn+0x1c/0x54)
> > [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> > [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> > [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> > ...
> > 
> > Unable to handle kernel paging request at virtual address ffffffec
> > ...
> > Internal error: Oops: 37 [#2] SMP ARM
> > PC is at kthread_data+0x4/0xc
> > LR is at irq_thread_dtor+0x28/0xd0
> > ...
> > [<c035e0b4>] (kthread_data) from [<c038a5dc>] (irq_thread_dtor+0x28/0xd0)
> > [<c038a5dc>] (irq_thread_dtor) from [<c035bef0>] (task_work_run+0xb8/0xdc)
> > [<c035bef0>] (task_work_run) from [<c03448d4>] (do_exit+0x314/0xa20)
> > [<c03448d4>] (do_exit) from [<c030bea8>] (die+0x410/0x474)
> > [<c030bea8>] (die) from [<c0301350>] (do_DataAbort+0xb4/0xb8)
> > [<c0301350>] (do_DataAbort) from [<c030c578>] (__dabt_svc+0x58/0x80)
> > Exception stack(0xee777ec8 to 0xee777f10)
> > 7ec0:                   0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00
> > 7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18
> > 7f00: c038a4d8 c0989fa8 60000013 ffffffff
> > [<c030c578>] (__dabt_svc) from [<c0989fa8>] (dwc3_omap_interrupt_thread+0x20/0x80)
> > [<c0989fa8>] (dwc3_omap_interrupt_thread) from [<c038a4d8>] (irq_thread_fn+0x1c/0x54)
> > [<c038a4d8>] (irq_thread_fn) from [<c038a7b0>] (irq_thread+0x12c/0x1f0)
> > [<c038a7b0>] (irq_thread) from [<c035d6f0>] (kthread+0xdc/0xf4)
> > [<c035d6f0>] (kthread) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
> > 
> > Fix the issue by making sure the dwc3 interrupts are disabled
> > before we call devm_request_threaded_irq().
> > 
> > Note that there does not seem to be issues with the dwc3 wrapper
> > accessing these registers even before the dwc3 core is probed.
> > If some of these registers are specific to the dwc3 core, we can
> > have IRQ disabled with irq_set_status_flags(omap->irq, IRQ_NOAUTOEN)
> > on start-up instead of accessing the dwc3 registers.
> > 
> > Reported-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > Cc: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > ---
> >  drivers/usb/dwc3/dwc3-omap.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> > --- a/drivers/usb/dwc3/dwc3-omap.c
> > +++ b/drivers/usb/dwc3/dwc3-omap.c
> > @@ -511,6 +511,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
> >  	/* check the DMA Status */
> >  	reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
> >  
> > +	dwc3_omap_disable_irqs(omap);
> > +
> >  	ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
> >  					dwc3_omap_interrupt_thread, IRQF_SHARED,
> >  					"dwc3-omap", omap);
> > 
> 
> I'm not able to see this issue on my omap5-uevm or dra7-evm on v4.9-rc8.
> What u-boot are you using? Are you using usb gadget in u-boot?

Seems to be a bit hard to reproduce, see for example "v4.9-rc8-74-gea5a9eff96fe"
at kernelci.org for "mainline" failed jobs:

https://kernelci.org/job/mainline/

Regards,

Tony

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