netdev - Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 29 Sep 2020 16:59:10 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Calvin Johnson <calvin.johnson@....nxp.com>,
        Grant Likely <grant.likely@....com>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Jeremy Linton <jeremy.linton@....com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Jon <jon@...id-run.com>,
        Cristi Sovaiala <cristian.sovaiala@....com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Madalin Bucur <madalin.bucur@....nxp.com>,
        Networking <netdev@...r.kernel.org>, linux.cj@...il.com,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        nd <nd@....com>
Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO
 PHY

> 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.

    Thanks
	Andrew