All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Heiko Stuebner <heiko@sntech.de>
Cc: palmer@dabbelt.com, paul.walmsley@sifive.com,
	aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org, wefu@redhat.com,
	liush@allwinnertech.com, guoren@kernel.org,
	atishp@atishpatra.org, anup@brainfault.org, drew@beagleboard.org,
	hch@lst.de, arnd@arndb.de, wens@csie.org, maxime@cerno.tech,
	gfavor@ventanamicro.com, andrea.mondelli@huawei.com,
	behrensj@mit.edu, xinhaoqu@huawei.com, mick@ics.forth.gr,
	allen.baum@esperantotech.com, jscheid@ventanamicro.com,
	rtrauben@gmail.com, samuel@sholland.org, cmuellner@linux.com,
	philipp.tomsich@vrull.eu
Subject: Re: [PATCH 11/12] riscv: don't use global static vars to store alternative data
Date: Mon, 16 May 2022 08:15:41 +0200	[thread overview]
Message-ID: <20220516061541.GA12877@lst.de> (raw)
In-Reply-To: <20220511192921.2223629-12-heiko@sntech.de>

On Wed, May 11, 2022 at 09:29:20PM +0200, Heiko Stuebner wrote:
> Right now the code uses a global struct to store vendor-ids
> and another global variable to store the vendor-patch-function.
> 
> There exist specific cases where we'll need to patch the kernel
> at an even earlier stage, where trying to write to a static
> variable might actually result in hangs.
> 
> Also collecting the vendor-information consists of 3 sbi-ecalls
> (or csr-reads) which is pretty negligible in the context of
> booting a kernel.
> 
> So rework the code to not rely on static variables and instead
> collect the vendor-information when a round of alternatives is
> to be applied.
> 
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> Reviewed-by: Guo Ren <guoren@kernel.org>
> Reviewed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
> ---
>  arch/riscv/kernel/alternative.c | 51 ++++++++++++++++-----------------
>  1 file changed, 24 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/riscv/kernel/alternative.c b/arch/riscv/kernel/alternative.c
> index e6c9de9f9ba6..27f722ae452b 100644
> --- a/arch/riscv/kernel/alternative.c
> +++ b/arch/riscv/kernel/alternative.c
> @@ -16,41 +16,35 @@
>  #include <asm/sbi.h>
>  #include <asm/csr.h>
>  
> -static struct cpu_manufacturer_info_t {
> +struct cpu_manufacturer_info_t {
>  	unsigned long vendor_id;
>  	unsigned long arch_id;
>  	unsigned long imp_id;
> -} cpu_mfr_info;
> +	void (*vendor_patch_func)(struct alt_entry *begin, struct alt_entry *end,
> +				  unsigned long archid, unsigned long impid,
> +				  unsigned int stage);

Please drop the confusing vendor_ prefix for the function pointer
while you're at it.  The vendor id is just one of three inputs for
the patching.

Otherwise this looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

_______________________________________________
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: Heiko Stuebner <heiko@sntech.de>
Cc: palmer@dabbelt.com, paul.walmsley@sifive.com,
	aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org, wefu@redhat.com,
	liush@allwinnertech.com, guoren@kernel.org,
	atishp@atishpatra.org, anup@brainfault.org, drew@beagleboard.org,
	hch@lst.de, arnd@arndb.de, wens@csie.org, maxime@cerno.tech,
	gfavor@ventanamicro.com, andrea.mondelli@huawei.com,
	behrensj@mit.edu, xinhaoqu@huawei.com, mick@ics.forth.gr,
	allen.baum@esperantotech.com, jscheid@ventanamicro.com,
	rtrauben@gmail.com, samuel@sholland.org, cmuellner@linux.com,
	philipp.tomsich@vrull.eu
Subject: Re: [PATCH 11/12] riscv: don't use global static vars to store alternative data
Date: Mon, 16 May 2022 08:15:41 +0200	[thread overview]
Message-ID: <20220516061541.GA12877@lst.de> (raw)
In-Reply-To: <20220511192921.2223629-12-heiko@sntech.de>

On Wed, May 11, 2022 at 09:29:20PM +0200, Heiko Stuebner wrote:
> Right now the code uses a global struct to store vendor-ids
> and another global variable to store the vendor-patch-function.
> 
> There exist specific cases where we'll need to patch the kernel
> at an even earlier stage, where trying to write to a static
> variable might actually result in hangs.
> 
> Also collecting the vendor-information consists of 3 sbi-ecalls
> (or csr-reads) which is pretty negligible in the context of
> booting a kernel.
> 
> So rework the code to not rely on static variables and instead
> collect the vendor-information when a round of alternatives is
> to be applied.
> 
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> Reviewed-by: Guo Ren <guoren@kernel.org>
> Reviewed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
> ---
>  arch/riscv/kernel/alternative.c | 51 ++++++++++++++++-----------------
>  1 file changed, 24 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/riscv/kernel/alternative.c b/arch/riscv/kernel/alternative.c
> index e6c9de9f9ba6..27f722ae452b 100644
> --- a/arch/riscv/kernel/alternative.c
> +++ b/arch/riscv/kernel/alternative.c
> @@ -16,41 +16,35 @@
>  #include <asm/sbi.h>
>  #include <asm/csr.h>
>  
> -static struct cpu_manufacturer_info_t {
> +struct cpu_manufacturer_info_t {
>  	unsigned long vendor_id;
>  	unsigned long arch_id;
>  	unsigned long imp_id;
> -} cpu_mfr_info;
> +	void (*vendor_patch_func)(struct alt_entry *begin, struct alt_entry *end,
> +				  unsigned long archid, unsigned long impid,
> +				  unsigned int stage);

Please drop the confusing vendor_ prefix for the function pointer
while you're at it.  The vendor id is just one of three inputs for
the patching.

Otherwise this looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

  reply	other threads:[~2022-05-16  6:15 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-11 19:29 [PATCH v10 00/12] riscv: support for Svpbmt and D1 memory types Heiko Stuebner
2022-05-11 19:29 ` Heiko Stuebner
2022-05-11 19:29 ` [PATCH 01/12] riscv: integrate alternatives better into the main architecture Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-16  6:01   ` Christoph Hellwig
2022-05-16  6:01     ` Christoph Hellwig
2022-05-16  6:45   ` Guo Ren
2022-05-16  6:45     ` Guo Ren
2022-05-11 19:29 ` [PATCH 02/12] riscv: allow different stages with alternatives Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-16  6:01   ` Christoph Hellwig
2022-05-16  6:01     ` Christoph Hellwig
2022-05-16  6:51   ` Guo Ren
2022-05-16  6:51     ` Guo Ren
2022-05-11 19:29 ` [PATCH 03/12] riscv: implement module alternatives Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-16  6:02   ` Christoph Hellwig
2022-05-16  6:02     ` Christoph Hellwig
2022-05-16  6:54   ` Guo Ren
2022-05-16  6:54     ` Guo Ren
2022-05-11 19:29 ` [PATCH 04/12] riscv: implement ALTERNATIVE_2 macro Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-16  6:03   ` Christoph Hellwig
2022-05-16  6:03     ` Christoph Hellwig
2022-05-16  6:54   ` Guo Ren
2022-05-16  6:54     ` Guo Ren
2022-05-11 19:29 ` [PATCH 05/12] riscv: extend concatenated alternatives-lines to the same length Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-16  6:03   ` Christoph Hellwig
2022-05-16  6:03     ` Christoph Hellwig
2022-05-16  6:55   ` Guo Ren
2022-05-16  6:55     ` Guo Ren
2022-05-11 19:29 ` [PATCH 06/12] riscv: prevent compressed instructions in alternatives Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-16  6:04   ` Christoph Hellwig
2022-05-16  6:04     ` Christoph Hellwig
2022-05-16  6:55   ` Guo Ren
2022-05-16  6:55     ` Guo Ren
2022-05-11 19:29 ` [PATCH 07/12] riscv: move boot alternatives to after fill_hwcap Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-11 19:29 ` [PATCH 08/12] riscv: Fix accessing pfn bits in PTEs for non-32bit variants Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-16  6:04   ` Christoph Hellwig
2022-05-16  6:04     ` Christoph Hellwig
2022-05-16  6:55   ` Guo Ren
2022-05-16  6:55     ` Guo Ren
2022-05-23 14:03   ` Alexandre Ghiti
2022-05-23 14:03     ` Alexandre Ghiti
2022-05-25 15:22     ` Heiko Stübner
2022-05-25 15:22       ` Heiko Stübner
2022-05-28  8:15       ` Alexandre Ghiti
2022-05-28  8:15         ` Alexandre Ghiti
2022-05-11 19:29 ` [PATCH 09/12] riscv: add RISC-V Svpbmt extension support Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-16  6:10   ` Christoph Hellwig
2022-05-16  6:10     ` Christoph Hellwig
2022-05-16  9:09     ` Philipp Tomsich
2022-05-16  9:09       ` Philipp Tomsich
2022-05-16 10:30       ` Heiko Stübner
2022-05-16 10:30         ` Heiko Stübner
2022-05-11 19:29 ` [PATCH 10/12] riscv: remove FIXMAP_PAGE_IO and fall back to its default value Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-11 19:29 ` [PATCH 11/12] riscv: don't use global static vars to store alternative data Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-16  6:15   ` Christoph Hellwig [this message]
2022-05-16  6:15     ` Christoph Hellwig
2022-05-11 19:29 ` [PATCH 12/12] riscv: add memory-type errata for T-Head Heiko Stuebner
2022-05-11 19:29   ` Heiko Stuebner
2022-05-13 13:37   ` Guo Ren
2022-05-13 13:37     ` Guo Ren
2022-05-13  3:32 ` [PATCH v10 00/12] riscv: support for Svpbmt and D1 memory types Palmer Dabbelt
2022-05-13  3:32   ` Palmer Dabbelt
2022-05-13 21:41   ` Heiko Stuebner
2022-05-13 21:41     ` Heiko Stuebner

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=20220516061541.GA12877@lst.de \
    --to=hch@lst.de \
    --cc=allen.baum@esperantotech.com \
    --cc=andrea.mondelli@huawei.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=atishp@atishpatra.org \
    --cc=behrensj@mit.edu \
    --cc=cmuellner@linux.com \
    --cc=drew@beagleboard.org \
    --cc=gfavor@ventanamicro.com \
    --cc=guoren@kernel.org \
    --cc=heiko@sntech.de \
    --cc=jscheid@ventanamicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=liush@allwinnertech.com \
    --cc=maxime@cerno.tech \
    --cc=mick@ics.forth.gr \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=rtrauben@gmail.com \
    --cc=samuel@sholland.org \
    --cc=wefu@redhat.com \
    --cc=wens@csie.org \
    --cc=xinhaoqu@huawei.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.