Received-SPF: pass (google.com: domain of linux-kernel+bounces-196884-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 31 May 2024 16:30:58 +0300
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Alexander Stein <alexander.stein@ew.tq-group.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
Message-ID: <ZlnREkzvS0rnMUDv@smile.fi.intel.com>
References: <20240530191418.1138003-1-andriy.shevchenko@linux.intel.com>
 <20240530191418.1138003-3-andriy.shevchenko@linux.intel.com>
 <7750850.EvYhyI6sBW@steina-w>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7750850.EvYhyI6sBW@steina-w>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

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.

-- 
With Best Regards,
Andy Shevchenko