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

["Sven Peter" <sven@svenpeter.dev>]

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