On Thu, Aug 20 2020 at 14:53, Adam Borowski wrote:
> Not that x86 without ACPI sees any real use...
>
> Signed-off-by: Adam Borowski <[email protected]>
> ---
> Found by randconfig builds.
>
> arch/x86/pci/intel_mid_pci.c | 2 ++
> arch/x86/pci/xen.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
> index 00c62115f39c..f14a911f0d06 100644
> --- a/arch/x86/pci/intel_mid_pci.c
> +++ b/arch/x86/pci/intel_mid_pci.c
> @@ -299,8 +299,10 @@ int __init intel_mid_pci_init(void)
> pcibios_disable_irq = intel_mid_pci_irq_disable;
> pci_root_ops = intel_mid_pci_ops;
> pci_soc_mode = 1;
> +#ifdef CONFIG_ACPI
> /* Continue with standard init */
> acpi_noirq_set();
> +#endif
If CONFIG_ACPI=n then acpi_noirq_set() is an empty stub inline. So I'm
not sure what you are trying to solve here.
Ah, I see with CONFIG_ACPI=n linux/acpi.h does not include asm/acpi.h so
the stubs are unreachable. So that needs to be fixed and not papered
over with #ifdeffery
Thanks,
tglx
On Fri, Aug 21, 2020 at 10:13:25PM +0200, Thomas Gleixner wrote:
> On Thu, Aug 20 2020 at 14:53, Adam Borowski wrote:
> > Found by randconfig builds.
> >
> > arch/x86/pci/intel_mid_pci.c | 2 ++
> > arch/x86/pci/xen.c | 2 ++
> > --- a/arch/x86/pci/intel_mid_pci.c
> > +++ b/arch/x86/pci/intel_mid_pci.c
> > @@ -299,8 +299,10 @@ int __init intel_mid_pci_init(void)
> > +#ifdef CONFIG_ACPI
> > /* Continue with standard init */
> > acpi_noirq_set();
> > +#endif
> If CONFIG_ACPI=n then acpi_noirq_set() is an empty stub inline. So I'm
> not sure what you are trying to solve here.
>
> Ah, I see with CONFIG_ACPI=n linux/acpi.h does not include asm/acpi.h so
> the stubs are unreachable. So that needs to be fixed and not papered
> over with #ifdeffery
If I understand Randy Dunlap correctly, he already sent a pair of patches
that do what you want.
Meow.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
⠈⠳⣄⠀⠀⠀⠀
On 8/21/20 1:32 PM, Adam Borowski wrote:
> On Fri, Aug 21, 2020 at 10:13:25PM +0200, Thomas Gleixner wrote:
>> On Thu, Aug 20 2020 at 14:53, Adam Borowski wrote:
>>> Found by randconfig builds.
>>>
>>> arch/x86/pci/intel_mid_pci.c | 2 ++
>>> arch/x86/pci/xen.c | 2 ++
>
>>> --- a/arch/x86/pci/intel_mid_pci.c
>>> +++ b/arch/x86/pci/intel_mid_pci.c
>>> @@ -299,8 +299,10 @@ int __init intel_mid_pci_init(void)
>>> +#ifdef CONFIG_ACPI
>>> /* Continue with standard init */
>>> acpi_noirq_set();
>>> +#endif
>
>> If CONFIG_ACPI=n then acpi_noirq_set() is an empty stub inline. So I'm
>> not sure what you are trying to solve here.
>>
>> Ah, I see with CONFIG_ACPI=n linux/acpi.h does not include asm/acpi.h so
>> the stubs are unreachable. So that needs to be fixed and not papered
>> over with #ifdeffery
>
> If I understand Randy Dunlap correctly, he already sent a pair of patches
> that do what you want.
I did, but I sent them to the Xen and PCI maintainers,
not the x86 maintainers, but I will happily resend this patch.
The Xen patch has already been applied whereas the patch
to intel_mid_pci.c is in limbo. :(
Thomas, do you want me to send it to you/X86 people?
(with 2 Reviewed-by: additions)
thanks.
--
~Randy
On Fri, Aug 21 2020 at 14:19, Randy Dunlap wrote:
> On 8/21/20 1:32 PM, Adam Borowski wrote:
>> If I understand Randy Dunlap correctly, he already sent a pair of patches
>> that do what you want.
I replied before reading Randy's reply. Old habit of reading stuff from
top and not getting biased by other peoples replies before doing so. Is
most of the time the correct approach, but sometimes it would be better
to do it the other way round :)
> I did, but I sent them to the Xen and PCI maintainers,
> not the x86 maintainers, but I will happily resend this patch.
> The Xen patch has already been applied whereas the patch
> to intel_mid_pci.c is in limbo. :(
>
> Thomas, do you want me to send it to you/X86 people?
> (with 2 Reviewed-by: additions)
Sure, but usually Bjorn handles the x86/pci/ stuff.
As I trust you, here is a blind
Acked-by: Thomas Gleixner <[email protected]>
just in case.
Thanks,
tglx