linux-kernel - Re: [PATCH 2/6] rtc: isl12022: simplify some expressions

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:   Wed, 21 Sep 2022 09:12:08 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>, linux-rtc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/6] rtc: isl12022: simplify some expressions

On 21/09/2022 09:08:52+0200, Rasmus Villemoes wrote:
> On 14/09/2022 17.08, Alexandre Belloni wrote:
> > Hi,
> > 
> > On 30/08/2022 12:01:48+0200, Rasmus Villemoes wrote:
> >> These instances of '&client->dev' might as well be spelled 'dev', since
> >> 'client' has been computed from 'dev' via 'client =
> >> to_i2c_client(dev)'.
> >>
> >> Later patches will get rid of that local variable 'client', so remove
> >> these unnecessary references so those later patches become easier to
> >> read.
> >>
> >> Signed-off-by: Rasmus Villemoes <linux@...musvillemoes.dk>
> >> ---
> >>  drivers/rtc/rtc-isl12022.c | 11 +++++------
> >>  1 file changed, 5 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c
> >> index 2dc19061cf5f..5e6bb9153c89 100644
> >> --- a/drivers/rtc/rtc-isl12022.c
> >> +++ b/drivers/rtc/rtc-isl12022.c
> >> @@ -112,13 +112,13 @@ static int isl12022_rtc_read_time(struct device *dev, struct rtc_time *tm)
> >>  		return ret;
> >>  
> >>  	if (buf[ISL12022_REG_SR] & (ISL12022_SR_LBAT85 | ISL12022_SR_LBAT75)) {
> >> -		dev_warn(&client->dev,
> >> +		dev_warn(dev,
> > 
> > While at it, I would prefer that one to also become a dev_dbg
> 
> Well, I prefer to keep it, because my customer actually wants to use
> this information. Grepping it out from dmesg is of course not the best
> interface, but if it gets demoted to a dev_dbg() it doesn't even get there.
> 

There is a proper userspace interface, look for RTC_VL_READ.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com