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

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

On 15/09/2026 20:45, Jan Beulich wrote:
> 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


Thank you. I will make the changes and post them in v13. I'll wait a 
little while before posting to avoid spamming patch versions.