Sebastian suggested to try this here:
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1264,8 +1264,11 @@ static void lan78xx_status(struct lan78xx_net *dev,
struct urb *urb)
netif_dbg(dev, link, dev->net, "PHY INTR: 0x%08x\n", intdata);
lan78xx_
> > Wouldn't handle_nested_irq() work here instead of the simple thingy?
>
> Daniel could you try this suggestion? Would it work?
[6.427289] [ cut here ]
[6.431977] kernel BUG at drivers/net/phy/mdio_bus.c:626!
[6.437453] Internal error: Oops - BUG: 0 [#1] PRE
On Tue, 22 Oct 2019 10:17:47 -0700
Jakub Kicinski 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 interrup
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 ha
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
On Fri, 18 Oct 2019 09:28:17 +0100,
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.
>
> This reverts the changes from cc89c323a30e ("lan78xx: Use
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.
This reverts the changes from cc89c323a30e ("lan78xx: Use irq_domain
for phy interrupt from USB Int. EP").
[4.886203] 000:
7 matches
Mail list logo
