Re: [PATCH v1] ACPI: processor: Provide empty stub of acpi_proc_quirk_mwait_check()

[Ard Biesheuvel]

On Wed, 22 Nov 2023 at 20:39, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> On Thu, Sep 21, 2023 at 4:00 PM Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> >
> > On Thursday, September 21, 2023 3:09:04 PM CEST Ard Biesheuvel wrote:
> > > On Thu, 21 Sept 2023 at 13:04, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> > > >
> > > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > > >
> > > > Commit 0a0e2ea642f6 ("ACPI: processor: Move MWAIT quirk out of
> > > > acpi_processor.c") added acpi_proc_quirk_mwait_check() that is
> > > > only defined for x86 and is unlikely to be defined for any other
> > > > architectures, so put it under #ifdef CONFIG_X86 and provide
> > > > an empty stub implementation of it for the other cases.
> > > >
> > > > Link: https://lore.kernel.org/lkml/c7a05a44-c0be-46c2-a21d-b242524d482b@xxxxxxxxxxxx
> > > > Link: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=remove-ia64&id=a0334bf78b95532cec54f56b53e8ae1bfe7e1ca1
> > > > Fixes: 0a0e2ea642f6 ("ACPI: processor: Move MWAIT quirk out of acpi_processor.c")
> > > > Reported-by: Guenter Roeck <linux@xxxxxxxxxxxx>
> > > > Reported-by: Frank Scheiner <frank.scheiner@xxxxxx>
> > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > > > ---
> > > >
> > > > This is kind of orthogonal to
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=remove-ia64&id=a0334bf78b95532cec54f56b53e8ae1bfe7e1ca1
> > > >
> > > > because if any architectures other than x86 and ia64 decide to use the
> > > > processor _OSC, they will see the reported build error.
> > > >
> > >
> > > You mean when other arches #define CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC too, right?
> > >
> > > In any case, this is going to conflict with my change, which is
> > > already in linux-next (you were cc'ed on the PR to asm-generic). What
> > > do you propose here?
> >
> > IIUC, the conflict is that the empty stub will be defined twice if this is
> > applied before removing ia64.
> >
> > But if it is applied on top of the ia64 removal, all should be fine, so that's
> > what I would do (and tell the -stable people to ignore it).
>
> And ia64 is gone now, so applied.

Excellent.