linux-kernel - Re: [PATCH 2/8] i2c: i2c-qcom-geni: Signify successful driver probe

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]

Message-ID: <20190605083353.GD29637@localhost>
Date:   Wed, 5 Jun 2019 10:33:53 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Johan Hovold <johan@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>, balbi@...nel.org,
        wsa+renesas@...g-engineering.com, gregkh@...uxfoundation.org,
        linus.walleij@...aro.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, david.brown@...aro.org,
        alokc@...eaurora.org, kramasub@...eaurora.org,
        linux-i2c@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, andy.gross@...aro.org,
        jlhugo@...il.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/8] i2c: i2c-qcom-geni: Signify successful driver probe

On Wed, Jun 05, 2019 at 09:20:47AM +0100, Lee Jones wrote:
> On Wed, 05 Jun 2019, Johan Hovold wrote:

> > No, we don't add noise like this to the logs just because it may be
> > useful while debugging. Even one-liners add up.
> 
> One line per device is should not cause an issue.
> 
> Problems occur when developers try to print all kinds of device
> specifics to the boot log.  A simple, single line for such an
> important device/controller has more benefits than drawbacks.

What about the thousands of probe functions which do not currently spam
the logs? If you want to see all successful probes reliably, you tell
driver core to print it.

> > There are plenty of options for debugging already ranging from adding a
> > temporary dev_info() to the probe function in question to using dynamic
> > debugging to have driver core log every successful probe.
> 
> This is what I ended up doing.  It was time consuming to parse though
> a log of that size when you have no paging or keyboard.

With the right command-line option to enable dynamic debugging you get
one line per successful probe, just like you wanted. Or are you now
saying that one-line per device is too much after all? ;)

> > And in this case you say the driver was in fact already bound; that can
> > easily be verified through sysfs too in case things aren't behaving the
> > way you expect.
> 
> Not in a non-booting system with no keyboard you can't. ;)

Fair enough, but the above would still work.

Johan