On Tue, Sep 29, 2020 at 3:44 PM Andrew Lunn [off-list ref] wrote:

On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:

quoted

On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:

quoted

quoted

+DSDT entry for MDIO node
+------------------------
+a) Silicon Component
+--------------------
+ Scope(_SB)
+ {
+   Device(MDI0) {
+     Name(_HID, "NXP0006")
+     Name(_CCA, 1)
+     Name(_UID, 0)
+     Name(_CRS, ResourceTemplate() {
+       Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)
+       Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
+        {
+          MDI0_IT
+        }
+     }) // end of _CRS for MDI0
+     Name (_DSD, Package () {
+       ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+       Package () {
+          Package () {"little-endian", 1},
+       }

Adopting the 'little-endian' property here makes little sense. This looks
like legacy from old PowerPC DT platforms that doesn't belong here. I would
drop this bit.

I'm unable to drop this as the xgmac_mdio driver relies on this variable to
change the io access to little-endian. Default is big-endian.
Please see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/freescale/xgmac_mdio.c?h=v5.9-rc7#n55

Hi Calvin

Are we talking about the bus controller endiannes, or the CPU
endianness?

If we are talking about the CPU endiannes, are you plan on supporting
any big endian platforms using ACPI? If not, just hard code it.
Newbie ACPI question: Does ACPI even support big endian CPUs, given
its x86 origins?

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.

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.

       Arnd