From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED4C8C47420 for ; Tue, 29 Sep 2020 14:59:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A871820759 for ; Tue, 29 Sep 2020 14:59:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729381AbgI2O7X (ORCPT ); Tue, 29 Sep 2020 10:59:23 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:33792 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725710AbgI2O7W (ORCPT ); Tue, 29 Sep 2020 10:59:22 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kNH5y-00GlhJ-GW; Tue, 29 Sep 2020 16:59:10 +0200 Date: Tue, 29 Sep 2020 16:59:10 +0200 From: Andrew Lunn To: Arnd Bergmann Cc: Calvin Johnson , Grant Likely , "Rafael J . Wysocki" , Jeremy Linton , Russell King - ARM Linux admin , Jon , Cristi Sovaiala , Ioana Ciornei , Andy Shevchenko , Florian Fainelli , Madalin Bucur , Networking , linux.cj@gmail.com, ACPI Devel Maling List , nd Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY Message-ID: <20200929145910.GJ3950513@lunn.ch> References: <20200715090400.4733-1-calvin.johnson@oss.nxp.com> <20200715090400.4733-2-calvin.johnson@oss.nxp.com> <20200929051703.GA10849@lsv03152.swis.in-blr01.nxp.com> <20200929134302.GF3950513@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > 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