From: Stafford Horne <shorne@gmail.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH 06/12] openrisc: Use of_get_cpu_hwid()
Date: Thu, 7 Oct 2021 06:25:09 +0900 [thread overview]
Message-ID: <YV4UNQg3QROuTfQ/@antec> (raw)
In-Reply-To: <CAL_JsqLv+Ym=hxxz2vm0H3pbx1FRkBpHs3V=8DKjG43n+gS+RA@mail.gmail.com>
On Wed, Oct 06, 2021 at 04:08:38PM -0500, Rob Herring wrote:
> On Wed, Oct 6, 2021 at 3:44 PM Stafford Horne <shorne@gmail.com> wrote:
> >
> > On Wed, Oct 06, 2021 at 11:43:26AM -0500, Rob Herring wrote:
> > > Replace open coded parsing of CPU nodes' 'reg' property with
> > > of_get_cpu_hwid().
> > >
> > > Cc: Jonas Bonn <jonas@southpole.se>
> > > Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
> > > Cc: Stafford Horne <shorne@gmail.com>
> > > Cc: openrisc at lists.librecores.org
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > ---
> > > arch/openrisc/kernel/smp.c | 6 +-----
> > > 1 file changed, 1 insertion(+), 5 deletions(-)
> > >
> > > diff --git a/arch/openrisc/kernel/smp.c b/arch/openrisc/kernel/smp.c
> > > index 415e209732a3..7d5a4f303a5a 100644
> > > --- a/arch/openrisc/kernel/smp.c
> > > +++ b/arch/openrisc/kernel/smp.c
> > > @@ -65,11 +65,7 @@ void __init smp_init_cpus(void)
> > > u32 cpu_id;
> > >
> > > for_each_of_cpu_node(cpu) {
> > > - if (of_property_read_u32(cpu, "reg", &cpu_id)) {
> > > - pr_warn("%s missing reg property", cpu->full_name);
> > > - continue;
> > > - }
> > > -
> > > + cpu_id = of_get_cpu_hwid(cpu);
>
> Oops, that should be: of_get_cpu_hwid(cpu, 0);
OK. I checked all other patches in the series, it seems OpenRISC was the only
one missing that. Sorry I missed it initially.
> I thought I double checked all those...
>
> > You have defined of_get_cpu_hwid to return u64, will this create compiler
> > warnings when since we are storing a u64 into a u32?
>
> I'm counting on the caller to know the max size for their platform.
OK.
> >
> > It seems only if we make with W=3.
> >
> > I thought we usually warned on this. Oh well, for the openrisc bits.
>
> That's only on ptr truncation I think.
Right, that makes sense.
-Stafford
next prev parent reply other threads:[~2021-10-06 21:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 16:43 [OpenRISC] [PATCH 00/12] DT: CPU h/w id parsing clean-ups and cacheinfo id support Rob Herring
2021-10-06 16:43 ` [OpenRISC] [PATCH 01/12] of: Add of_get_cpu_hwid() to read hardware ID from CPU nodes Rob Herring
2021-10-18 13:26 ` Sudeep Holla
2021-10-06 16:43 ` [OpenRISC] [PATCH 02/12] ARM: Use of_get_cpu_hwid() Rob Herring
2021-10-06 16:43 ` [OpenRISC] [PATCH 03/12] ARM: broadcom: " Rob Herring
2021-10-07 2:24 ` Florian Fainelli
2021-10-06 16:43 ` [OpenRISC] [PATCH 04/12] arm64: " Rob Herring
2021-10-07 8:07 ` Will Deacon
2021-10-18 13:27 ` Sudeep Holla
2021-10-06 16:43 ` [OpenRISC] [PATCH 05/12] csky: " Rob Herring
2021-10-06 16:43 ` [OpenRISC] [PATCH 06/12] openrisc: " Rob Herring
2021-10-06 20:44 ` Stafford Horne
2021-10-06 21:08 ` Rob Herring
2021-10-06 21:25 ` Stafford Horne [this message]
2021-10-06 21:27 ` Segher Boessenkool
2021-10-06 22:37 ` Stafford Horne
2021-10-07 7:53 ` David Laight
2021-10-06 16:43 ` [OpenRISC] [PATCH 07/12] powerpc: " Rob Herring
2021-10-08 11:01 ` Michael Ellerman
2021-10-06 16:43 ` [OpenRISC] [PATCH 08/12] riscv: " Rob Herring
2021-10-06 16:43 ` [OpenRISC] [PATCH 09/12] sh: " Rob Herring
2021-10-27 14:26 ` Rich Felker
2021-10-06 16:43 ` [OpenRISC] [PATCH 10/12] x86: dt: " Rob Herring
2021-10-06 16:43 ` [OpenRISC] [PATCH 11/12] cacheinfo: Allow for >32-bit cache 'id' Rob Herring
2021-10-18 13:30 ` Sudeep Holla
2021-10-06 16:43 ` [OpenRISC] [PATCH 12/12] cacheinfo: Set cache 'id' based on DT data Rob Herring
2021-10-18 13:31 ` Sudeep Holla
2021-10-07 2:24 ` [OpenRISC] [PATCH 00/12] DT: CPU h/w id parsing clean-ups and cacheinfo id support Florian Fainelli
2021-10-20 18:47 ` Rob Herring
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=YV4UNQg3QROuTfQ/@antec \
--to=shorne@gmail.com \
--cc=openrisc@lists.librecores.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