From: David Laight <David.Laight@ACULAB.COM>
To: 'Jessica Clarke' <jrtc27@jrtc27.com>, Atish Patra <atishp@rivosinc.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Anup Patel <anup@brainfault.org>,
Albert Ou <aou@eecs.berkeley.edu>,
Atish Patra <atishp@atishpatra.org>,
Damien Le Moal <damien.lemoal@wdc.com>,
devicetree <devicetree@vger.kernel.org>,
Jisheng Zhang <jszhang@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
Rob Herring <robh+dt@kernel.org>
Subject: RE: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap
Date: Tue, 25 Jan 2022 22:29:26 +0000 [thread overview]
Message-ID: <63b1a64fc25d44dabab777bf1f247863@AcuMS.aculab.com> (raw)
In-Reply-To: <1AA3005C-E9C8-4E4B-900D-DD48B37CEA41@jrtc27.com>
> On 20 Jan 2022, at 09:09, Atish Patra <atishp@rivosinc.com> wrote:
> >
> > Currently, SBI APIs accept a hartmask that is generated from struct
> > cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it
> > is not the correct data structure for hartids as it can be higher
> > than NR_CPUs for platforms with sparse or discontguous hartids.
> >
> > Remove all association between hartid mask and struct cpumask.
....
> > -static int __sbi_rfence_v01(int fid, const unsigned long *hart_mask,
> > +static int __sbi_rfence_v01(int fid, const struct cpumask *cpu_mask,
> > unsigned long start, unsigned long size,
> > unsigned long arg4, unsigned long arg5)
> > {
> > int result = 0;
> > + unsigned long hart_mask;
> > +
> > + if (!cpu_mask)
> > + cpu_mask = cpu_online_mask;
> > + hart_mask = __sbi_v01_cpumask_to_hartmask(cpu_mask);
> >
> > /* v0.2 function IDs are equivalent to v0.1 extension IDs */
> > switch (fid) {
> > case SBI_EXT_RFENCE_REMOTE_FENCE_I:
> > sbi_ecall(SBI_EXT_0_1_REMOTE_FENCE_I, 0,
> > - (unsigned long)hart_mask, 0, 0, 0, 0, 0);
> > + (unsigned long)&hart_mask, 0, 0, 0, 0, 0);
You don't need the cast.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-01-25 22:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 9:09 [PATCH v3 0/6] Sparse HART id support Atish Patra
2022-01-20 9:09 ` [PATCH v3 1/6] RISC-V: Avoid using per cpu array for ordered booting Atish Patra
2022-01-20 9:09 ` [PATCH v3 2/6] RISC-V: Do not print the SBI version during HSM extension boot print Atish Patra
2022-01-20 9:09 ` [PATCH v3 3/6] RISC-V: Use __cpu_up_stack/task_pointer only for spinwait method Atish Patra
2022-01-20 9:09 ` [PATCH v3 5/6] RISC-V: Move spinwait booting method to its own config Atish Patra
2022-01-20 9:09 ` [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap Atish Patra
2022-01-25 20:12 ` Geert Uytterhoeven
2022-01-25 20:17 ` Atish Patra
2022-01-25 20:52 ` Geert Uytterhoeven
2022-01-25 21:11 ` Ron Economos
2022-01-25 22:26 ` Jessica Clarke
2022-01-25 22:29 ` David Laight [this message]
2022-01-26 2:21 ` Atish Patra
2022-01-26 8:28 ` Geert Uytterhoeven
2022-01-26 9:10 ` Geert Uytterhoeven
2022-01-27 1:01 ` Atish Patra
2022-01-27 8:48 ` Geert Uytterhoeven
2022-01-27 8:48 ` Geert Uytterhoeven
2022-01-27 10:03 ` Geert Uytterhoeven
2022-01-27 10:17 ` Andreas Schwab
[not found] ` <CAOnJCU+U0xmw-_yTEUo9ZXO5pvoJ6VCGu+jjU-Sa2MnhcAha6Q@mail.gmail.com>
2022-01-28 8:39 ` Geert Uytterhoeven
2022-01-28 8:55 ` Geert Uytterhoeven
2022-01-31 12:09 ` Anup Patel
2022-01-31 13:27 ` Geert Uytterhoeven
2022-01-27 9:56 ` Ron Economos
2022-01-31 8:35 ` Anup Patel
2022-01-20 18:17 ` [PATCH v3 0/6] Sparse HART id support Palmer Dabbelt
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=63b1a64fc25d44dabab777bf1f247863@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atishp@atishpatra.org \
--cc=atishp@rivosinc.com \
--cc=damien.lemoal@wdc.com \
--cc=devicetree@vger.kernel.org \
--cc=jrtc27@jrtc27.com \
--cc=jszhang@kernel.org \
--cc=krzysztof.kozlowski@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@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).