[PATCH] x86/pci: fix intel_mid_pci.c build error when ACPI is not enabled

[PATCH] x86/pci: fix intel_mid_pci.c build error when ACPI is not enabled

[Randy Dunlap]

From: Randy Dunlap <rdunlap@infradead.org>

Fix build error when CONFIG_ACPI is not set/enabled by adding
the header file <asm/acpi.h> which contains a stub for the function
in the build error.

../arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration]
  acpi_noirq_set();

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jesse Barnes <jsbarnes@google.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: linux-pci@vger.kernel.org
---
Found in linux-next, but applies to/exists in mainline also.

Alternative.1: X86_INTEL_MID depends on ACPI
Alternative.2: drop X86_INTEL_MID support

 arch/x86/pci/intel_mid_pci.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-next-20200813.orig/arch/x86/pci/intel_mid_pci.c
+++ linux-next-20200813/arch/x86/pci/intel_mid_pci.c
@@ -33,6 +33,7 @@
 #include <asm/hw_irq.h>
 #include <asm/io_apic.h>
 #include <asm/intel-mid.h>
+#include <asm/acpi.h>
 
 #define PCIE_CAP_OFFSET	0x100
 

Re: [PATCH] x86/pci: fix intel_mid_pci.c build error when ACPI is not enabled

[Bjorn Helgaas]

[+cc Andy]

On Thu, Aug 13, 2020 at 12:58:38PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
> 
> Fix build error when CONFIG_ACPI is not set/enabled by adding
> the header file <asm/acpi.h> which contains a stub for the function
> in the build error.
> 
> ../arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
> ../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration]
>   acpi_noirq_set();

Fixes: a912a7584ec3 ("x86/platform/intel-mid: Move PCI initialization to arch_init()")

Possibly
Cc: stable@vger.kernel.org	# v4.16+

> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
> Cc: Len Brown <lenb@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Jesse Barnes <jsbarnes@google.com>
> Cc: Arjan van de Ven <arjan@linux.intel.com>
> Cc: linux-pci@vger.kernel.org
> ---
> Found in linux-next, but applies to/exists in mainline also.
> 
> Alternative.1: X86_INTEL_MID depends on ACPI
> Alternative.2: drop X86_INTEL_MID support
> 
>  arch/x86/pci/intel_mid_pci.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> --- linux-next-20200813.orig/arch/x86/pci/intel_mid_pci.c
> +++ linux-next-20200813/arch/x86/pci/intel_mid_pci.c
> @@ -33,6 +33,7 @@
>  #include <asm/hw_irq.h>
>  #include <asm/io_apic.h>
>  #include <asm/intel-mid.h>
> +#include <asm/acpi.h>
>  
>  #define PCIE_CAP_OFFSET	0x100
>  
> 

Re: [PATCH] x86/pci: fix intel_mid_pci.c build error when ACPI is not enabled

[Arjan van de Ven]

On 8/13/2020 12:58 PM, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
> 
> Fix build error when CONFIG_ACPI is not set/enabled by adding
> the header file <asm/acpi.h> which contains a stub for the function
> in the build error.
> 
> ../arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
> ../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration]
>    acpi_noirq_set();
> 
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
> Cc: Len Brown <lenb@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Jesse Barnes <jsbarnes@google.com>
> Cc: Arjan van de Ven <arjan@linux.intel.com>
> Cc: linux-pci@vger.kernel.org
> ---
> Found in linux-next, but applies to/exists in mainline also.
> 
> Alternative.1: X86_INTEL_MID depends on ACPI
> Alternative.2: drop X86_INTEL_MID support

at this point I'd suggest Alternative 2; the products that needed that (past tense, that technology
is no longer need for any newer products) never shipped in any form where a 4.x or 5.x kernel could
work, and they are also all locked down...

Re: [PATCH] x86/pci: fix intel_mid_pci.c build error when ACPI is not enabled

[Jesse Barnes]

On Thu, Aug 13, 2020 at 12:58 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix build error when CONFIG_ACPI is not set/enabled by adding
> the header file <asm/acpi.h> which contains a stub for the function
> in the build error.
>
> ../arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
> ../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration]
>   acpi_noirq_set();
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
> Cc: Len Brown <lenb@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Jesse Barnes <jsbarnes@google.com>
> Cc: Arjan van de Ven <arjan@linux.intel.com>
> Cc: linux-pci@vger.kernel.org
> ---
> Found in linux-next, but applies to/exists in mainline also.
>
> Alternative.1: X86_INTEL_MID depends on ACPI
> Alternative.2: drop X86_INTEL_MID support
>
>  arch/x86/pci/intel_mid_pci.c |    1 +
>  1 file changed, 1 insertion(+)
>
> --- linux-next-20200813.orig/arch/x86/pci/intel_mid_pci.c
> +++ linux-next-20200813/arch/x86/pci/intel_mid_pci.c
> @@ -33,6 +33,7 @@
>  #include <asm/hw_irq.h>
>  #include <asm/io_apic.h>
>  #include <asm/intel-mid.h>
> +#include <asm/acpi.h>
>
>  #define PCIE_CAP_OFFSET        0x100

Reviewed-by: Jesse Barnes <jsbarnes@google.com>

Thanks Randy. Another option is to remove the MID support entirely.

Jesse

Re: [PATCH] x86/pci: fix intel_mid_pci.c build error when ACPI is not enabled

[Andy Shevchenko]

On Thu, Aug 13, 2020 at 11:31 PM Arjan van de Ven <arjan@linux.intel.com> wrote:
> On 8/13/2020 12:58 PM, Randy Dunlap wrote:
> > From: Randy Dunlap <rdunlap@infradead.org>
> >
> > Fix build error when CONFIG_ACPI is not set/enabled by adding
> > the header file <asm/acpi.h> which contains a stub for the function
> > in the build error.
> >
> > ../arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
> > ../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration]
> >    acpi_noirq_set();

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Thanks!

> > Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> > Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
> > Cc: Len Brown <lenb@kernel.org>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Jesse Barnes <jsbarnes@google.com>
> > Cc: Arjan van de Ven <arjan@linux.intel.com>
> > Cc: linux-pci@vger.kernel.org
> > ---
> > Found in linux-next, but applies to/exists in mainline also.
> >
> > Alternative.1: X86_INTEL_MID depends on ACPI
> > Alternative.2: drop X86_INTEL_MID support
>
> at this point I'd suggest Alternative 2; the products that needed that (past tense, that technology
> is no longer need for any newer products) never shipped in any form where a 4.x or 5.x kernel could
> work, and they are also all locked down...

This is not true. We have Intel Edison which runs nicely on vanilla
(not everything, some is still requiring a couple of patches, but most
of it works out-of-the-box).

And for the record, I have been working on removing quite a pile of
code (~13kLOCs to the date IIRC) in MID area. Just need some time to
fix Edison watchdog for that.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] x86/pci: fix intel_mid_pci.c build error when ACPI is not enabled

[Randy Dunlap]

On 8/13/20 1:55 PM, Andy Shevchenko wrote:
> On Thu, Aug 13, 2020 at 11:31 PM Arjan van de Ven <arjan@linux.intel.com> wrote:
>> On 8/13/2020 12:58 PM, Randy Dunlap wrote:
>>> From: Randy Dunlap <rdunlap@infradead.org>
>>>
>>> Fix build error when CONFIG_ACPI is not set/enabled by adding
>>> the header file <asm/acpi.h> which contains a stub for the function
>>> in the build error.
>>>
>>> ../arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
>>> ../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration]
>>>    acpi_noirq_set();
> 
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Thanks!

also:
Reviewed-by: Jesse Barnes <jsbarnes@google.com>

> 
>>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>>> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
>>> Cc: Len Brown <lenb@kernel.org>
>>> Cc: Bjorn Helgaas <bhelgaas@google.com>
>>> Cc: Jesse Barnes <jsbarnes@google.com>
>>> Cc: Arjan van de Ven <arjan@linux.intel.com>
>>> Cc: linux-pci@vger.kernel.org
>>> ---
>>> Found in linux-next, but applies to/exists in mainline also.
>>>
>>> Alternative.1: X86_INTEL_MID depends on ACPI
>>> Alternative.2: drop X86_INTEL_MID support
>>
>> at this point I'd suggest Alternative 2; the products that needed that (past tense, that technology
>> is no longer need for any newer products) never shipped in any form where a 4.x or 5.x kernel could
>> work, and they are also all locked down...
> 
> This is not true. We have Intel Edison which runs nicely on vanilla
> (not everything, some is still requiring a couple of patches, but most
> of it works out-of-the-box).
> 
> And for the record, I have been working on removing quite a pile of
> code (~13kLOCs to the date IIRC) in MID area. Just need some time to
> fix Edison watchdog for that.


I didn't see a consensus on this patch, although Andy says it's still needed,
so it shouldn't be removed (yet). Maybe his big removal patch can remove it
later. For now can we just fix the build error?


-- 
~Randy

Re: [PATCH] x86/pci: fix intel_mid_pci.c build error when ACPI is not enabled

[Jesse Barnes]

On Wed, Aug 19, 2020 at 9:08 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 8/13/20 1:55 PM, Andy Shevchenko wrote:
> > On Thu, Aug 13, 2020 at 11:31 PM Arjan van de Ven <arjan@linux.intel.com> wrote:
> >> On 8/13/2020 12:58 PM, Randy Dunlap wrote:
> >>> From: Randy Dunlap <rdunlap@infradead.org>
> >>>
> >>> Fix build error when CONFIG_ACPI is not set/enabled by adding
> >>> the header file <asm/acpi.h> which contains a stub for the function
> >>> in the build error.
> >>>
> >>> ../arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
> >>> ../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration]
> >>>    acpi_noirq_set();
> >
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > Thanks!
>
> also:
> Reviewed-by: Jesse Barnes <jsbarnes@google.com>
>
> >
> >>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> >>> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
> >>> Cc: Len Brown <lenb@kernel.org>
> >>> Cc: Bjorn Helgaas <bhelgaas@google.com>
> >>> Cc: Jesse Barnes <jsbarnes@google.com>
> >>> Cc: Arjan van de Ven <arjan@linux.intel.com>
> >>> Cc: linux-pci@vger.kernel.org
> >>> ---
> >>> Found in linux-next, but applies to/exists in mainline also.
> >>>
> >>> Alternative.1: X86_INTEL_MID depends on ACPI
> >>> Alternative.2: drop X86_INTEL_MID support
> >>
> >> at this point I'd suggest Alternative 2; the products that needed that (past tense, that technology
> >> is no longer need for any newer products) never shipped in any form where a 4.x or 5.x kernel could
> >> work, and they are also all locked down...
> >
> > This is not true. We have Intel Edison which runs nicely on vanilla
> > (not everything, some is still requiring a couple of patches, but most
> > of it works out-of-the-box).
> >
> > And for the record, I have been working on removing quite a pile of
> > code (~13kLOCs to the date IIRC) in MID area. Just need some time to
> > fix Edison watchdog for that.
>
>
> I didn't see a consensus on this patch, although Andy says it's still needed,
> so it shouldn't be removed (yet). Maybe his big removal patch can remove it
> later. For now can we just fix the build error?


Yeah I think it makes sense to land it.  Doesn't get in the way of a
future removal and fixes a build error in the meantime.

Jesse