linux-kernel - Re: [PATCH 0/7] Support exposing bits of any byte as NVMEM cells

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]

Message-ID: <20250514203246.GA2958656-robh@kernel.org>
Date: Wed, 14 May 2025 15:32:46 -0500
From: Rob Herring <robh@...nel.org>
To: Sven Peter <sven@...npeter.dev>
Cc: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Janne Grunau <j@...nau.net>,
	Alyssa Rosenzweig <alyssa@...enzweig.io>,
	Neal Gompa <neal@...pa.dev>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, linux-kernel@...r.kernel.org,
	asahi@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	devicetree@...r.kernel.org, R <rqou@...keley.edu>
Subject: Re: [PATCH 0/7] Support exposing bits of any byte as NVMEM cells

On Sat, May 10, 2025 at 07:44:40AM +0000, Sven Peter wrote:
> Hi,
> 
> I'm preparing USB3 support for Apple Silicon Macs for upstreaming right
> now and this series is the first dependency. The Type-C PHY requires
> configuration values encoded in fuses for which we already have a
> driver.
> Unfortunately, the fuses on these machines are only accessibly as 32bit
> words but the Type-C PHY configuration values are individual bits which
> are sometimes spread across multiple fuses.
> Right now this is not supported by the nvmem core which only allows a
> subset of bits within the first byte to be exposed as a nvmem cell. This
> small series adds support for exposing arbitrary bits as nvmem cells.
> 
> The second part of the series then adds the nvmem cells required for the
> Type-C PHY to our device trees. While it's technically independent I've
> included those changes in this series for context.

The idea in the DT is normal addressing is byte-wise, so the only thing 
needed to specify bit level addressing is a 1-7 bit offset.

If you have access size restrictions, then that should be handled by 
your driver. The nvmem layout shouldn't change because of that. You 
could perhaps define the access size with 'reg-io-width' property, but 
really compatible should imply it.

Rob