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

Dragan Simic
2024-06-23T05:41:43Z

Hello Uwe,

On 2024-06-23 02:20, Uwe Kleine-König wrote:
> On Sat, Jun 22, 2024 at 10:45:22PM +0200, Dragan Simic wrote:
>> 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:
>> > > >>>> + dev_info(&pdev->dev, "Registered Rockchip hwrng\n");
>> > > >>>
>> > > >>> Drop, driver should be silent on success.
>> > > >>
>> > [...]
>> > 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.
>
> IMHO it's a bit sad, that there is such a long thread about something
> so
> trivial, but I want to make a few points:
>
> - not all dmesg implementations support this:
>
> root@machine:~ dmesg --level=err,warn
> dmesg: unrecognized option '--level=err,warn'
> BusyBox v1.36.1 () multi-call binary.
>
> Usage: dmesg [-cr] [-n LEVEL] [-s SIZE]
>
> Print or control the kernel ring buffer
>
> -c Clear ring buffer after printing
> -n LEVEL Set console logging level
> -s SIZE Buffer size
> -r Print raw message buffer
>
> - Your argument that the output of this dev_info can easily be ignored
> is a very weak reason to keep it.
>
> - I personally consider it hard sometimes to accept feedback if I
> think
> it's wrong and there is a good reason to do it the way I want it.
> But there are now three people opposing your position, who brought
> forward (IMHO) good reasons and even a constructive alternative was
> presented. Please stay open minded while weighting the options.
> The questions to ask here include:
>
> - How many people care for this message? During every boot? Is it
> maybe enough for these people to check in /sys if the device
> probed successfully? Or maybe even the absence of an error
> message
> is enough?
> - How many people get this message and don't care about the
> presented information? How many people are even annoyed by it?
> - Is the delay and memory usage introduced by this message
> justified
> then, even if it's small?

I'm sorry if my responses caused any inconvenience. I find most of your
points totally valid, but there are a couple of them I could continue
arguing about. Though, as you also pointed out, my opinion has been
already outvoted, so I'll remain silent.