Message-ID: <87h605o8vd.ffs@tglx>
Date: Tue, 24 Jun 2025 10:13:10 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Pan Chuang <panchuang@...o.com>, "Rafael J. Wysocki"
 <rafael@...nel.org>, Daniel Lezcano <daniel.lezcano@...aro.org>, Zhang Rui
 <rui.zhang@...el.com>, Lukasz Luba <lukasz.luba@....com>, Miquel Raynal
 <miquel.raynal@...tlin.com>, Markus Mayer <mmayer@...adcom.com>, Broadcom
 internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
 Florian Fainelli <florian.fainelli@...adcom.com>, Shawn Guo
 <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix
 Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
 zhanghongchen <zhanghongchen@...ngson.cn>, Yinbo Zhu
 <zhuyinbo@...ngson.cn>, Amit Kucheria <amitk@...nel.org>, Thara Gopinath
 <thara.gopinath@...il.com>, Niklas Söderlund
 <niklas.soderlund@...natech.se>, Geert Uytterhoeven
 <geert+renesas@...der.be>, Magnus Damm <magnus.damm@...il.com>, Heiko
 Stuebner <heiko@...ech.de>, Bartlomiej Zolnierkiewicz
 <bzolnier@...il.com>, Krzysztof Kozlowski <krzk@...nel.org>, Alim Akhtar
 <alim.akhtar@...sung.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>, Vasily Khoruzhick
 <anarsoul@...il.com>, Yangtao Li <tiny.windzz@...il.com>, Chen-Yu Tsai
 <wens@...e.org>, Jernej Skrabec <jernej.skrabec@...il.com>, Samuel Holland
 <samuel@...lland.org>, Thierry Reding <thierry.reding@...il.com>, Jonathan
 Hunter <jonathanh@...dia.com>, Kunihiko Hayashi
 <hayashi.kunihiko@...ionext.com>, Masami Hiramatsu <mhiramat@...nel.org>,
 Matthias Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
 <angelogioacchino.delregno@...labora.com>, Srinivas Pandruvada
 <srinivas.pandruvada@...ux.intel.com>, Greg KH
 <gregkh@...uxfoundation.org>, Peter Zijlstra <peterz@...radead.org>,
 Nícolas F. R. A. Prado <nfraprado@...labora.com>,
 Conor Dooley
 <conor.dooley@...rochip.com>, Julien Panis <jpanis@...libre.com>, Arnd
 Bergmann <arnd@...db.de>, Uwe Kleine-König
 <u.kleine-koenig@...libre.com>,
 Colin Ian King <colin.i.king@...il.com>, Raphael Gallais-Pou
 <rgallaispou@...il.com>, Patrice Chotard <patrice.chotard@...s.st.com>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>, "Jiri Slaby (SUSE)"
 <jirislaby@...nel.org>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 Andrew Morton <akpm@...ux-foundation.org>, Costa Shulyupin
 <costa.shul@...hat.com>, Yury Norov <yury.norov@...il.com>, Cheng-Yang
 Chou <yphbchou0911@...il.com>, Caleb Sander Mateos
 <csander@...estorage.com>, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 imx@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
 linux-renesas-soc@...r.kernel.org, linux-rockchip@...ts.infradead.org,
 linux-samsung-soc@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com, linux-sunxi@...ts.linux.dev,
 linux-tegra@...r.kernel.org, linux-mediatek@...ts.infradead.org
Cc: Yangtao Li <frank.li@...o.com>, Uwe Kleine-König
 <u.kleine-koenig@...gutronix.de>, Jonathan Cameron
 <Jonathan.Cameron@...wei.com>, Pan Chuang <panchuang@...o.com>
Subject: Re: [PATCH v6 01/24] genirq/devres: Add
 devm_request_threaded_irq_probe() and devm_request_irq_probe()

