linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: guoren@kernel.org, Anup Patel <Anup.Patel@wdc.com>,
	anup@brainfault.org, drew@beagleboard.org,
	Christoph Hellwig <hch@lst.de>,
	wefu@redhat.com, lazyparser@gmail.com,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-sunxi@lists.linux.dev,
	guoren@linux.alibaba.com,
	Paul Walmsley <paul.walmsley@sifive.com>
Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support
Date: Fri, 04 Jun 2021 15:10:25 -0700 (PDT)	[thread overview]
Message-ID: <mhng-82cca177-11c3-44d0-a0c3-37df6a40bb6b@palmerdabbelt-glaptop> (raw)
In-Reply-To: <CAK8P3a04C8HObpSHNYqQpe4V96MoSLs7sEpiPvp4OpvyAU1_fQ@mail.gmail.com>

On Fri, 04 Jun 2021 14:26:11 PDT (-0700), Arnd Bergmann wrote:
> On Fri, Jun 4, 2021 at 6:14 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> >> To give some common examples that make it break down:
>> >>
>> >> - 32-bit vs 64-bit already violates that rule on risc-v (as it does on
>> >>   most other architectures)
>>
>> Yes, and there's no way around that on RISC-V.  They're different base
>> ISAs therefor re-define the same instructions, so we're essentially at
>> two kernel binaries by that point.  The platform spec says rv64gc, so we
>> can kind of punt on this one for now.  If rv32 hardware shows up
>> we'll probably want a standard system there too, which is why we've
>> avoided coupling kernel portability to XLEN.
>
> I would actually put 32-bit into the same category as NOMMU, XIP
> and the built-in DTB:
> Since it seems unrealistic to expect an rv32 Debian or Fedora build,
> there is very little to gain by enforcing compatibility between machines.
> This is different from 32-bit Arm, which is widely used across multiple
> distros and many SoCs.

OK, well, that's what the spec says already.  Maybe the right answer is 
to just add that "be compatible with the platform spec" Kconfig and have 
it also enforce rv64gc like the spec says.

>
>> >> - architectures that support both big-endian and little-endian kernels
>> >>   tend to have platforms that require one or the other (e.g. mips,
>> >>   though not arm). Not an issue for you.
>>
>> It is now!  We've added big-endian to RISC-V.  There's no hardware yet
>> and very little software support.  IMO the right answer is to ban that
>> from the platform spec, but again it'll depnd on what vendors want to
>> build (though anyone is listening, please don't make my life miserable
>> ;)).
>
> I don't see any big-endian support in linux-next. This one does seem
> worth enforcing to be kept out, as it would double the number of user
> space ABIs, not just kernel configurations. On arm64, I think the general
> feeling is now that we would have been better off not merging big-endian
> support into the kernel as an option, but it still seemed important at the
> time. Not that there is anything really wrong with big-endian by itself,
> just that there is no use case that is worth the added complexity of
> supporting both.
>
> Let me know if there are patches you want me to Nak in the future ;-)

Sorry, by "added big-endian to RISC-V" I meant to the ISA, not to Linux.  
We haven't had any interesting in adding it to Linux.  The interest has 
all been in the embedded space.

  reply	other threads:[~2021-06-04 22:11 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-19  5:04 [PATCH RFC 0/3] riscv: Add DMA_COHERENT support guoren
2021-05-19  5:04 ` [PATCH RFC 1/3] riscv: pgtable.h: Fixup _PAGE_CHG_MASK usage guoren
2021-05-19  5:04 ` [PATCH RFC 2/3] riscv: Add DMA_COHERENT for custom PTE attributes guoren
2021-05-19  5:04 ` [PATCH RFC 3/3] riscv: Add SYNC_DMA_FOR_CPU/DEVICE for DMA_COHERENT guoren
2021-05-19  6:32   ` Guo Ren
2021-05-19  5:20 ` [PATCH RFC 0/3] riscv: Add DMA_COHERENT support Christoph Hellwig
2021-05-19  5:48   ` Guo Ren
2021-05-19  5:55     ` Christoph Hellwig
2021-05-19  6:09       ` Guo Ren
2021-05-19  6:44     ` Drew Fustini
2021-05-19  6:53       ` Christoph Hellwig
2021-05-20  1:45         ` Guo Ren
2021-05-20  5:48           ` Christoph Hellwig
2021-06-06 18:14           ` Nick Kossifidis
2021-06-07  0:04             ` Guo Ren
2021-06-07  2:16               ` Nick Kossifidis
2021-06-07  3:19                 ` Guo Ren
2021-06-07  6:27                   ` Christoph Hellwig
2021-06-07  6:41                     ` Guo Ren
2021-06-07  6:51                       ` Christoph Hellwig
2021-06-07  7:46                         ` Guo Ren
2021-06-08 15:00                     ` David Laight
2021-06-08 15:32                       ` 'Christoph Hellwig'
2021-06-08 16:11                         ` David Laight
2021-06-07  8:35                   ` Nick Kossifidis
2021-06-09  3:28             ` Guo Ren
2021-06-09  6:05               ` Jisheng Zhang
2021-06-09  9:45               ` Nick Kossifidis
2021-06-09 12:43                 ` Guo Ren
2021-05-19  6:05   ` Guo Ren
2021-05-19  6:06     ` Christoph Hellwig
2021-05-19  6:11       ` Guo Ren
2021-05-19  6:54       ` Drew Fustini
2021-05-19  6:56         ` Christoph Hellwig
2021-05-19  7:14         ` Anup Patel
2021-05-19  8:25           ` Damien Le Moal
2021-05-20  1:47           ` Guo Ren
2021-05-20  1:59             ` Guo Ren
2021-05-22  0:36           ` Guo Ren
2021-05-30  0:30             ` Palmer Dabbelt
2021-06-03  4:13               ` Palmer Dabbelt
2021-06-03  6:00                 ` Anup Patel
2021-06-03 15:39                   ` Palmer Dabbelt
2021-06-04  9:02                     ` David Laight
2021-06-04  9:53                     ` Arnd Bergmann
2021-06-04 14:47                       ` Guo Ren
2021-06-04 16:12                         ` Palmer Dabbelt
2021-06-04 21:26                           ` Arnd Bergmann
2021-06-04 22:10                             ` Palmer Dabbelt [this message]
2021-06-08 12:26                           ` Guo Ren
2021-06-06 17:11                   ` Guo Ren
2021-06-07  3:38                     ` Anup Patel
2021-06-07  4:22                       ` Guo Ren
2021-06-07  4:47                         ` Anup Patel
2021-06-07  5:08                           ` Guo Ren
2021-06-07  5:13                           ` Guo Ren

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=mhng-82cca177-11c3-44d0-a0c3-37df6a40bb6b@palmerdabbelt-glaptop \
    --to=palmer@dabbelt.com \
    --cc=Anup.Patel@wdc.com \
    --cc=anup@brainfault.org \
    --cc=arnd@arndb.de \
    --cc=drew@beagleboard.org \
    --cc=guoren@kernel.org \
    --cc=guoren@linux.alibaba.com \
    --cc=hch@lst.de \
    --cc=lazyparser@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=paul.walmsley@sifive.com \
    --cc=wefu@redhat.com \
    /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).