On 29/09/2020 15:59, Andrew Lunn wrote:
IIRC both UEFI and ACPI define only little-endian data structures.
The code does not attempt to convert these into CPU endianness
at the moment. In theory it could be changed to support either, but
this seems non-practical for the UEFI runtime services that require
calling into firmware code in little-endian mode.
Hi Arnd
Thanks for the info. So we can assume the CPU is little endian. That
helps narrow down the problem.
If this is the bus controller endianness, are all the SoCs you plan to
support via ACPI the same endianness? If they are all the same, you
can hard code it.
NXP has a bunch of SoCs that reuse the same on-chip devices but
change the endianness between them based on what the chip
designers guessed the OS would want, which is why the drivers
usually support both register layouts and switch at runtime.
Worse, depending on which SoC was the first to get a DT binding
for a particular NXP on-chip device, the default endianness is
different, and there is either a "big-endian" or "little-endian"
override in the binding.
I would guess that for modern NXP chips that you might boot with
ACPI the endianness is always wired the same way, but I
understand the caution when they have been burned by this
problem before.
So it might depend on if NXP is worried it might flip the endianness
of the synthesis of the MDIO controller at some point for devices it
wants to support using ACPI?
Does ACPI have a standard way of declaring the endianness of a device?
We don't really want to put the DT parameter in ACPI, we want to use
the ACPI way of doing it.
No, and it doesn't need one. If a device is wired up big-endian, then it
is between the device driver and the device. The OS, and the ACPI
framework doesn't come into play other than providing a generic way of
encoding data useful to the device driver. Encoding endian hasn't been a
common problem, and the tools are already there to deal with it when it is.
g.
