linux-kernel - Re: [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 18 Dec 2023 17:28:53 +0100
From: Lorenzo Pieralisi <lpieralisi@...nel.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	linux-pm@...r.kernel.org, loongarch@...ts.linux.dev,
	linux-acpi@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-riscv@...ts.infradead.org, kvmarm@...ts.linux.dev,
	x86@...nel.org, acpica-devel@...ts.linuxfoundation.org,
	linux-csky@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-ia64@...r.kernel.org, linux-parisc@...r.kernel.org,
	Salil Mehta <salil.mehta@...wei.com>,
	Jean-Philippe Brucker <jean-philippe@...aro.org>,
	jianyong.wu@....com, justin.he@....com,
	James Morse <james.morse@....com>
Subject: Re: [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields

On Mon, Dec 18, 2023 at 02:14:30PM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 18, 2023 at 10:23 AM Lorenzo Pieralisi
> <lpieralisi@...nel.org> wrote:
> >
> > On Fri, Dec 15, 2023 at 04:53:28PM +0000, Russell King (Oracle) wrote:
> > > On Fri, Dec 15, 2023 at 04:23:22PM +0000, Jonathan Cameron wrote:
> > > > On Wed, 13 Dec 2023 12:50:18 +0000
> > > > Russell King (Oracle) <rmk+kernel@...linux.org.uk> wrote:
> > > >
> > > > > From: James Morse <james.morse@....com>
> > > > >
> > > > > Add the new flag field to the MADT's GICC structure.
> > > > >
> > > > > 'Online Capable' indicates a disabled CPU can be enabled later. See
> > > > > ACPI specification 6.5 Tabel 5.37: GICC CPU Interface Flags.
> > > > >
> > > > > Signed-off-by: James Morse <james.morse@....com>
> > > > > Tested-by: Miguel Luis <miguel.luis@...cle.com>
> > > > > Tested-by: Vishnu Pajjuri <vishnu@...amperecomputing.com>
> > > > > Tested-by: Jianyong Wu <jianyong.wu@....com>
> > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> > > >
> > > > I see there is an acpica pull request including this bit but with a different name
> > > > For reference.
> > > > https://github.com/acpica/acpica/pull/914/commits/453a5f67567786522021d5f6913f561f8b3cabf6
> > > >
> > > > +CC Lorenzo who submitted that.
> > >
> > > > > +#define ACPI_MADT_GICC_CPU_CAPABLE      (1<<3)   /* 03: CPU is online capable */
> > > >
> > > > ACPI_MADT_GICC_ONLINE_CAPABLE
> > >
> > > It's somewhat disappointing, but no big deal. It's easy enough to change
> > > "irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs"
> > > to use Lorenzo's name when that patch hits - and it becomes one less
> > > patch in this patch set when Lorenzo's change eventually hits mainline.
> > >
> > > Does anyone know how long it may take for Lorenzo's change to get into
> > > mainline? Would it be by the 6.8 merge window or the following one?
> >
> > I wish I knew. I submitted ACPICA changes for the online capable bit
> > since I had to add additional flags on top (ie DMA coherent) and it
> > would not make sense to submit the latter without the former.
> >
> > I'd be great if the ACPICA headers can make it into Linux for the upcoming
> > merge window, not sure what I can do to fasttrack the process though
> > (I shall ping the maintainers).
> 
> If your upstream pull request has been merged, I can pick up Linux
> patches carrying Link: tags pointing to the upstream ACPICA commits in
> that pull request.

Thank you, I don't think it has been merged yet (and it requires
review because I am not that familiar with the ACPICA code base).

Hopefully it should be an extended kernel cycle so it might be
possible to get these headers in v6.8, if you deem that reasonable
of course once the PR is merged.

Thanks,
Lorenzo