linux-kernel - Re: [PATCH v2 2/2] gpiolib: Show more info for interrupt only lines in debugfs

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]

Date: Mon, 03 Jun 2024 11:06:06 +0200
From: Alexander Stein <alexander.stein@...tq-group.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org, Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski <brgl@...ev.pl>
Subject: Re: [PATCH v2 2/2] gpiolib: Show more info for interrupt only lines in debugfs

Hi,

Am Freitag, 31. Mai 2024, 15:30:58 CEST schrieb Andy Shevchenko:
> On Fri, May 31, 2024 at 01:19:56PM +0200, Alexander Stein wrote:
> > Am Donnerstag, 30. Mai 2024, 21:12:30 CEST schrieb Andy Shevchenko:
> > > Show more info for interrupt only lines in debugfs. It's useful
> > > to monitor the lines that have been never requested as GPIOs,
> > > but IRQs.
> > 
> > I was trying to test this on TQMa8MPQL (i.MX8MP) using gpio-mxc.c.
> 
> Thank you for trying!
> 
> > But apparently this series only has an effect when gpiochip_lock_as_irq()
> > is called eventually. I'm wondering what needs to be done so IRQ only
> > GPIOs are listed in debugfs. Using irq_request_resources/irq_release_resources
> > similar to what pinctrl-at91.c is doing?
> 
> I haven't looked deeply into this and I don't know if it's relevant, but...
> 
> The idea is that GPIO driver has an IRQ chip that announces handle_bad_irq()
> as a handler and IRQ_TYPE_NONE as default type at probe stage. It also needs
> to implement ->set_irq_type() callback where actual handler is going to be
> locked.
> 
> That's what I do not see implemented in the driver. Moreover, I do see it
> implements its own ->to_irq() callback which shouldn't be there.
> 
> Taking all above into consideration _I think_ the drivers need a bit of
> refreshments.

I noticed this driver is using irq_chip_generic and a dedicated irq domain.
I'm not sure if this is superseded meanwhile using the integrated IRQ chip
inside that GPIO chip.
Thanks for looking into this.

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/