[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ea9f570c-b135-4a98-91ea-ceeb2f48a0e5@linaro.org>
Date: Tue, 20 May 2025 08:06:22 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Johan Hovold <johan@...nel.org>
Cc: Robert Foss <rfoss@...nel.org>, Todor Tomov <todor.too@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>, linux-media@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] media: qcom: camss: vfe: Stop spamming logs with
version
On 30/04/2025 10:33, Krzysztof Kozlowski wrote:
> On 30/04/2025 10:30, Bryan O'Donoghue wrote:
>> On 30/04/2025 09:19, Krzysztof Kozlowski wrote:
>>> If anyone wants to know it and cannot deduce from compatible, then add
>>> debugfs interface.
>>
>> dev_dbg(); isn't too offensive really IMO but if it really bothers you
>> switching to debugfs would be fine.
>
> Yes, please. Dmesg should be only contain issues or some useful
> debugging data. Probe success is not useful. It duplicates sysfs and
> tracing. Version of hardware - well, I am sure it duplicates the compatible.
To recall: kernel coding style is also clear here:
"When drivers are working properly they are quiet,"
and kernel debugging guide as well:
"In almost all cases the debug statements shouldn't be upstreamed, as a
working driver is supposed to be silent."
So I really do not get why this driver deserved exception. Nevertheless
I think we agreed that these logs can go away, thus I just sent a v2
with a bit extended commit msg.
Best regards,
Krzysztof
Powered by blists - more mailing lists