From: Conor Dooley <conor@kernel.org>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: Samuel Holland <samuel@sholland.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Anup Patel <apatel@ventanamicro.com>,
Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH] riscv: Fix NR_CPUS range conditions
Date: Mon, 28 Nov 2022 19:19:39 +0000 [thread overview]
Message-ID: <Y4UJy0xL4Cj9tH2W@spud> (raw)
In-Reply-To: <20221128183559.5ei5fx4cl4mo3ioj@kamzik>
On Mon, Nov 28, 2022 at 07:35:59PM +0100, Andrew Jones wrote:
> On Sat, Nov 26, 2022 at 03:32:04PM +0000, Conor Dooley wrote:
> > On Sat, Nov 26, 2022 at 12:15:56AM -0600, Samuel Holland wrote:
> > > The conditions reference the symbol SBI_V01, which does not exist. The
> > > correct symbol is RISCV_SBI_V01.
> >
> > Huh, good spot.
> > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>
> Yeah, huh. It never occurred to me that we don't have some sort of symbol
> referencing checking in kconfig. Or maybe we do and I just don't know how
kismet, but that does the opposite. Randy Dunlap is the only person I
see fiddling with that stuff usually, so perhaps he knows? +CC them
either way.
> to enable it? Anyway, this issue made me wonder how many more dangling
> references we may have. I wrote a script to look for them and found 29,
> including this one. I'm not exactly sure how to report them since they
> touch so many different places. For now, I've opened this kernel BZ
>
> https://bugzilla.kernel.org/show_bug.cgi?id=216748
>
> >
> > >
> > > Fixes: e623715f3d67 ("RISC-V: Increase range and default value of NR_CPUS")
> > > Signed-off-by: Samuel Holland <samuel@sholland.org>
> > > ---
> > >
> > > arch/riscv/Kconfig | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index fec54872ab45..acbfe34c6a00 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -319,9 +319,9 @@ config SMP
> > > config NR_CPUS
> > > int "Maximum number of CPUs (2-512)"
> > > depends on SMP
> > > - range 2 512 if !SBI_V01
> > > - range 2 32 if SBI_V01 && 32BIT
> > > - range 2 64 if SBI_V01 && 64BIT
> > > + range 2 512 if !RISCV_SBI_V01
> > > + range 2 32 if RISCV_SBI_V01 && 32BIT
> > > + range 2 64 if RISCV_SBI_V01 && 64BIT
>
> And for this patch,
>
> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
>
> Thanks,
> drew
_______________________________________________
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: Conor Dooley <conor@kernel.org>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: Samuel Holland <samuel@sholland.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Anup Patel <apatel@ventanamicro.com>,
Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH] riscv: Fix NR_CPUS range conditions
Date: Mon, 28 Nov 2022 19:19:39 +0000 [thread overview]
Message-ID: <Y4UJy0xL4Cj9tH2W@spud> (raw)
In-Reply-To: <20221128183559.5ei5fx4cl4mo3ioj@kamzik>
On Mon, Nov 28, 2022 at 07:35:59PM +0100, Andrew Jones wrote:
> On Sat, Nov 26, 2022 at 03:32:04PM +0000, Conor Dooley wrote:
> > On Sat, Nov 26, 2022 at 12:15:56AM -0600, Samuel Holland wrote:
> > > The conditions reference the symbol SBI_V01, which does not exist. The
> > > correct symbol is RISCV_SBI_V01.
> >
> > Huh, good spot.
> > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>
> Yeah, huh. It never occurred to me that we don't have some sort of symbol
> referencing checking in kconfig. Or maybe we do and I just don't know how
kismet, but that does the opposite. Randy Dunlap is the only person I
see fiddling with that stuff usually, so perhaps he knows? +CC them
either way.
> to enable it? Anyway, this issue made me wonder how many more dangling
> references we may have. I wrote a script to look for them and found 29,
> including this one. I'm not exactly sure how to report them since they
> touch so many different places. For now, I've opened this kernel BZ
>
> https://bugzilla.kernel.org/show_bug.cgi?id=216748
>
> >
> > >
> > > Fixes: e623715f3d67 ("RISC-V: Increase range and default value of NR_CPUS")
> > > Signed-off-by: Samuel Holland <samuel@sholland.org>
> > > ---
> > >
> > > arch/riscv/Kconfig | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index fec54872ab45..acbfe34c6a00 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -319,9 +319,9 @@ config SMP
> > > config NR_CPUS
> > > int "Maximum number of CPUs (2-512)"
> > > depends on SMP
> > > - range 2 512 if !SBI_V01
> > > - range 2 32 if SBI_V01 && 32BIT
> > > - range 2 64 if SBI_V01 && 64BIT
> > > + range 2 512 if !RISCV_SBI_V01
> > > + range 2 32 if RISCV_SBI_V01 && 32BIT
> > > + range 2 64 if RISCV_SBI_V01 && 64BIT
>
> And for this patch,
>
> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
>
> Thanks,
> drew
next prev parent reply other threads:[~2022-11-28 19:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-26 6:15 [PATCH] riscv: Fix NR_CPUS range conditions Samuel Holland
2022-11-26 6:15 ` Samuel Holland
2022-11-26 15:32 ` Conor Dooley
2022-11-26 15:32 ` Conor Dooley
2022-11-28 18:35 ` Andrew Jones
2022-11-28 18:35 ` Andrew Jones
2022-11-28 19:19 ` Conor Dooley [this message]
2022-11-28 19:19 ` Conor Dooley
2022-11-28 23:38 ` Palmer Dabbelt
2022-11-28 23:38 ` Palmer Dabbelt
2022-11-28 23:36 ` Palmer Dabbelt
2022-11-28 23:36 ` Palmer Dabbelt
2022-11-28 23:40 ` patchwork-bot+linux-riscv
2022-11-28 23:40 ` patchwork-bot+linux-riscv
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=Y4UJy0xL4Cj9tH2W@spud \
--to=conor@kernel.org \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=heinrich.schuchardt@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rdunlap@infradead.org \
--cc=samuel@sholland.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 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.