On Tue, 22 Oct 2019 10:17:47 -0700
Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx> wrote:
> On Fri, 18 Oct 2019 15:15:32 +0200, Sebastian Andrzej Siewior wrote:
> > On 2019-10-18 10:28:17 [+0200], Daniel Wagner wrote:
> > > handle_simple_irq() expect interrupts to be disabled. The USB
> > > framework is using threaded interrupts, which implies that interrupts
> > > are re-enabled as soon as it has run.
> >
> > Without threading interrupts, this is invoked in pure softirq context
> > since commit ed194d1367698 ("usb: core: remove local_irq_save() around
> > ->complete() handler") where the local_irq_disable() has been removed.
> >
> > This is probably not a problem because the lock is never observed with
> > in IRQ context.
> >
> > Wouldn't handle_nested_irq() work here instead of the simple thingy?
>
> Daniel could you try this suggestion? Would it work?
>
> I'm not sure we are at the stage yet where "doesn't work on -rt" is
> sufficient reason to revert a working upstream patch. Please correct
> me if I'm wrong.
But that's the thing: it doesn't work at all, RT or not (it spits an
awful warning). See the various reports Daniel linked to. Maintainers
have been completely unresponsive, and the RPI folks have their own out
of tree hack, I believe (which probably reverts to the previous,
working situation where the driver uses polling for some of its PHY
handling business).
Sebastian's suggestion is definitely worth trying if you have the HW
though.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
