Re: [PATCH v2] arch_topology: Introduce nr_possible_packages

[Sudeep Holla <sudeep.holla@kernel.org>]

On Wed, Jul 22, 2026 at 02:50:48PM +0800, Feng Tang wrote:
> On Tue, Jul 21, 2026 at 03:32:03PM +0100, Sudeep Holla wrote:
> > On Tue, Jul 14, 2026 at 01:43:17PM +0800, Feng Tang wrote:
> > > For multi-sockets platforms kernel or driver code may need the number
> > > of packages to chose different code directions. Some architecture
> > > already provides such kind of interface like x86, which is being used
> > > in its architecture code and drivers.
> > > 
> > > Add similar interface 'nr_possible_packages' for platforms which can
> > > get package topology information by parsing ACPI tables in boot phase,
> > > which was verified to show the correct number of packages on some
> > > 1-socket and 2-sockets production arm64 servers from different vendors.
> > > 
> > > It has been used locally by some arm64 PMU driver, and cross-socket
> > > timer-consistency check code, which are to be posted.
> > > 
> > > Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com>
> > > ---
> > >   since v1:
> > >       * fix the potential overflow issue for 32b package ID (Sudeep)
> > > 	  * add real use case in commit log (Sudeep)
> > > 
> > >   since RFC:
> > >       * use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL (Greg)
> > 
> > This is undone in this version, why ?
> > 
> > > 	  * change the possible max package ID to 2047 (Greg)
> > > 	  * remove the CONFIG_ARM64/RISCV limit for 'nr_possible_packages' (Greg)
> > 
> > Again this is still there, misleading or v2 is back to RFC, /me confused.
> 
> Thanks for the review!
> 
> My fault! that I messed up with the locally saved RFC and V1 patch. I was
> focusing on fixing the problems you mentioned.
> 
> > > 
> > >   v1:  https://lore.kernel.org/lkml/20260515144435.93035-1-feng.tang@linux.alibaba.com/ 
> > 
> > Comments about users is still ignored.
> 
> I described the user case in commit log of this version. It was
> locally used by several drivers and other code, maybe I should
> repost it together with those code.
> 

Yes please.

> btw, is there any problem with the new package accounting code?  
> 

Depends on the users really, because it can be simplified based on the usage.

Regards,
Sudeep