[PATCH 0/4] nvmem: Support non-stride-aligned NVMEM cell data

[Samuel Holland]

The first half of this series fixes a bug in the sunxi SID driver,
emphasizing that it really does have a hardware-level stride of 4 bytes.

The remainder of the series tries to answer the question:

    How can I use nvmem_cell_read_u8() to read byte 0x2a of a NVMEM
    device that has .stride == 4?

The NVMEM cell may be at a different offset in future SoCs, so I think
it would be wrong to use nvmem_cell_read_u32() and extract the single
relevant byte in the consumer driver.

I can think of three solutions:
 1) Change the NVMEM provider driver to use .stride == 1, and fix the
    alignment inside that driver. Some other NVMEM implementations have
    taken this path. This is not ideal because it requires allocating
    an extra bounce buffer inside the driver.
 2) Extend nvmem_shift_read_buffer_in_place() to handle larger bit
    offsets. Specify a stride-aligned "reg" in the devicetree, and use
    "bits" to provide the sub-stride offset. This adds a minimal amount
    of new code, and is generic across all drivers.
 3) Do the same as #2, but also remove the alignment checks from
    nvmem_cell_info_to_nvmem_cell_entry_nodup() and have it convert
    non-stride-aligned "reg" properties to the equivalent bit_offset
    and nbits fields (and use that from nvmem_add_cells_from_of()).

Since option #3 has larger impacts on the NVMEM core, and is backward-
compatible with option #2, I have implemented option #2 in this series.


Samuel Holland (4):
  nvmem: sunxi_sid: Always use 32-bit MMIO reads
  nvmem: sunxi_sid: Drop the workaround on A64
  dt-bindings: nvmem: Allow bit offsets greater than a byte
  nvmem: core: Support reading cells with >= 8 bit offsets

 .../devicetree/bindings/nvmem/nvmem.yaml      |  2 +-
 drivers/nvmem/core.c                          | 43 +++++++++++--------
 drivers/nvmem/sunxi_sid.c                     | 23 ++++++----
 3 files changed, 40 insertions(+), 28 deletions(-)

-- 
2.35.1