linux-kernel - Re: [PATCH] rtc: m41t80: Complete error propagation from SMBus calls

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 14 Nov 2018 10:57:37 +0100
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     "Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>,
        Matt Turner <mattst88@...il.com>, linux-rtc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rtc: m41t80: Complete error propagation from SMBus calls

On 07/11/2018 02:39:51+0000, Maciej W. Rozycki wrote:
> Complement commit 85d77047c4ea ("drivers/rtc/rtc-m41t80.c: propagate 
> error value from smbus functions") and correct the remaining places that 
> fail to propagate the error code from SMBus calls.
> 
> Signed-off-by: Maciej W. Rozycki <macro@...ux-mips.org>
> References: 85d77047c4ea ("drivers/rtc/rtc-m41t80.c: propagate error value from smbus functions")
> ---
> Hi,
> 
>  I think this does not qualify for backporting, but please feel free to 
> decide otherwise.
> 
>  This change I did verify at run time to the extent I was able to, but I 
> didn't try to trigger artificial errors.  Also the M41T81, which is the 
> device I've been using this driver with, does not have battery failure 
> indication implemented, so I could not execute the procfs handling path 
> (again without making some artificial changes).  These changes should be 
> obvious regardless.
> 
>  I'll be posting further patches over the coming weeks, based on my 
> original effort as archived here: <https://lkml.org/lkml/2008/5/12/385>,
> <https://lore.kernel.org/patchwork/project/lkml/list/?series=73524&archive=both> 
> However I have just realised they'll need another iteration before I post 
> them.  So for now just these two obvious fixes.
> 

Regarding the persistent part, do you really need more than what is
provided? As far as I know, the timekeeping core is already taking care
of using the best source to get the suspended time.


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