linux-kernel - Re: [PATCH v3 2/3] hwrng: add Rockchip SoC hwrng driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 22 Jun 2024 22:45:22 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Heiko Stübner <heiko@...ech.de>
Cc: Uwe Kleine-König <ukleinek@...nel.org>, Krzysztof
 Kozlowski <krzk@...nel.org>, Daniel Golle <daniel@...rotopia.org>, Aurelien
 Jarno <aurelien@...el32.net>, Olivia Mackall <olivia@...enic.com>, Herbert
 Xu <herbert@...dor.apana.org.au>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Philipp
 Zabel <p.zabel@...gutronix.de>, Sebastian Reichel
 <sebastian.reichel@...labora.com>, Anand Moon <linux.amoon@...il.com>,
 Sascha Hauer <s.hauer@...gutronix.de>, Martin Kaiser <martin@...ser.cx>, Ard
 Biesheuvel <ardb@...nel.org>, linux-crypto@...r.kernel.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/3] hwrng: add Rockchip SoC hwrng driver

Hello Heiko,

On 2024-06-22 22:26, Heiko Stübner wrote:
> Am Samstag, 22. Juni 2024, 12:29:33 CEST schrieb Dragan Simic:
>> On 2024-06-22 00:16, Uwe Kleine-König wrote:
>> > On 6/21/24 20:13, Dragan Simic wrote:
>> >> On 2024-06-21 11:57, Krzysztof Kozlowski wrote:
>> >>> On 21/06/2024 03:25, Daniel Golle wrote:
>> >>>> From: Aurelien Jarno <aurelien@...el32.net>
>> >>
>> >> [snip]
>> >>
>> >>>> +    pm_runtime_set_autosuspend_delay(dev,
>> >>>> RK_RNG_AUTOSUSPEND_DELAY);
>> >>>> +    pm_runtime_use_autosuspend(dev);
>> >>>> +    pm_runtime_enable(dev);
>> >>>> +
>> >>>> +    ret = devm_hwrng_register(dev, &rk_rng->rng);
>> >>>> +    if (ret)
>> >>>> +        return dev_err_probe(&pdev->dev, ret, "Failed to register
>> >>>> Rockchip hwrng\n");
>> >>>> +
>> >>>> +    dev_info(&pdev->dev, "Registered Rockchip hwrng\n");
>> >>>
>> >>> Drop, driver should be silent on success.
>> >>
>> >> I respectfully disagree.  Many drivers print a single line upon
>> >> successful probing, which I find very useful.  In this particular
>> >> case, it's even more useful, because some people may be concerned
>> >> about the use of hardware TRNGs, so we should actually make sure
>> >> to announce it.
>> >
>> > I agree to Krzysztof here. From the POV of a driver author, your own
>> > driver is very important and while you write it, it really interests
>> > *you* if the driver is successfully probed. However from a system
>> > perspective these are annoying: There are easily >50 devices[1] on a
>> > system, if all of these print a message in probe, you have little
>> > chance
>> > to see the relevant messages. Even if every driver author thinks their
>> > work is a special snow flake that is worth announcing, in practice
>> > users
>> > only care about your driver if there is a problem. Additionally each
>> > message takes time and so delays the boot process. Additionally each
>> > message takes place in the printk ring buffer and so edges out earlier
>> > messages that might be more important.
>> 
>> Well, I don't find those messages annoying, for the drivers I've had
>> nothing to do with.  Also, in my experience, 99.9% of users don't care
>> about the kernel messages at all, be it everything hunky-dory, or be
>> it something really wrong somewhere.
>> 
>> > So +1 for dropping the dev_info() or at least using dev_debug() for it.
> 
> Just for 2ct ... I'm also in the don't print too much camp ;-) .
> When parsing kernel logs to see where things fail, messages just
> telling me about sucesses make things more difficult.
> 
> So really this message should be dropped or at least as Uwe suggests
> made a dev_dbg.

As a note, "dmesg --level=err,warn", for example, is rather useful
when it comes to filtering the kernel messages to see only those that
are signs of a trouble.