Re: [PATCH v2 1/4] rust: io: Add big-endian read and write functions

Link Mauve
2026-02-05T21:21:10Z

On Thu, Feb 05, 2026 at 08:05:08PM +0100, Danilo Krummrich wrote:
> On Thu Feb 5, 2026 at 6:28 PM CET, Daniel Almeida wrote:
> >> On 5 Feb 2026, at 12:16, Gary Guo <gary@garyguo.net> wrote:
> >> I think we should have everything default to little endian, and have wrapper
> >> types that do big endian which require expicit construction, similar to
> >> RelaxedMmio in Alex's series.
> >
> > Ah yes, the RelaxedMmio pattern is definitely a good one. I agree that we
> > should head in this direction.
>
> I strongly disagree.
>
> This is a great pattern for relaxed ordering because:
>
> (1) We need both strict and relaxed ordering.
>
> (2) Relaxed ordering is rare, hence it doesn't hurt to write e.g.
>
> io.relaxed().write()
>
> (3) If you by accident just write
>
> io.write()
>
> i.e. forget to call relaxed() it s not a bug, nothing bad happens.
>
> Whereas for endianness it is a bad pattern because:
>
> (1) Devices are either little-endian or big-endian. Hence, having to write
>
> io.big_endian().write()
>
> is excessive, we always want big-endian for a big-endian device.
>
> (2) It is error prone, if you forget to call big_endian() first, it is a bug.
>
> (3) It is unergonomic in combination with relaxed ordering.
>
> io.big_endian().relaxed().write()
>
> (Does the other way around work as well? :)
>
> It makes much more sense to define once when we request the I/O memory whether
> the device is litte-endian or big-endian.
>
> This could be done with different request functions, a const generic or a
> function argument, but it should be done at request time.

Could this ever be done in the device tree? I understand this would
mean having to change all drivers and all device trees that do big
endian, but it seems to be the natural location for this information. I
have no idea how to structure that though.

--
Link Mauve