netdev - RE: [PATCH] net: txgbe: fix GPIO interrupt blocking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <003801da6249$888e4210$99aac630$@trustnetic.com>
Date: Sun, 18 Feb 2024 17:04:52 +0800
From: Jiawen Wu <jiawenwu@...stnetic.com>
To: "'Andrew Lunn'" <andrew@...n.ch>
Cc: <davem@...emloft.net>,
	<edumazet@...gle.com>,
	<kuba@...nel.org>,
	<pabeni@...hat.com>,
	<maciej.fijalkowski@...el.com>,
	<netdev@...r.kernel.org>,
	<mengyuanlou@...-swift.com>
Subject: RE: [PATCH] net: txgbe: fix GPIO interrupt blocking

On Tue, Feb 6, 2024 11:29 PM, Andrew Lunn wrote:
> On Tue, Feb 06, 2024 at 03:08:24PM +0800, Jiawen Wu wrote:
> > GPIO interrupt is generated before MAC IRQ is enabled, it causes
> > subsequent GPIO interrupts that can no longer be reported if it is
> > not cleared in time. So clear GPIO interrupt status at the right
> > time.
> 
> This does not sound correct. Since this is an interrupt controller, it
> is a level interrupt. If its not cleared, as soon as the parent
> interrupt is re-enabled, is should cause another interrupt at the
> parent level. Servicing that interrupt, should case a descent to the
> child, which will service the interrupt, and atomically clear the
> interrupt status.
> 
> Is something wrong here, like you are using edge interrupts, not
> level?

Yes, it is edge interrupt.

> 
> > And executing function txgbe_gpio_irq_ack() manually since
> > handle_nested_irq() does not call .irq_ack for irq_chip.
> 
> I don't know the interrupt code too well, so could you explain this in
> more detail. Your explanation sounds odd to me.

This is because I changed the interrupt controller in
https://git.kernel.org/netdev/net-next/c/aefd013624a1.
In the previous interrupt controller, .irq_ack in struct irq_chip is called
to clear the interrupt after the GPIO interrupt is handled. But I found
that in the current interrupt controller, this .irq_ack is not called. Maybe
I don't know enough about this interrupt code, I have to manually add
txgbe_gpio_irq_ack() to clear the interrupt in the handler.

> 
> What is the big picture problem here? Do you have the PHY interrupt
> connected to a GPIO and you are loosing PHY interrupts?

No, PHY interrupt is connected to the LINK UP/DOWN filed in the MAC
interrupt. The problem I encountered was that the GPIO interrupts were
not cleaned up in time and could not continue to generate the next GPIO
interrupt.