On Mon, Jun 23 2025 at 20:30, Pan Chuang wrote:
> +/**
> + * devm_request_threaded_irq_probe - request irq for a managed device with error msg (recommended in probe)
> + * @dev:	Device to request interrupt for
> + * @irq:	Interrupt line to allocate
> + * @handler:	Function to be called when the IRQ occurs
> + * @thread_fn:	Function to be called in a threaded interrupt context. NULL
> + *		for devices which handle everything in @handler
> + * @irqflags:	Interrupt type flags
> + * @devname:	An ascii name for the claiming device, dev_name(dev) if NULL
> + * @dev_id:	A cookie passed back to the handler function
> + * @info:	Optional additional error log
> + *
> + * This is a variant of the devm_request_threaded_irq function.
> + * It will print an error message by default when the request fails,
> + * and the consumer can add a special error msg.
> + *
> + * Except for the extra @info argument, this function takes the
> + * same arguments and performs the same function as
> + * devm_request_threaded_irq(). IRQs requested with this function will be
> + * automatically freed on driver detach.

I really have to ask why you need the extra info argument. It's not
providing any really value.

What's important when the interrupt request fails?

    1) The device, which is identifiable by @devname and/or dev_name(@dev)

    2) The interrupt number

    3) The error code

If you want to be more expressive then you can also print out the
handler function symbols, which makes it even more useful to map back
into the affected driver.

As you cited correctly I said back then:

  "So there is certainly an argument to be made that this particular
   function should print a well formatted and informative error
   message."

This particular function is: devm_request_threaded_irq().

IOW, I did not ask you should go an create a new one, right?

The extra @info argument is just proliferating the nonsensical
information which driver developers put into the output. I just looked
through a couple of your thermal patches (hint, I had to chase them
manually because you failed to thread them properly). While most of them
provide NULL, the two adding 'alarm' are really not providing any useful
information.

The point is, that the information is aimed at developers and not to be
helpful for Joe User to identify/fix a problem. If the driver
developer/maintainer is not able to track back the information (name,
number, error code) to the driver in question, then the added "foo" info
is not going to make him any smarter.

If that happens, then being able to map it back to the driver is only 1%
of the problem analysis, simply because you need to decode the
underlying problem (DT, vector exhaustion, memory exhaustion ....) to be
able to address it.

So just make devm_request.*irq() emit a uniform and informative message
on fail and you can go and remove all the homebrewn useless error prints
from the drivers.

It does not matter at all if there are duplicated error messages for a
release or two until all drivers have been cleaned up. This is not the
common case and only rarely triggered. So what?

> +int devm_request_threaded_irq_probe(struct device *dev, unsigned int irq,
> +				    irq_handler_t handler, irq_handler_t thread_fn,
> +				    unsigned long irqflags, const char *devname,
> +				    void *dev_id, const char *info)
> +{
> +	int rc;
> +
> +	rc = devm_request_threaded_irq(dev, irq, handler, NULL, irqflags, devname, dev_id);

This is just wrong as you fail to hand in thread_fn.

Q: How was this code ever tested?
A: Not at all.

> Could you please consider merging the entire series into your branch? 

You're seriously asking that for something which is so obviously broken?

> +	if (rc) {
> +		return dev_err_probe(dev, rc, "Failed to request %sinterrupt %u %s %s\n",
> +				     thread_fn ? "threaded " : "", irq, devname ? : dev_name(dev),
> +				     info ? : "");

This is wrong too because devm_request_threaded_irq() allows you to hand
in both a hard interrupt and a threaded handler and either one of them
can be NULL.

So what you want to add in devm_request_threaded_irq() is something like
this:

	if (rc < 0) {
		return dev_err_probe(dev, rc, "request_irq(%u) %pS %pS %s\n",
                        	     handler, thread_fn, devname ? : "");
        }

dev_err_probe() already prefixes the caller string with 'error ', so
there is no need for a lenghty 'failed to request ....' novel.

Thanks,

        tglx

Powered by blists - more mailing lists