[<prev] [next>] [day] [month] [year] [list]
Message-ID: <9d0ce727-6473-e326-6b75-f8415fdb85b9@linaro.org>
Date: Mon, 3 Jul 2023 14:28:25 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Yangtao Li <frank.li@...o.com>,
Thomas Gleixner <tglx@...utronix.de>,
Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc: miquel.raynal@...tlin.com, rafael@...nel.org,
daniel.lezcano@...aro.org, amitk@...nel.org, rui.zhang@...el.com,
mmayer@...adcom.com, bcm-kernel-feedback-list@...adcom.com,
florian.fainelli@...adcom.com, shawnguo@...nel.org,
s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
linux-imx@....com, agross@...nel.org, andersson@...nel.org,
konrad.dybcio@...aro.org, thara.gopinath@...il.com,
heiko@...ech.de, mcoquelin.stm32@...il.com,
alexandre.torgue@...s.st.com, thierry.reding@...il.com,
jonathanh@...dia.com, matthias.bgg@...il.com,
angelogioacchino.delregno@...labora.com,
srinivas.pandruvada@...ux.intel.com,
DLG-Adam.Ward.opensource@...renesas.com, shangxiaojing@...wei.com,
bchihi@...libre.com, wenst@...omium.org,
hayashi.kunihiko@...ionext.com,
niklas.soderlund+renesas@...natech.se, chi.minghao@....com.cn,
johan+linaro@...nel.org, jernej.skrabec@...il.com,
linux-pm@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, linux-tegra@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 01/15] genirq/devres: Add error information printing
for devm_request_threaded_irq()
On 03/07/2023 13:54, Yangtao Li wrote:
> Hi Krzysztof,
>
> On 2023/6/30 19:11, Thomas Gleixner wrote:
>> On Tue, Jun 27 2023 at 13:00, Uwe Kleine-König wrote:
>>> On Tue, Jun 27, 2023 at 06:12:01PM +0800, Yangtao Li wrote:
>>>
>>> While I assume changing to dev_err_probe is a result of my concern that
>>> no error should be printed when rc=-EPROBEDEFER, my other concern that
>>> adding an error message to a generic allocation function is a bad idea
>>> still stands.
>> I agree in general, but if you actually look at the call sites of
>> devm_request_threaded_irq() then the vast majority of them print more or
>> less lousy error messages. A quick grep/sed/awk/sort/uniq revealed
>>
>> 519 messages total (there are probably more)
>>
>> 352 unique messages
>>
>> 323 unique messages after lower casing
>>
>> Those 323 are mostly just variants of the same patterns with slight
>> modifications in formatting and information provided.
>>
>> 186 of these messages do not deliver any useful information,
>> e.g. "no irq", "
>>
>> The most useful one of all is: "could request wakeup irq: %d"
>>
>> So there is certainly an argument to be made that this particular
>> function should print a well formatted and informative error message.
>>
>> It's not a general allocator like kmalloc(). It's specialized and in the
>> vast majority of cases failing to request the interrupt causes the
>> device probe to fail. So having proper and consistent information why
>> the device cannot be used _is_ useful.
>>
>> Yangtao: The way how this is attempted is not useful at all.
>>
>> 1) The changelog is word salad and provides 0 rationale
>>
>> Also such series require a cover letter...
>>
>> 2) The dev_err() which is added is not informative at all and cannot
>> replace actually useful error messages. It's not that hard to
>> make it useful.
>>
>> 2) Adding the printks unconditionally first will emit two messages
>> with different content.
>>
>> This is not how such changes are done.
>>
>> The proper approach is to create a wrapper function which emits
>> the error message:
>>
>> wrapper(....., const char *info)
>> {
>> ret = devm_request_threaded_irq(....);
>> if (ret < 0) {
>> dev_err(dev, "Failed to request %sinterrupt %u %s %s: %d\n,
>> thread_fn ? "threaded " : "",
>> irq, devname, info ? : "", ret);
>> }
>> return ret;
>> }
>
>
> Here.
>
> V3 was modified according to tglx's suggestion, if there is any problem,
> please point out.
The comment was about request_thread_irq, not about devres alloc. Don't
mix the places. Really, since when do we print any errors on ENOMEM?
Best regards,
Krzysztof
Powered by blists - more mailing lists