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: <CAK8P3a0etJf_SG8qLY0VjR+JamKQ8MtyPwoXnb0mpnGZawLfRA@mail.gmail.com>
Date:   Tue, 29 Sep 2020 16:44:42 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Andrew Lunn <andrew@...n.ch>
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

On Tue, Sep 29, 2020 at 3:44 PM Andrew Lunn <andrew@...n.ch> wrote:
> On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:
> > On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:
> > > > +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