[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ytac7G1zlq6WW4jt@arm.com>
Date: Tue, 19 Jul 2022 13:00:44 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Conor.Dooley@...rochip.com
Cc: paul.walmsley@...ive.com, palmer@...belt.com, palmer@...osinc.com,
aou@...s.berkeley.edu, sudeep.holla@....com, will@...nel.org,
gregkh@...uxfoundation.org, rafael@...nel.org,
Daire.McNamara@...rochip.com, niklas.cassel@....com,
damien.lemoal@...nsource.wdc.com, geert@...ux-m68k.org,
zong.li@...ive.com, kernel@...il.dk, hahnjo@...njo.de,
guoren@...nel.org, anup@...infault.org, atishp@...shpatra.org,
heiko@...ech.de, philipp.tomsich@...ll.eu, robh@...nel.org,
maz@...nel.org, viresh.kumar@...aro.org,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, Brice.Goglin@...ia.fr
Subject: Re: [PATCH v4 1/2] arm64: topology: move store_cpu_topology() to
shared code
On Tue, Jul 19, 2022 at 11:51:04AM +0000, Conor.Dooley@...rochip.com wrote:
> On 19/07/2022 12:41, Catalin Marinas wrote:
> > On Fri, Jul 15, 2022 at 06:51:55PM +0100, Conor Dooley wrote:
> >> From: Conor Dooley <conor.dooley@...rochip.com>
> >>
> >> arm64's method of defining a default cpu topology requires only minimal
> >> changes to apply to RISC-V also. The current arm64 implementation exits
> >> early in a uniprocessor configuration by reading MPIDR & claiming that
> >> uniprocessor can rely on the default values.
> >>
> >> This is appears to be a hangover from prior to '3102bc0e6ac7 ("arm64:
> >> topology: Stop using MPIDR for topology information")', because the
> >> current code just assigns default values for multiprocessor systems.
> >>
> >> With the MPIDR references removed, store_cpu_topolgy() can be moved to
> >> the common arch_topology code.
> >>
> >> CC: stable@...r.kernel.org
> >
> > I'd quantify how far back you want this to go. IIUC based on the Fixes
> > tag in the other patch, it should stop at 5.4. If you send a pull
> > request instead and have a fixed commit id, you could add it as a
> > prerequisite on the following patch without a cc stable here.
>
> I guess a PR might be the easiest way for it anyway, so that both
> yourself and Palmer could merge it?
I guess so, a stable branch would do. Note that Will is handling the
upcoming merging window.
--
Catalin
Powered by blists - more mailing lists