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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux