Messages in this thread | | | From | <> | Subject | Re: [PATCH v3 1/2] arm64: topology: move store_cpu_topology() to shared code | Date | Mon, 11 Jul 2022 16:39:01 +0000 |
| |
On 11/07/2022 16:24, Sudeep Holla wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Mon, Jul 11, 2022 at 04:50:38PM +0200, Greg Kroah-Hartman wrote: >> On Mon, Jul 11, 2022 at 03:35:42PM +0100, Sudeep Holla wrote: >>> On Sat, Jul 09, 2022 at 04:23:54PM +0100, Conor Dooley wrote: >>>> From: Conor Dooley <conor.dooley@microchip.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. >>>> >>> >>> Looks good. FWIW, >>> >>> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> >>> >>>> CC: stable@vger.kernel.org >>> >>> However, while I understand the reason why this is needed in stable trees >>> for RISC-V, I am not sure if we want this for stable tree at-least on arm64. >>> I leave that part to Greg and Will. >> >> Why would it be good for one arch but bad for another? > > Not really bad as such. Just needs testing and must not change much ideally, > but it really depends on which stable trees we will target and what is the > original state there. As mentioned in the commit, this changed a bit around > v5.8/9 on arm64 and not sure what kernels RISC-V needs this. There could > be some surprises on some Andriod platforms but that is something we can > look at when if and when there are complaints. > > I am in general not sure what is the -stable tree rules is such situation and > hence made the noise so that we are aware that we may need more work than just > backporting this patch. Also this is just my opinion. If we decide to backport > esp. to kernels older than the one containing 3102bc0e6ac7, then arm64 may need > more changes or probably we can pull that commit if that makes it easier. Based > on what is decided and what are the targeted -stable trees, we can dig deeper.
There's always the option of, for the older kernels, not migrating arm64 at all and just wrap store_cpu_topo with "if RISCV" rather than "if RISCV || ARM64".
| |