Re: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.09.2026 17:45, Oleksii Moisieiev wrote:
> - io.h
> 
> I'd replace the current comment with something along these lines (kept
> arch-neutral, so other implementations remain possible):
> 
> /*
>   * Copy a sequence of bytes between regular memory and a memory-like
>   * I/O region, e.g. shared memory placed in RAM or SRAM mapped with
>   * device attributes.
>   * The I/O region must behave like byte-addressable storage: it must
>   * accept 8-bit accesses at any byte address and naturally aligned
>   * 32-bit accesses, with plain byte-storage semantics in both cases
>   * (no side effects, no dependency on the access width). An
>   * implementation may use any of these widths, but never wider ones.
>   * The helpers are not suitable for device registers with access-width
>   * requirements.
>   *
>   * Neither pointer needs to be aligned. The access widths issued on the
>   * I/O side depend only on the alignment of the I/O pointer and on
>   * count, never on the alignment of the regular memory pointer.
>   *
>   * Implementations are architecture-specific; see the respective
>   * arch/*/lib/memcpy-{from,to}io.c for the exact access pattern.
>   */
> 
> The Arm-specific note in memcpy-{from,to}io.c would then state the
> concrete pattern: 8-bit accesses until the I/O pointer is 32-bit
> aligned and for the trailing count % 4 bytes, 32-bit accesses for the
> aligned bulk. I'd also drop the "tolerate" wording in favour of the
> above.
> 
> - implementation
> 
> As proposed: only the I/O pointer is aligned up; the RAM side uses
> get_unaligned_le32()/put_unaligned_le32() for the 32-bit part. The
> _le32 variants are used deliberately: paired with readl()/writel(),
> which are defined as little-endian accessors, this preserves the byte
> sequence regardless of CPU endianness. That is the only endianness
> aspect worth a mention, and I'll rewrite the commit message
> accordingly (dropping the sentence you pointed out).
> 
> Would that address your concerns?

I think so.

Jan