linux-kernel - Re: [PATCH] nvmem: include bit index in cell sysfs file name

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: Thu, 25 Jan 2024 13:15:26 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Miquel Raynal" <miquel.raynal@...tlin.com>
Cc: "Arnd Bergmann" <arnd@...nel.org>,
 "Srinivas Kandagatla" <srinivas.kandagatla@...aro.org>,
 regressions@...ts.linux.dev,
 Rafał Miłecki <rafal@...ecki.pl>,
 "Chen-Yu Tsai" <wenst@...omium.org>,
 "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, asahi@...ts.linux.dev,
 "Sven Peter" <sven@...npeter.dev>, "Michael Walle" <michael@...le.cc>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nvmem: include bit index in cell sysfs file name

On Wed, Jan 24, 2024, at 23:11, Miquel Raynal wrote:
> Hi Arnd,
>
> arnd@...db.de wrote on Wed, 24 Jan 2024 20:49:53 +0100:
>
>> On Wed, Jan 24, 2024, at 18:22, Miquel Raynal wrote:
>> > arnd@...nel.org wrote on Mon, 22 Jan 2024 16:34:10 +0100:
>> >  
>> >> From: Arnd Bergmann <arnd@...db.de>
>> >> 
>> >> 
>> >> As far as I can tell, this is a problem for any device with multiple cells on
>> >> different bits of the same address. Avoid the issue by changing the file name
>> >> to include the first bit number.  
>> >
>> > There is only one bit number right? We are talking about byte offsets
>> > so this value can only range from 0 to 7? If we understand each other
>> > correctly then why not, I'm fine with the extra ",0" thing.  
>> 
>> On the Apple M1, the nvmem registers are 32 bit wide, so the
>> bit numbers can go up to 31. I can imagine some system using
>> 64-bit registers, but it's unlikely to be higher than that.
>
> In this case we will soon or later have a problem again. Can we include
> the full offset of the bit and not just the first digit?

I thought that is what my patch does, maybe I don't
undestand the problem you are referring to. This is what
I see on my system with the patch applied:

$ cd /sys/devices/platform/soc@...000000/2922bc000.efuse
$ find . -name efuse\*
/apple_efuses_nvmem0/cells/efuse@a24,11
/apple_efuses_nvmem0/cells/efuse@a24,9
/apple_efuses_nvmem0/cells/efuse@a1c,f
/apple_efuses_nvmem0/cells/efuse@a20,17
/apple_efuses_nvmem0/cells/efuse@a20,1e
/apple_efuses_nvmem0/cells/efuse@a18,0
/apple_efuses_nvmem0/cells/efuse@a14,b
/apple_efuses_nvmem0/cells/efuse@a1c,1f
/apple_efuses_nvmem0/cells/efuse@a1c,d
/apple_efuses_nvmem0/cells/efuse@a20,1c
/apple_efuses_nvmem0/cells/efuse@a18,15
/apple_efuses_nvmem0/cells/efuse@a14,0
/apple_efuses_nvmem0/cells/efuse@a1c,14
/apple_efuses_nvmem0/cells/efuse@a24,3
/apple_efuses_nvmem0/cells/efuse@a20,7
/apple_efuses_nvmem0/cells/efuse@a18,5
/apple_efuses_nvmem0/cells/efuse@a10,16
/apple_efuses_nvmem0/cells/efuse@a1c,12
/apple_efuses_nvmem0/cells/efuse@a20,5
/apple_efuses_nvmem0/cells/efuse@a18,3
/apple_efuses_nvmem0/cells/efuse@a18,a
/apple_efuses_nvmem0/cells/efuse@a10,1b
/apple_efuses_nvmem0/cells/efuse@a14,5
/apple_efuses_nvmem0/cells/efuse@a1c,19
/apple_efuses_nvmem0/cells/efuse@a24,f
/apple_efuses_nvmem0/cells/efuse@a18,1d
/apple_efuses_nvmem0/cells/efuse@a14,13
/apple_efuses_nvmem0/cells/efuse@a18,8
/apple_efuses_nvmem0/cells/efuse@a18,f
/apple_efuses_nvmem0/cells/efuse@a20,14
/apple_efuses_nvmem0/cells/efuse@a10,19
/apple_efuses_nvmem0/cells/efuse@a18,1b
/apple_efuses_nvmem0/cells/efuse@a14,11
/apple_efuses_nvmem0/cells/efuse@a1c,a
/apple_efuses_nvmem0/cells/efuse@a10,1e
/apple_efuses_nvmem0/cells/efuse@a20,19

      Arnd