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

[Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

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