Received-SPF: pass (google.com: domain of linux-kernel+bounces-198833-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <brgl@bgdev.pl>
Subject: Re: [PATCH v2 2/2] gpiolib: Show more info for interrupt only lines in debugfs
Date: Mon, 03 Jun 2024 11:06:06 +0200
Message-ID: <12451373.O9o76ZdvQC@steina-w>
Organization: TQ-Systems GmbH
In-Reply-To: <ZlnREkzvS0rnMUDv@smile.fi.intel.com>
References: <20240530191418.1138003-1-andriy.shevchenko@linux.intel.com> <7750850.EvYhyI6sBW@steina-w> <ZlnREkzvS0rnMUDv@smile.fi.intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

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.
> >=20
> > I was trying to test this on TQMa8MPQL (i.MX8MP) using gpio-mxc.c.
>=20
> Thank you for trying!
>=20
> > 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_re=
sources
> > similar to what pinctrl-at91.c is doing?
>=20
> I haven't looked deeply into this and I don't know if it's relevant, but.=
=2E.
>=20
> The idea is that GPIO driver has an IRQ chip that announces handle_bad_ir=
q()
> as a handler and IRQ_TYPE_NONE as default type at probe stage. It also ne=
eds
> to implement ->set_irq_type() callback where actual handler is going to be
> locked.
>=20
> 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.
>=20
> 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
=2D-=20
TQ-Systems GmbH | M=FChlstra=DFe 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M=FCnchen, HRB 105018
Gesch=E4ftsf=FChrer: Detlef Schneider, R=FCdiger Stahl, Stefan Schneider
http://www.tq-group.com/