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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <b336221b-e1fa-42d8-a879-bda178f73735@app.fastmail.com>
Date: Wed, 14 May 2025 22:38:34 +0200
From: "Sven Peter" <sven@...npeter.dev>
To: "Rob Herring" <robh@...nel.org>
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

Hi,

On Wed, May 14, 2025, at 22:32, Rob Herring wrote:
> 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.

fair enough, I'll just handle the unaligned reads in the driver itself then
and adjust the offsets in the device tree.


Sven