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]

Message-ID: <28906ffc-8774-6479-b292-e8ab2c6f5434@arm.com>
Date:   Tue, 29 Sep 2020 16:59:41 +0100
From:   Grant Likely <grant.likely@....com>
To:     Andrew Lunn <andrew@...n.ch>, Arnd Bergmann <arnd@...db.de>
Cc:     Calvin Johnson <calvin.johnson@....nxp.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



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.