From: Christoph Hellwig <hch@lst.de>
To: guoren@kernel.org
Cc: anup.patel@wdc.com, atish.patra@wdc.com,
palmerdabbelt@google.com, christoph.muellner@vrull.eu,
philipp.tomsich@vrull.eu, hch@lst.de, liush@allwinnertech.com,
wefu@redhat.com, lazyparser@gmail.com, drew@beagleboard.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
taiten.peng@canonical.com, aniket.ponkshe@canonical.com,
heinrich.schuchardt@canonical.com, gordan.markus@canonical.com,
Guo Ren <guoren@linux.alibaba.com>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Palmer Dabbelt <palmer@dabbelt.com>
Subject: Re: [RFC PATCH V4 1/6] riscv: pgtable: Add custom protection_map init
Date: Wed, 15 Sep 2021 09:45:57 +0200 [thread overview]
Message-ID: <20210915074557.GA20024@lst.de> (raw)
In-Reply-To: <20210911092139.79607-2-guoren@kernel.org>
On Sat, Sep 11, 2021 at 05:21:34PM +0800, guoren@kernel.org wrote:
> From: Guo Ren <guoren@linux.alibaba.com>
>
> Some RISC-V CPU vendors have defined their own PTE attributes to
> solve non-coherent DMA bus problems. That makes _P/SXXX definitions
> contain global variables which could be initialized at the early
> boot stage before setup_vm. The patch prevents compile errors.
That sounds way to nice for someone who deliberatly ignores the
specification and should definitively not go into the kernel
commit log like this.
> This patch is similar to 316d097c4cd4 (x86/pti: Filter at
> vma->vm_page_prot population) which give a choice for arch custom
> implementation.
How? To me it looks like a bad duplication of such functionality in
a way that totally breaks abstractions. architectures really do not
have any business changing protection_map.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: guoren@kernel.org
Cc: anup.patel@wdc.com, atish.patra@wdc.com,
palmerdabbelt@google.com, christoph.muellner@vrull.eu,
philipp.tomsich@vrull.eu, hch@lst.de, liush@allwinnertech.com,
wefu@redhat.com, lazyparser@gmail.com, drew@beagleboard.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
taiten.peng@canonical.com, aniket.ponkshe@canonical.com,
heinrich.schuchardt@canonical.com, gordan.markus@canonical.com,
Guo Ren <guoren@linux.alibaba.com>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Palmer Dabbelt <palmer@dabbelt.com>
Subject: Re: [RFC PATCH V4 1/6] riscv: pgtable: Add custom protection_map init
Date: Wed, 15 Sep 2021 09:45:57 +0200 [thread overview]
Message-ID: <20210915074557.GA20024@lst.de> (raw)
In-Reply-To: <20210911092139.79607-2-guoren@kernel.org>
On Sat, Sep 11, 2021 at 05:21:34PM +0800, guoren@kernel.org wrote:
> From: Guo Ren <guoren@linux.alibaba.com>
>
> Some RISC-V CPU vendors have defined their own PTE attributes to
> solve non-coherent DMA bus problems. That makes _P/SXXX definitions
> contain global variables which could be initialized at the early
> boot stage before setup_vm. The patch prevents compile errors.
That sounds way to nice for someone who deliberatly ignores the
specification and should definitively not go into the kernel
commit log like this.
> This patch is similar to 316d097c4cd4 (x86/pti: Filter at
> vma->vm_page_prot population) which give a choice for arch custom
> implementation.
How? To me it looks like a bad duplication of such functionality in
a way that totally breaks abstractions. architectures really do not
have any business changing protection_map.
next prev parent reply other threads:[~2021-09-15 7:47 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-11 9:21 [RFC PATCH V4 0/6] riscv: Add PBMT & DMA for D1 bringup guoren
2021-09-11 9:21 ` guoren
2021-09-11 9:21 ` [RFC PATCH V4 1/6] riscv: pgtable: Add custom protection_map init guoren
2021-09-11 9:21 ` guoren
2021-09-15 7:45 ` Christoph Hellwig [this message]
2021-09-15 7:45 ` Christoph Hellwig
2021-09-15 23:52 ` Guo Ren
2021-09-15 23:52 ` Guo Ren
2021-09-11 9:21 ` [RFC PATCH V4 2/6] riscv: errata: pgtable: Add custom Svpbmt supported for Allwinner D1 guoren
2021-09-11 9:21 ` guoren
2021-09-15 7:47 ` Christoph Hellwig
2021-09-15 7:47 ` Christoph Hellwig
2021-09-16 0:48 ` Guo Ren
2021-09-16 0:48 ` Guo Ren
2021-09-16 7:31 ` Atish Patra
2021-09-16 7:31 ` Atish Patra
2021-09-11 9:21 ` [RFC PATCH V4 3/6] RISC-V: Support a new config option for non-coherent DMA guoren
2021-09-11 9:21 ` guoren
2021-09-15 7:48 ` Christoph Hellwig
2021-09-15 7:48 ` Christoph Hellwig
2021-09-16 1:20 ` Guo Ren
2021-09-16 1:20 ` Guo Ren
2021-09-16 4:39 ` Atish Patra
2021-09-16 4:39 ` Atish Patra
2021-09-16 6:09 ` Guo Ren
2021-09-16 6:09 ` Guo Ren
2021-09-11 9:21 ` [RFC PATCH V4 4/6] RISC-V: Implement arch_sync_dma* functions guoren
2021-09-11 9:21 ` guoren
2021-09-15 7:50 ` Christoph Hellwig
2021-09-15 7:50 ` Christoph Hellwig
2021-09-16 1:32 ` Guo Ren
2021-09-16 1:32 ` Guo Ren
2021-09-16 4:24 ` Anup Patel
2021-09-16 4:24 ` Anup Patel
2021-09-16 4:42 ` Atish Patra
2021-09-16 4:42 ` Atish Patra
2021-09-11 9:21 ` [RFC PATCH V4 5/6] riscv: errata: Support T-HEAD custom dcache ops guoren
2021-09-11 9:21 ` guoren
2021-09-11 9:21 ` [RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option guoren
2021-09-11 9:21 ` guoren
2021-09-13 8:45 ` Maxime Ripard
2021-09-13 8:45 ` Maxime Ripard
2021-09-13 9:20 ` Guo Ren
2021-09-13 9:20 ` Guo Ren
2021-09-13 18:48 ` Randy Dunlap
2021-09-13 18:48 ` Randy Dunlap
2021-09-14 2:34 ` Guo Ren
2021-09-14 2:34 ` Guo Ren
2021-09-14 3:06 ` Randy Dunlap
2021-09-14 3:06 ` Randy Dunlap
2021-09-14 5:16 ` Anup Patel
2021-09-14 5:16 ` Anup Patel
2021-09-14 5:20 ` Randy Dunlap
2021-09-14 5:20 ` Randy Dunlap
2021-09-14 9:29 ` Arnd Bergmann
2021-09-14 9:29 ` Arnd Bergmann
2021-09-14 10:07 ` Krzysztof Kozlowski
2021-09-14 10:07 ` Krzysztof Kozlowski
2021-09-14 10:13 ` Maxime Ripard
2021-09-14 10:13 ` Maxime Ripard
2021-09-14 12:09 ` Krzysztof Kozlowski
2021-09-14 12:09 ` Krzysztof Kozlowski
2021-09-14 13:02 ` Arnd Bergmann
2021-09-14 13:02 ` Arnd Bergmann
2021-09-16 6:37 ` Guo Ren
2021-09-16 6:37 ` Guo Ren
2021-09-14 3:49 ` Heinrich Schuchardt
2021-09-14 3:49 ` Heinrich Schuchardt
2021-09-14 5:16 ` Samuel Holland
2021-09-14 5:16 ` Samuel Holland
2021-09-14 6:30 ` Heinrich Schuchardt
2021-09-14 6:30 ` Heinrich Schuchardt
2021-09-14 7:20 ` Maxime Ripard
2021-09-14 7:20 ` Maxime Ripard
2021-09-14 9:26 ` Ben Dooks
2021-09-14 9:26 ` Ben Dooks
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=20210915074557.GA20024@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=aniket.ponkshe@canonical.com \
--cc=anup.patel@wdc.com \
--cc=arnd@arndb.de \
--cc=atish.patra@wdc.com \
--cc=christoph.muellner@vrull.eu \
--cc=drew@beagleboard.org \
--cc=gordan.markus@canonical.com \
--cc=guoren@kernel.org \
--cc=guoren@linux.alibaba.com \
--cc=heinrich.schuchardt@canonical.com \
--cc=lazyparser@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=liush@allwinnertech.com \
--cc=palmer@dabbelt.com \
--cc=palmerdabbelt@google.com \
--cc=philipp.tomsich@vrull.eu \
--cc=taiten.peng@canonical.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.