netdev - Re: [PATCH net-next v8 6/9] net: txgbe: Support GPIO to SFP socket

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: <f0b571ab-544b-49c3-948f-d592f931673b@lunn.ch>
Date: Fri, 19 May 2023 15:13:04 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jiawen Wu <jiawenwu@...stnetic.com>
Cc: 'Andy Shevchenko' <andy.shevchenko@...il.com>, netdev@...r.kernel.org,
	jarkko.nikula@...ux.intel.com, andriy.shevchenko@...ux.intel.com,
	mika.westerberg@...ux.intel.com, jsd@...ihalf.com,
	Jose.Abreu@...opsys.com, hkallweit1@...il.com,
	linux@...linux.org.uk, linux-i2c@...r.kernel.org,
	linux-gpio@...r.kernel.org, mengyuanlou@...-swift.com
Subject: Re: [PATCH net-next v8 6/9] net: txgbe: Support GPIO to SFP socket

> I have one MSI-X interrupt for all general MAC interrupt (see TXGBE_PX_MISC_IEN_MASK).
> It has 32 bits to indicate various interrupts, GPIOs are the one of them. When GPIO
> interrupt is determined, GPIO_INT_STATUS register should be read to determine
> which GPIO line has changed state.

So you have another interrupt controller above the GPIO interrupt
controller. regmap-gpio is pushing you towards describing this
interrupt controller as a Linux interrupt controller.

When you look at drivers handling interrupts, most leaf interrupt
controllers are not described as Linux interrupt controllers. The
driver interrupt handler reads the interrupt status register and
internally dispatches to the needed handler. This works well when
everything is internal to one driver.

However, here, you have two drivers involved, your MAC driver and a
GPIO driver instantiated by the MAC driver. So i think you are going
to need to described the MAC interrupt controller as a Linux interrupt
controller.

Take a look at the mv88e6xxx driver, which does this. It has two
interrupt controller embedded within it, and they are chained.

> > If you are getting errors when removing the driver it means you are
> > missing some level of undoing what us done in probe. Are you sure
> > regmap_del_irq_chip() is being called on unload?
> 
> I used devm_* all when I registered them.

Look at the ordering. Is regmap_del_irq_chip() being called too late?
I've had problems like this with the mv88e6xxx driver and its
interrupt controllers. I ended up not using devm_ so i had full
control over the order things got undone. In that case, the external
devices was PHYs, with the PHY interrupt being inside the Ethernet
switch, which i exposed using a Linux interrupt controller.

	Andrew