Re: [PATCH RFC v3 21/21] cpumask: Add enabled cpumask for present CPUs that can be brought online
Jonathan Cameron <[email protected]> Tue, 2 Jan 2024 15:19:53 +0000
| Newsgroups | org.kernel.vger.linux-ia64,dev.linux.lists.acpica-devel,dev.linux.lists.kvmarm,dev.linux.lists.loongarch,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.linux-acpi,org.kernel.vger.linux-arch,org.kernel.vger.linux-csky,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-parisc,org.kernel.vger.linux-pm |
|---|---|
| Organization | Huawei Technologies Research and Development (UK) Ltd. |
| Message-ID | <[email protected]> |
On Mon, 18 Dec 2023 12:14:14 +0000 "Russell King (Oracle)" <[email protected]> wrote: > On Fri, Dec 15, 2023 at 05:18:31PM +0000, Jonathan Cameron wrote: > > On Wed, 13 Dec 2023 12:50:59 +0000 > > Russell King (Oracle) <[email protected]> wrote: > > > > > From: James Morse <[email protected]> > > > > > > The 'offline' file in sysfs shows all offline CPUs, including those > > > that aren't present. User-space is expected to remove not-present CPUs > > > from this list to learn which CPUs could be brought online. > > > > > > CPUs can be present but not-enabled. These CPUs can't be brought online > > > until the firmware policy changes, which comes with an ACPI notification > > > that will register the CPUs. > > > > > > With only the offline and present files, user-space is unable to > > > determine which CPUs it can try to bring online. Add a new CPU mask > > > that shows this based on all the registered CPUs. > > > > > > Signed-off-by: James Morse <[email protected]> > > > Tested-by: Miguel Luis <[email protected]> > > > Tested-by: Vishnu Pajjuri <[email protected]> > > > Tested-by: Jianyong Wu <[email protected]> > > > --- > > > > Needs docs > > Documentation/ABI/testing/sysfs-devices-system-cpu > > seems to have the rest of the similar entries. > > Any ideas what I put in there as "Date" ? It seems to me that we have > little idea when this might be merged.. I could use the date of the > commit (Nov 2022). > That's always a guess at best. Hopefully whoever picks this up fixes the date up or asks for a new version with it fixed just before they do. J