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 <[email protected]> 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
