linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: arm@kernel.org, soc@kernel.org, Jon Hunter <jonathanh@nvidia.com>,
	linux-tegra@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [GIT PULL v2 2/7] firmware: tegra: Changes for v6.2-rc1
Date: Wed, 23 Nov 2022 12:33:29 +0100	[thread overview]
Message-ID: <Y34FCQ3xTmcjqKRT@orome> (raw)
In-Reply-To: <374ae4ef-2f57-4737-95af-b1bdfdb03740@app.fastmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1944 bytes --]

On Tue, Nov 22, 2022 at 10:25:50PM +0100, Arnd Bergmann wrote:
> On Mon, Nov 21, 2022, at 18:12, Thierry Reding wrote:
> >       firmware: tegra: bpmp: Do not support big-endian
> 
> I pulled the branch, but I think this patch is inconsistent with
> our normal approach: Since all ARMv7 and ARMv8 processors can
> run with both big-endian and little-endian kernels, we normally
> try to keep drivers portable between both ways, even though we
> don't expect anyone to actually want a big-endian kernel any
> more. Changing portable code to nonportable code doesn't seem
> helpful here.

The only reason I dropped this is because the driver is in itself
inconsistent. Parts of it use byte-swapping for 32-bit values and other
parts don't. I was originally going to fix big-endian support but it
would've required changes to the BPMP ABI header to avoid sparse
warnings in lots of places, then these ABI changes would've needed to
trickle up to the canonical source, etc. All of that didn't seem worth
the effort if we couldn't even test this in any way. So the easiest fix
was to stop pretending and drop the partial support.

> On the other hand, there are already examples of important
> drivers that are fundamentally incompatible with big-endian
> mode, notably drivers/efi/, which is required on a lot of
> machines.
> 
> You don't have to revert this patch, but it would be helpful
> to mark code that is explicitly unportable with a 'depends
> on !CPU_BIG_ENDIAN' line in Kconfig. If you agree, I can
> add that.

Yes, feel free to add that.

> Do you know of other tegra drivers that only work on
> little-endian?

I'm not aware of any that explicitly wouldn't work with big endian, but
it's not something we've ever tested. I know that people have in the
past done experiments with running emulated Tegra on QEMU in big endian
mode, but it's probably not something that's very common.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-11-23 11:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 17:12 [GIT PULL v2 1/7] soc/tegra: Changes for v6.2-rc1 Thierry Reding
2022-11-21 17:12 ` [GIT PULL v2 2/7] firmware: tegra: " Thierry Reding
2022-11-22 21:25   ` Arnd Bergmann
2022-11-23 11:33     ` Thierry Reding [this message]
2022-11-23 13:23       ` Arnd Bergmann
2022-11-25 10:12         ` Thierry Reding
2022-11-21 17:12 ` [GIT PULL v2 3/7] clk: " Thierry Reding
2022-11-21 17:12 ` [GIT PULL v2 4/7] dt-bindings: " Thierry Reding
2022-11-29 17:16   ` Rob Herring
2022-11-21 17:12 ` [GIT PULL v2 5/7] memory: tegra: " Thierry Reding
2022-11-21 17:12 ` [GIT PULL v2 6/7] ARM: tegra: Device tree changes " Thierry Reding
2022-11-21 17:12 ` [GIT PULL v2 7/7] arm64: " Thierry Reding
2022-11-22 22:09   ` Arnd Bergmann
2022-11-23 11:36     ` Thierry Reding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y34FCQ3xTmcjqKRT@orome \
    --to=thierry.reding@gmail.com \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=jonathanh@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=soc@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).