[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

When ACPI was originally merged for arm64 it had only been tested on
emulators and not on real physical platforms and no platforms were
relying on it.  This meant that there were concerns that there might be
serious issues attempting to use it on practical systems so it had a
dependency on EXPERT added to warn people that it was in an early stage
of development with very little practical testing.  Since then things
have moved on a bit.  We have seen people testing on real hardware and
now have people starting to produce some platforms (the most prominent
being the 96boards Cello) which only have ACPI support and which build
and run to some useful extent with mainline.

This is not to say that ACPI support or support for these systems is
completely done, there are still areas being worked on such as PCI, but
at this point it seems that we can be reasonably sure that ACPI will be
viable for use on ARM64 and that the already merged support works for
the cases it handles.  For the AMD Seattle based platforms support
outside of PCI has been fairly complete in mainline a few releases now.

This is also not to say that we don't have vendors working with ACPI who
are trying do things that we would not consider optimal but it does not
appear that the EXPERT dependency is having a substantial impact on
these vendors.

Given all this it seems that at this point the EXPERT dependency mainly
creates inconvenience for users with systems that are doing the right
thing and gets in the way of including the ACPI code in the testing that
people are doing on mainline.  Removing it should help our ongoing
testing cover those platforms with only ACPI support and help ensure
that when ACPI code is merged any problems it causes for other users are
more easily discovered.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/acpi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 82b96ee8624c..bf5dc1ac3446 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -5,7 +5,7 @@
 menuconfig ACPI
 	bool "ACPI (Advanced Configuration and Power Interface) Support"
 	depends on !IA64_HP_SIM
-	depends on IA64 || X86 || (ARM64 && EXPERT)
+	depends on IA64 || X86 || ARM64
 	depends on PCI
 	select PNP
 	default y
-- 
2.8.0.rc3

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

When ACPI was originally merged for arm64 it had only been tested on
emulators and not on real physical platforms and no platforms were
relying on it.  This meant that there were concerns that there might be
serious issues attempting to use it on practical systems so it had a
dependency on EXPERT added to warn people that it was in an early stage
of development with very little practical testing.  Since then things
have moved on a bit.  We have seen people testing on real hardware and
now have people starting to produce some platforms (the most prominent
being the 96boards Cello) which only have ACPI support and which build
and run to some useful extent with mainline.

This is not to say that ACPI support or support for these systems is
completely done, there are still areas being worked on such as PCI, but
at this point it seems that we can be reasonably sure that ACPI will be
viable for use on ARM64 and that the already merged support works for
the cases it handles.  For the AMD Seattle based platforms support
outside of PCI has been fairly complete in mainline a few releases now.

This is also not to say that we don't have vendors working with ACPI who
are trying do things that we would not consider optimal but it does not
appear that the EXPERT dependency is having a substantial impact on
these vendors.

Given all this it seems that at this point the EXPERT dependency mainly
creates inconvenience for users with systems that are doing the right
thing and gets in the way of including the ACPI code in the testing that
people are doing on mainline.  Removing it should help our ongoing
testing cover those platforms with only ACPI support and help ensure
that when ACPI code is merged any problems it causes for other users are
more easily discovered.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/acpi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 82b96ee8624c..bf5dc1ac3446 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -5,7 +5,7 @@
 menuconfig ACPI
 	bool "ACPI (Advanced Configuration and Power Interface) Support"
 	depends on !IA64_HP_SIM
-	depends on IA64 || X86 || (ARM64 && EXPERT)
+	depends on IA64 || X86 || ARM64
 	depends on PCI
 	select PNP
 	default y
-- 
2.8.0.rc3

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[G Gregory]

On 30 March 2016 at 18:58, Mark Brown <broonie@kernel.org> wrote:
> When ACPI was originally merged for arm64 it had only been tested on
> emulators and not on real physical platforms and no platforms were
> relying on it.  This meant that there were concerns that there might be
> serious issues attempting to use it on practical systems so it had a
> dependency on EXPERT added to warn people that it was in an early stage
> of development with very little practical testing.  Since then things
> have moved on a bit.  We have seen people testing on real hardware and
> now have people starting to produce some platforms (the most prominent
> being the 96boards Cello) which only have ACPI support and which build
> and run to some useful extent with mainline.
>
> This is not to say that ACPI support or support for these systems is
> completely done, there are still areas being worked on such as PCI, but
> at this point it seems that we can be reasonably sure that ACPI will be
> viable for use on ARM64 and that the already merged support works for
> the cases it handles.  For the AMD Seattle based platforms support
> outside of PCI has been fairly complete in mainline a few releases now.
>
> This is also not to say that we don't have vendors working with ACPI who
> are trying do things that we would not consider optimal but it does not
> appear that the EXPERT dependency is having a substantial impact on
> these vendors.
>
> Given all this it seems that at this point the EXPERT dependency mainly
> creates inconvenience for users with systems that are doing the right
> thing and gets in the way of including the ACPI code in the testing that
> people are doing on mainline.  Removing it should help our ongoing
> testing cover those platforms with only ACPI support and help ensure
> that when ACPI code is merged any problems it causes for other users are
> more easily discovered.
>

I agree,

Acked-by: Graeme Gregory <graeme.gregory@linaro.org>

Thanks

G

> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/acpi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee8624c..bf5dc1ac3446 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,7 +5,7 @@
>  menuconfig ACPI
>         bool "ACPI (Advanced Configuration and Power Interface) Support"
>         depends on !IA64_HP_SIM
> -       depends on IA64 || X86 || (ARM64 && EXPERT)
> +       depends on IA64 || X86 || ARM64
>         depends on PCI
>         select PNP
>         default y
> --
> 2.8.0.rc3
>

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[G Gregory]

On 30 March 2016 at 18:58, Mark Brown <broonie@kernel.org> wrote:
> When ACPI was originally merged for arm64 it had only been tested on
> emulators and not on real physical platforms and no platforms were
> relying on it.  This meant that there were concerns that there might be
> serious issues attempting to use it on practical systems so it had a
> dependency on EXPERT added to warn people that it was in an early stage
> of development with very little practical testing.  Since then things
> have moved on a bit.  We have seen people testing on real hardware and
> now have people starting to produce some platforms (the most prominent
> being the 96boards Cello) which only have ACPI support and which build
> and run to some useful extent with mainline.
>
> This is not to say that ACPI support or support for these systems is
> completely done, there are still areas being worked on such as PCI, but
> at this point it seems that we can be reasonably sure that ACPI will be
> viable for use on ARM64 and that the already merged support works for
> the cases it handles.  For the AMD Seattle based platforms support
> outside of PCI has been fairly complete in mainline a few releases now.
>
> This is also not to say that we don't have vendors working with ACPI who
> are trying do things that we would not consider optimal but it does not
> appear that the EXPERT dependency is having a substantial impact on
> these vendors.
>
> Given all this it seems that at this point the EXPERT dependency mainly
> creates inconvenience for users with systems that are doing the right
> thing and gets in the way of including the ACPI code in the testing that
> people are doing on mainline.  Removing it should help our ongoing
> testing cover those platforms with only ACPI support and help ensure
> that when ACPI code is merged any problems it causes for other users are
> more easily discovered.
>

I agree,

Acked-by: Graeme Gregory <graeme.gregory@linaro.org>

Thanks

G

> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/acpi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee8624c..bf5dc1ac3446 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,7 +5,7 @@
>  menuconfig ACPI
>         bool "ACPI (Advanced Configuration and Power Interface) Support"
>         depends on !IA64_HP_SIM
> -       depends on IA64 || X86 || (ARM64 && EXPERT)
> +       depends on IA64 || X86 || ARM64
>         depends on PCI
>         select PNP
>         default y
> --
> 2.8.0.rc3
>

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Ard Biesheuvel]

On 30 March 2016 at 19:58, Mark Brown <broonie@kernel.org> wrote:
> When ACPI was originally merged for arm64 it had only been tested on
> emulators and not on real physical platforms and no platforms were
> relying on it.  This meant that there were concerns that there might be
> serious issues attempting to use it on practical systems so it had a
> dependency on EXPERT added to warn people that it was in an early stage
> of development with very little practical testing.  Since then things
> have moved on a bit.  We have seen people testing on real hardware and
> now have people starting to produce some platforms (the most prominent
> being the 96boards Cello) which only have ACPI support and which build
> and run to some useful extent with mainline.
>
> This is not to say that ACPI support or support for these systems is
> completely done, there are still areas being worked on such as PCI, but
> at this point it seems that we can be reasonably sure that ACPI will be
> viable for use on ARM64 and that the already merged support works for
> the cases it handles.  For the AMD Seattle based platforms support
> outside of PCI has been fairly complete in mainline a few releases now.
>
> This is also not to say that we don't have vendors working with ACPI who
> are trying do things that we would not consider optimal but it does not
> appear that the EXPERT dependency is having a substantial impact on
> these vendors.
>
> Given all this it seems that at this point the EXPERT dependency mainly
> creates inconvenience for users with systems that are doing the right
> thing and gets in the way of including the ACPI code in the testing that
> people are doing on mainline.  Removing it should help our ongoing
> testing cover those platforms with only ACPI support and help ensure
> that when ACPI code is merged any problems it causes for other users are
> more easily discovered.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

> ---
>  drivers/acpi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee8624c..bf5dc1ac3446 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,7 +5,7 @@
>  menuconfig ACPI
>         bool "ACPI (Advanced Configuration and Power Interface) Support"
>         depends on !IA64_HP_SIM
> -       depends on IA64 || X86 || (ARM64 && EXPERT)
> +       depends on IA64 || X86 || ARM64
>         depends on PCI
>         select PNP
>         default y
> --
> 2.8.0.rc3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Ard Biesheuvel]

On 30 March 2016 at 19:58, Mark Brown <broonie@kernel.org> wrote:
> When ACPI was originally merged for arm64 it had only been tested on
> emulators and not on real physical platforms and no platforms were
> relying on it.  This meant that there were concerns that there might be
> serious issues attempting to use it on practical systems so it had a
> dependency on EXPERT added to warn people that it was in an early stage
> of development with very little practical testing.  Since then things
> have moved on a bit.  We have seen people testing on real hardware and
> now have people starting to produce some platforms (the most prominent
> being the 96boards Cello) which only have ACPI support and which build
> and run to some useful extent with mainline.
>
> This is not to say that ACPI support or support for these systems is
> completely done, there are still areas being worked on such as PCI, but
> at this point it seems that we can be reasonably sure that ACPI will be
> viable for use on ARM64 and that the already merged support works for
> the cases it handles.  For the AMD Seattle based platforms support
> outside of PCI has been fairly complete in mainline a few releases now.
>
> This is also not to say that we don't have vendors working with ACPI who
> are trying do things that we would not consider optimal but it does not
> appear that the EXPERT dependency is having a substantial impact on
> these vendors.
>
> Given all this it seems that at this point the EXPERT dependency mainly
> creates inconvenience for users with systems that are doing the right
> thing and gets in the way of including the ACPI code in the testing that
> people are doing on mainline.  Removing it should help our ongoing
> testing cover those platforms with only ACPI support and help ensure
> that when ACPI code is merged any problems it causes for other users are
> more easily discovered.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

> ---
>  drivers/acpi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee8624c..bf5dc1ac3446 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,7 +5,7 @@
>  menuconfig ACPI
>         bool "ACPI (Advanced Configuration and Power Interface) Support"
>         depends on !IA64_HP_SIM
> -       depends on IA64 || X86 || (ARM64 && EXPERT)
> +       depends on IA64 || X86 || ARM64
>         depends on PCI
>         select PNP
>         default y
> --
> 2.8.0.rc3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Al Stone]

On 03/30/2016 11:58 AM, Mark Brown wrote:
> When ACPI was originally merged for arm64 it had only been tested on
> emulators and not on real physical platforms and no platforms were
> relying on it.  This meant that there were concerns that there might be
> serious issues attempting to use it on practical systems so it had a
> dependency on EXPERT added to warn people that it was in an early stage
> of development with very little practical testing.  Since then things
> have moved on a bit.  We have seen people testing on real hardware and
> now have people starting to produce some platforms (the most prominent
> being the 96boards Cello) which only have ACPI support and which build
> and run to some useful extent with mainline.
> 
> This is not to say that ACPI support or support for these systems is
> completely done, there are still areas being worked on such as PCI, but
> at this point it seems that we can be reasonably sure that ACPI will be
> viable for use on ARM64 and that the already merged support works for
> the cases it handles.  For the AMD Seattle based platforms support
> outside of PCI has been fairly complete in mainline a few releases now.
> 
> This is also not to say that we don't have vendors working with ACPI who
> are trying do things that we would not consider optimal but it does not
> appear that the EXPERT dependency is having a substantial impact on
> these vendors.
> 
> Given all this it seems that at this point the EXPERT dependency mainly
> creates inconvenience for users with systems that are doing the right
> thing and gets in the way of including the ACPI code in the testing that
> people are doing on mainline.  Removing it should help our ongoing
> testing cover those platforms with only ACPI support and help ensure
> that when ACPI code is merged any problems it causes for other users are
> more easily discovered.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/acpi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee8624c..bf5dc1ac3446 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,7 +5,7 @@
>  menuconfig ACPI
>  	bool "ACPI (Advanced Configuration and Power Interface) Support"
>  	depends on !IA64_HP_SIM
> -	depends on IA64 || X86 || (ARM64 && EXPERT)
> +	depends on IA64 || X86 || ARM64
>  	depends on PCI
>  	select PNP
>  	default y
> 

Yes, please.

Reviewed-by: Al Stone <ahs3@redhat.com>

Thanks.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@redhat.com
-----------------------------------

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Al Stone]

On 03/30/2016 11:58 AM, Mark Brown wrote:
> When ACPI was originally merged for arm64 it had only been tested on
> emulators and not on real physical platforms and no platforms were
> relying on it.  This meant that there were concerns that there might be
> serious issues attempting to use it on practical systems so it had a
> dependency on EXPERT added to warn people that it was in an early stage
> of development with very little practical testing.  Since then things
> have moved on a bit.  We have seen people testing on real hardware and
> now have people starting to produce some platforms (the most prominent
> being the 96boards Cello) which only have ACPI support and which build
> and run to some useful extent with mainline.
> 
> This is not to say that ACPI support or support for these systems is
> completely done, there are still areas being worked on such as PCI, but
> at this point it seems that we can be reasonably sure that ACPI will be
> viable for use on ARM64 and that the already merged support works for
> the cases it handles.  For the AMD Seattle based platforms support
> outside of PCI has been fairly complete in mainline a few releases now.
> 
> This is also not to say that we don't have vendors working with ACPI who
> are trying do things that we would not consider optimal but it does not
> appear that the EXPERT dependency is having a substantial impact on
> these vendors.
> 
> Given all this it seems that at this point the EXPERT dependency mainly
> creates inconvenience for users with systems that are doing the right
> thing and gets in the way of including the ACPI code in the testing that
> people are doing on mainline.  Removing it should help our ongoing
> testing cover those platforms with only ACPI support and help ensure
> that when ACPI code is merged any problems it causes for other users are
> more easily discovered.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/acpi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee8624c..bf5dc1ac3446 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,7 +5,7 @@
>  menuconfig ACPI
>  	bool "ACPI (Advanced Configuration and Power Interface) Support"
>  	depends on !IA64_HP_SIM
> -	depends on IA64 || X86 || (ARM64 && EXPERT)
> +	depends on IA64 || X86 || ARM64
>  	depends on PCI
>  	select PNP
>  	default y
> 

Yes, please.

Reviewed-by: Al Stone <ahs3@redhat.com>

Thanks.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3 at redhat.com
-----------------------------------

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Hanjun Guo]

On 2016/3/31 1:58, Mark Brown wrote:
> When ACPI was originally merged for arm64 it had only been tested on
> emulators and not on real physical platforms and no platforms were
> relying on it.  This meant that there were concerns that there might be
> serious issues attempting to use it on practical systems so it had a
> dependency on EXPERT added to warn people that it was in an early stage
> of development with very little practical testing.  Since then things
> have moved on a bit.  We have seen people testing on real hardware and
> now have people starting to produce some platforms (the most prominent
> being the 96boards Cello) which only have ACPI support and which build
> and run to some useful extent with mainline.
>
> This is not to say that ACPI support or support for these systems is
> completely done, there are still areas being worked on such as PCI, but
> at this point it seems that we can be reasonably sure that ACPI will be
> viable for use on ARM64 and that the already merged support works for
> the cases it handles.  For the AMD Seattle based platforms support
> outside of PCI has been fairly complete in mainline a few releases now.
>
> This is also not to say that we don't have vendors working with ACPI who
> are trying do things that we would not consider optimal but it does not
> appear that the EXPERT dependency is having a substantial impact on
> these vendors.
>
> Given all this it seems that at this point the EXPERT dependency mainly
> creates inconvenience for users with systems that are doing the right
> thing and gets in the way of including the ACPI code in the testing that
> people are doing on mainline.  Removing it should help our ongoing
> testing cover those platforms with only ACPI support and help ensure
> that when ACPI code is merged any problems it causes for other users are
> more easily discovered.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>

Acked-by: Hanjun Guo <hanjun.guo@linaro.org>

> ---
>  drivers/acpi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee8624c..bf5dc1ac3446 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,7 +5,7 @@
>  menuconfig ACPI
>  	bool "ACPI (Advanced Configuration and Power Interface) Support"
>  	depends on !IA64_HP_SIM
> -	depends on IA64 || X86 || (ARM64 && EXPERT)
> +	depends on IA64 || X86 || ARM64
>  	depends on PCI
>  	select PNP
>  	default y

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Hanjun Guo]

On 2016/3/31 1:58, Mark Brown wrote:
> When ACPI was originally merged for arm64 it had only been tested on
> emulators and not on real physical platforms and no platforms were
> relying on it.  This meant that there were concerns that there might be
> serious issues attempting to use it on practical systems so it had a
> dependency on EXPERT added to warn people that it was in an early stage
> of development with very little practical testing.  Since then things
> have moved on a bit.  We have seen people testing on real hardware and
> now have people starting to produce some platforms (the most prominent
> being the 96boards Cello) which only have ACPI support and which build
> and run to some useful extent with mainline.
>
> This is not to say that ACPI support or support for these systems is
> completely done, there are still areas being worked on such as PCI, but
> at this point it seems that we can be reasonably sure that ACPI will be
> viable for use on ARM64 and that the already merged support works for
> the cases it handles.  For the AMD Seattle based platforms support
> outside of PCI has been fairly complete in mainline a few releases now.
>
> This is also not to say that we don't have vendors working with ACPI who
> are trying do things that we would not consider optimal but it does not
> appear that the EXPERT dependency is having a substantial impact on
> these vendors.
>
> Given all this it seems that at this point the EXPERT dependency mainly
> creates inconvenience for users with systems that are doing the right
> thing and gets in the way of including the ACPI code in the testing that
> people are doing on mainline.  Removing it should help our ongoing
> testing cover those platforms with only ACPI support and help ensure
> that when ACPI code is merged any problems it causes for other users are
> more easily discovered.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>

Acked-by: Hanjun Guo <hanjun.guo@linaro.org>

> ---
>  drivers/acpi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee8624c..bf5dc1ac3446 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,7 +5,7 @@
>  menuconfig ACPI
>  	bool "ACPI (Advanced Configuration and Power Interface) Support"
>  	depends on !IA64_HP_SIM
> -	depends on IA64 || X86 || (ARM64 && EXPERT)
> +	depends on IA64 || X86 || ARM64
>  	depends on PCI
>  	select PNP
>  	default y

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Rafael J. Wysocki]

On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
> On 2016/3/31 1:58, Mark Brown wrote:
>> When ACPI was originally merged for arm64 it had only been tested on
>> emulators and not on real physical platforms and no platforms were
>> relying on it.  This meant that there were concerns that there might be
>> serious issues attempting to use it on practical systems so it had a
>> dependency on EXPERT added to warn people that it was in an early stage
>> of development with very little practical testing.  Since then things
>> have moved on a bit.  We have seen people testing on real hardware and
>> now have people starting to produce some platforms (the most prominent
>> being the 96boards Cello) which only have ACPI support and which build
>> and run to some useful extent with mainline.
>>
>> This is not to say that ACPI support or support for these systems is
>> completely done, there are still areas being worked on such as PCI, but
>> at this point it seems that we can be reasonably sure that ACPI will be
>> viable for use on ARM64 and that the already merged support works for
>> the cases it handles.  For the AMD Seattle based platforms support
>> outside of PCI has been fairly complete in mainline a few releases now.
>>
>> This is also not to say that we don't have vendors working with ACPI who
>> are trying do things that we would not consider optimal but it does not
>> appear that the EXPERT dependency is having a substantial impact on
>> these vendors.
>>
>> Given all this it seems that at this point the EXPERT dependency mainly
>> creates inconvenience for users with systems that are doing the right
>> thing and gets in the way of including the ACPI code in the testing that
>> people are doing on mainline.  Removing it should help our ongoing
>> testing cover those platforms with only ACPI support and help ensure
>> that when ACPI code is merged any problems it causes for other users are
>> more easily discovered.
>>
>> Signed-off-by: Mark Brown <broonie@kernel.org>
>
> Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>
>> ---
>>  drivers/acpi/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 82b96ee8624c..bf5dc1ac3446 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -5,7 +5,7 @@
>>  menuconfig ACPI
>>       bool "ACPI (Advanced Configuration and Power Interface) Support"
>>       depends on !IA64_HP_SIM
>> -     depends on IA64 || X86 || (ARM64 && EXPERT)
>> +     depends on IA64 || X86 || ARM64
>>       depends on PCI
>>       select PNP
>>       default y

OK

What do the ARM64 maintainers think?

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Rafael J. Wysocki]

On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
> On 2016/3/31 1:58, Mark Brown wrote:
>> When ACPI was originally merged for arm64 it had only been tested on
>> emulators and not on real physical platforms and no platforms were
>> relying on it.  This meant that there were concerns that there might be
>> serious issues attempting to use it on practical systems so it had a
>> dependency on EXPERT added to warn people that it was in an early stage
>> of development with very little practical testing.  Since then things
>> have moved on a bit.  We have seen people testing on real hardware and
>> now have people starting to produce some platforms (the most prominent
>> being the 96boards Cello) which only have ACPI support and which build
>> and run to some useful extent with mainline.
>>
>> This is not to say that ACPI support or support for these systems is
>> completely done, there are still areas being worked on such as PCI, but
>> at this point it seems that we can be reasonably sure that ACPI will be
>> viable for use on ARM64 and that the already merged support works for
>> the cases it handles.  For the AMD Seattle based platforms support
>> outside of PCI has been fairly complete in mainline a few releases now.
>>
>> This is also not to say that we don't have vendors working with ACPI who
>> are trying do things that we would not consider optimal but it does not
>> appear that the EXPERT dependency is having a substantial impact on
>> these vendors.
>>
>> Given all this it seems that at this point the EXPERT dependency mainly
>> creates inconvenience for users with systems that are doing the right
>> thing and gets in the way of including the ACPI code in the testing that
>> people are doing on mainline.  Removing it should help our ongoing
>> testing cover those platforms with only ACPI support and help ensure
>> that when ACPI code is merged any problems it causes for other users are
>> more easily discovered.
>>
>> Signed-off-by: Mark Brown <broonie@kernel.org>
>
> Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>
>> ---
>>  drivers/acpi/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 82b96ee8624c..bf5dc1ac3446 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -5,7 +5,7 @@
>>  menuconfig ACPI
>>       bool "ACPI (Advanced Configuration and Power Interface) Support"
>>       depends on !IA64_HP_SIM
>> -     depends on IA64 || X86 || (ARM64 && EXPERT)
>> +     depends on IA64 || X86 || ARM64
>>       depends on PCI
>>       select PNP
>>       default y

OK

What do the ARM64 maintainers think?

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Will Deacon]

On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote:
> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
> > On 2016/3/31 1:58, Mark Brown wrote:
> >> When ACPI was originally merged for arm64 it had only been tested on
> >> emulators and not on real physical platforms and no platforms were
> >> relying on it.  This meant that there were concerns that there might be
> >> serious issues attempting to use it on practical systems so it had a
> >> dependency on EXPERT added to warn people that it was in an early stage
> >> of development with very little practical testing.  Since then things
> >> have moved on a bit.  We have seen people testing on real hardware and
> >> now have people starting to produce some platforms (the most prominent
> >> being the 96boards Cello) which only have ACPI support and which build
> >> and run to some useful extent with mainline.
> >>
> >> This is not to say that ACPI support or support for these systems is
> >> completely done, there are still areas being worked on such as PCI, but
> >> at this point it seems that we can be reasonably sure that ACPI will be
> >> viable for use on ARM64 and that the already merged support works for
> >> the cases it handles.  For the AMD Seattle based platforms support
> >> outside of PCI has been fairly complete in mainline a few releases now.
> >>
> >> This is also not to say that we don't have vendors working with ACPI who
> >> are trying do things that we would not consider optimal but it does not
> >> appear that the EXPERT dependency is having a substantial impact on
> >> these vendors.
> >>
> >> Given all this it seems that at this point the EXPERT dependency mainly
> >> creates inconvenience for users with systems that are doing the right
> >> thing and gets in the way of including the ACPI code in the testing that
> >> people are doing on mainline.  Removing it should help our ongoing
> >> testing cover those platforms with only ACPI support and help ensure
> >> that when ACPI code is merged any problems it causes for other users are
> >> more easily discovered.
> >>
> >> Signed-off-by: Mark Brown <broonie@kernel.org>
> >
> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> >
> >> ---
> >>  drivers/acpi/Kconfig | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> >> index 82b96ee8624c..bf5dc1ac3446 100644
> >> --- a/drivers/acpi/Kconfig
> >> +++ b/drivers/acpi/Kconfig
> >> @@ -5,7 +5,7 @@
> >>  menuconfig ACPI
> >>       bool "ACPI (Advanced Configuration and Power Interface) Support"
> >>       depends on !IA64_HP_SIM
> >> -     depends on IA64 || X86 || (ARM64 && EXPERT)
> >> +     depends on IA64 || X86 || ARM64
> >>       depends on PCI
> >>       select PNP
> >>       default y
> 
> OK
> 
> What do the ARM64 maintainers think?

I'm unsure about whether or not we want 'default y' here, but I'd like
to wait for Catalin to come back from his 2-week holiday before going
anywhere with this patch. It's only fair that his opinion should be
taken into account, and there's not a huge rush for this. I do consider
"ACPI-only platforms" as simply "platforms without a .dtb" (modulo
any significant AML code) and therefore don't view this as a blocking
issue.

We should also take into account the large amount of ongoing ACPI work
(e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
etc), and decide whether or not that's currently in a state where we want
to encourage people to start using this in their arm64 kernels.

Will

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Will Deacon]

On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote:
> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
> > On 2016/3/31 1:58, Mark Brown wrote:
> >> When ACPI was originally merged for arm64 it had only been tested on
> >> emulators and not on real physical platforms and no platforms were
> >> relying on it.  This meant that there were concerns that there might be
> >> serious issues attempting to use it on practical systems so it had a
> >> dependency on EXPERT added to warn people that it was in an early stage
> >> of development with very little practical testing.  Since then things
> >> have moved on a bit.  We have seen people testing on real hardware and
> >> now have people starting to produce some platforms (the most prominent
> >> being the 96boards Cello) which only have ACPI support and which build
> >> and run to some useful extent with mainline.
> >>
> >> This is not to say that ACPI support or support for these systems is
> >> completely done, there are still areas being worked on such as PCI, but
> >> at this point it seems that we can be reasonably sure that ACPI will be
> >> viable for use on ARM64 and that the already merged support works for
> >> the cases it handles.  For the AMD Seattle based platforms support
> >> outside of PCI has been fairly complete in mainline a few releases now.
> >>
> >> This is also not to say that we don't have vendors working with ACPI who
> >> are trying do things that we would not consider optimal but it does not
> >> appear that the EXPERT dependency is having a substantial impact on
> >> these vendors.
> >>
> >> Given all this it seems that at this point the EXPERT dependency mainly
> >> creates inconvenience for users with systems that are doing the right
> >> thing and gets in the way of including the ACPI code in the testing that
> >> people are doing on mainline.  Removing it should help our ongoing
> >> testing cover those platforms with only ACPI support and help ensure
> >> that when ACPI code is merged any problems it causes for other users are
> >> more easily discovered.
> >>
> >> Signed-off-by: Mark Brown <broonie@kernel.org>
> >
> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> >
> >> ---
> >>  drivers/acpi/Kconfig | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> >> index 82b96ee8624c..bf5dc1ac3446 100644
> >> --- a/drivers/acpi/Kconfig
> >> +++ b/drivers/acpi/Kconfig
> >> @@ -5,7 +5,7 @@
> >>  menuconfig ACPI
> >>       bool "ACPI (Advanced Configuration and Power Interface) Support"
> >>       depends on !IA64_HP_SIM
> >> -     depends on IA64 || X86 || (ARM64 && EXPERT)
> >> +     depends on IA64 || X86 || ARM64
> >>       depends on PCI
> >>       select PNP
> >>       default y
> 
> OK
> 
> What do the ARM64 maintainers think?

I'm unsure about whether or not we want 'default y' here, but I'd like
to wait for Catalin to come back from his 2-week holiday before going
anywhere with this patch. It's only fair that his opinion should be
taken into account, and there's not a huge rush for this. I do consider
"ACPI-only platforms" as simply "platforms without a .dtb" (modulo
any significant AML code) and therefore don't view this as a blocking
issue.

We should also take into account the large amount of ongoing ACPI work
(e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
etc), and decide whether or not that's currently in a state where we want
to encourage people to start using this in their arm64 kernels.

Will

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Rafael J. Wysocki]

On Thu, Mar 31, 2016 at 2:36 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote:
>> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
>> > On 2016/3/31 1:58, Mark Brown wrote:
>> >> When ACPI was originally merged for arm64 it had only been tested on
>> >> emulators and not on real physical platforms and no platforms were
>> >> relying on it.  This meant that there were concerns that there might be
>> >> serious issues attempting to use it on practical systems so it had a
>> >> dependency on EXPERT added to warn people that it was in an early stage
>> >> of development with very little practical testing.  Since then things
>> >> have moved on a bit.  We have seen people testing on real hardware and
>> >> now have people starting to produce some platforms (the most prominent
>> >> being the 96boards Cello) which only have ACPI support and which build
>> >> and run to some useful extent with mainline.
>> >>
>> >> This is not to say that ACPI support or support for these systems is
>> >> completely done, there are still areas being worked on such as PCI, but
>> >> at this point it seems that we can be reasonably sure that ACPI will be
>> >> viable for use on ARM64 and that the already merged support works for
>> >> the cases it handles.  For the AMD Seattle based platforms support
>> >> outside of PCI has been fairly complete in mainline a few releases now.
>> >>
>> >> This is also not to say that we don't have vendors working with ACPI who
>> >> are trying do things that we would not consider optimal but it does not
>> >> appear that the EXPERT dependency is having a substantial impact on
>> >> these vendors.
>> >>
>> >> Given all this it seems that at this point the EXPERT dependency mainly
>> >> creates inconvenience for users with systems that are doing the right
>> >> thing and gets in the way of including the ACPI code in the testing that
>> >> people are doing on mainline.  Removing it should help our ongoing
>> >> testing cover those platforms with only ACPI support and help ensure
>> >> that when ACPI code is merged any problems it causes for other users are
>> >> more easily discovered.
>> >>
>> >> Signed-off-by: Mark Brown <broonie@kernel.org>
>> >
>> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>> >
>> >> ---
>> >>  drivers/acpi/Kconfig | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> >> index 82b96ee8624c..bf5dc1ac3446 100644
>> >> --- a/drivers/acpi/Kconfig
>> >> +++ b/drivers/acpi/Kconfig
>> >> @@ -5,7 +5,7 @@
>> >>  menuconfig ACPI
>> >>       bool "ACPI (Advanced Configuration and Power Interface) Support"
>> >>       depends on !IA64_HP_SIM
>> >> -     depends on IA64 || X86 || (ARM64 && EXPERT)
>> >> +     depends on IA64 || X86 || ARM64
>> >>       depends on PCI
>> >>       select PNP
>> >>       default y
>>
>> OK
>>
>> What do the ARM64 maintainers think?
>
> I'm unsure about whether or not we want 'default y' here, but I'd like
> to wait for Catalin to come back from his 2-week holiday before going
> anywhere with this patch. It's only fair that his opinion should be
> taken into account, and there's not a huge rush for this. I do consider
> "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
> any significant AML code) and therefore don't view this as a blocking
> issue.
>
> We should also take into account the large amount of ongoing ACPI work
> (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
> etc), and decide whether or not that's currently in a state where we want
> to encourage people to start using this in their arm64 kernels.

Fair enough.

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Rafael J. Wysocki]

On Thu, Mar 31, 2016 at 2:36 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote:
>> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
>> > On 2016/3/31 1:58, Mark Brown wrote:
>> >> When ACPI was originally merged for arm64 it had only been tested on
>> >> emulators and not on real physical platforms and no platforms were
>> >> relying on it.  This meant that there were concerns that there might be
>> >> serious issues attempting to use it on practical systems so it had a
>> >> dependency on EXPERT added to warn people that it was in an early stage
>> >> of development with very little practical testing.  Since then things
>> >> have moved on a bit.  We have seen people testing on real hardware and
>> >> now have people starting to produce some platforms (the most prominent
>> >> being the 96boards Cello) which only have ACPI support and which build
>> >> and run to some useful extent with mainline.
>> >>
>> >> This is not to say that ACPI support or support for these systems is
>> >> completely done, there are still areas being worked on such as PCI, but
>> >> at this point it seems that we can be reasonably sure that ACPI will be
>> >> viable for use on ARM64 and that the already merged support works for
>> >> the cases it handles.  For the AMD Seattle based platforms support
>> >> outside of PCI has been fairly complete in mainline a few releases now.
>> >>
>> >> This is also not to say that we don't have vendors working with ACPI who
>> >> are trying do things that we would not consider optimal but it does not
>> >> appear that the EXPERT dependency is having a substantial impact on
>> >> these vendors.
>> >>
>> >> Given all this it seems that at this point the EXPERT dependency mainly
>> >> creates inconvenience for users with systems that are doing the right
>> >> thing and gets in the way of including the ACPI code in the testing that
>> >> people are doing on mainline.  Removing it should help our ongoing
>> >> testing cover those platforms with only ACPI support and help ensure
>> >> that when ACPI code is merged any problems it causes for other users are
>> >> more easily discovered.
>> >>
>> >> Signed-off-by: Mark Brown <broonie@kernel.org>
>> >
>> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>> >
>> >> ---
>> >>  drivers/acpi/Kconfig | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> >> index 82b96ee8624c..bf5dc1ac3446 100644
>> >> --- a/drivers/acpi/Kconfig
>> >> +++ b/drivers/acpi/Kconfig
>> >> @@ -5,7 +5,7 @@
>> >>  menuconfig ACPI
>> >>       bool "ACPI (Advanced Configuration and Power Interface) Support"
>> >>       depends on !IA64_HP_SIM
>> >> -     depends on IA64 || X86 || (ARM64 && EXPERT)
>> >> +     depends on IA64 || X86 || ARM64
>> >>       depends on PCI
>> >>       select PNP
>> >>       default y
>>
>> OK
>>
>> What do the ARM64 maintainers think?
>
> I'm unsure about whether or not we want 'default y' here, but I'd like
> to wait for Catalin to come back from his 2-week holiday before going
> anywhere with this patch. It's only fair that his opinion should be
> taken into account, and there's not a huge rush for this. I do consider
> "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
> any significant AML code) and therefore don't view this as a blocking
> issue.
>
> We should also take into account the large amount of ongoing ACPI work
> (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
> etc), and decide whether or not that's currently in a state where we want
> to encourage people to start using this in their arm64 kernels.

Fair enough.

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Ard Biesheuvel]

On 31 March 2016 at 14:36, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote:
>> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
>> > On 2016/3/31 1:58, Mark Brown wrote:
>> >> When ACPI was originally merged for arm64 it had only been tested on
>> >> emulators and not on real physical platforms and no platforms were
>> >> relying on it.  This meant that there were concerns that there might be
>> >> serious issues attempting to use it on practical systems so it had a
>> >> dependency on EXPERT added to warn people that it was in an early stage
>> >> of development with very little practical testing.  Since then things
>> >> have moved on a bit.  We have seen people testing on real hardware and
>> >> now have people starting to produce some platforms (the most prominent
>> >> being the 96boards Cello) which only have ACPI support and which build
>> >> and run to some useful extent with mainline.
>> >>
>> >> This is not to say that ACPI support or support for these systems is
>> >> completely done, there are still areas being worked on such as PCI, but
>> >> at this point it seems that we can be reasonably sure that ACPI will be
>> >> viable for use on ARM64 and that the already merged support works for
>> >> the cases it handles.  For the AMD Seattle based platforms support
>> >> outside of PCI has been fairly complete in mainline a few releases now.
>> >>
>> >> This is also not to say that we don't have vendors working with ACPI who
>> >> are trying do things that we would not consider optimal but it does not
>> >> appear that the EXPERT dependency is having a substantial impact on
>> >> these vendors.
>> >>
>> >> Given all this it seems that at this point the EXPERT dependency mainly
>> >> creates inconvenience for users with systems that are doing the right
>> >> thing and gets in the way of including the ACPI code in the testing that
>> >> people are doing on mainline.  Removing it should help our ongoing
>> >> testing cover those platforms with only ACPI support and help ensure
>> >> that when ACPI code is merged any problems it causes for other users are
>> >> more easily discovered.
>> >>
>> >> Signed-off-by: Mark Brown <broonie@kernel.org>
>> >
>> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>> >
>> >> ---
>> >>  drivers/acpi/Kconfig | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> >> index 82b96ee8624c..bf5dc1ac3446 100644
>> >> --- a/drivers/acpi/Kconfig
>> >> +++ b/drivers/acpi/Kconfig
>> >> @@ -5,7 +5,7 @@
>> >>  menuconfig ACPI
>> >>       bool "ACPI (Advanced Configuration and Power Interface) Support"
>> >>       depends on !IA64_HP_SIM
>> >> -     depends on IA64 || X86 || (ARM64 && EXPERT)
>> >> +     depends on IA64 || X86 || ARM64
>> >>       depends on PCI
>> >>       select PNP
>> >>       default y
>>
>> OK
>>
>> What do the ARM64 maintainers think?
>
> I'm unsure about whether or not we want 'default y' here, but I'd like
> to wait for Catalin to come back from his 2-week holiday before going
> anywhere with this patch.

Ack to that, but ...

> It's only fair that his opinion should be
> taken into account, and there's not a huge rush for this. I do consider
> "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
> any significant AML code) and therefore don't view this as a blocking
> issue.
>

... this patch will only affect those systems. DT-based systems, even
if they provide an ACPI description as well, will not invoke the ACPI
code unless you go out of your way to either boot without a DT or pass
'acpi=force' on the command line. On the other hand, it will make
generic kernels (defconfig, etc) bootable on ACPI only systems, which
currently require special kernel builds. Another important reason for
this change is to get more build testing coverage for the arm64 ACPI
code that we had so much fuss about, e.g, by the kbuild test robot.

> We should also take into account the large amount of ongoing ACPI work
> (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
> etc), and decide whether or not that's currently in a state where we want
> to encourage people to start using this in their arm64 kernels.
>

The question is not about using it, the question is about
incorporating it into the default build. The runtime opt-in is not
going away with this patch.

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Ard Biesheuvel]

On 31 March 2016 at 14:36, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote:
>> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
>> > On 2016/3/31 1:58, Mark Brown wrote:
>> >> When ACPI was originally merged for arm64 it had only been tested on
>> >> emulators and not on real physical platforms and no platforms were
>> >> relying on it.  This meant that there were concerns that there might be
>> >> serious issues attempting to use it on practical systems so it had a
>> >> dependency on EXPERT added to warn people that it was in an early stage
>> >> of development with very little practical testing.  Since then things
>> >> have moved on a bit.  We have seen people testing on real hardware and
>> >> now have people starting to produce some platforms (the most prominent
>> >> being the 96boards Cello) which only have ACPI support and which build
>> >> and run to some useful extent with mainline.
>> >>
>> >> This is not to say that ACPI support or support for these systems is
>> >> completely done, there are still areas being worked on such as PCI, but
>> >> at this point it seems that we can be reasonably sure that ACPI will be
>> >> viable for use on ARM64 and that the already merged support works for
>> >> the cases it handles.  For the AMD Seattle based platforms support
>> >> outside of PCI has been fairly complete in mainline a few releases now.
>> >>
>> >> This is also not to say that we don't have vendors working with ACPI who
>> >> are trying do things that we would not consider optimal but it does not
>> >> appear that the EXPERT dependency is having a substantial impact on
>> >> these vendors.
>> >>
>> >> Given all this it seems that at this point the EXPERT dependency mainly
>> >> creates inconvenience for users with systems that are doing the right
>> >> thing and gets in the way of including the ACPI code in the testing that
>> >> people are doing on mainline.  Removing it should help our ongoing
>> >> testing cover those platforms with only ACPI support and help ensure
>> >> that when ACPI code is merged any problems it causes for other users are
>> >> more easily discovered.
>> >>
>> >> Signed-off-by: Mark Brown <broonie@kernel.org>
>> >
>> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>> >
>> >> ---
>> >>  drivers/acpi/Kconfig | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> >> index 82b96ee8624c..bf5dc1ac3446 100644
>> >> --- a/drivers/acpi/Kconfig
>> >> +++ b/drivers/acpi/Kconfig
>> >> @@ -5,7 +5,7 @@
>> >>  menuconfig ACPI
>> >>       bool "ACPI (Advanced Configuration and Power Interface) Support"
>> >>       depends on !IA64_HP_SIM
>> >> -     depends on IA64 || X86 || (ARM64 && EXPERT)
>> >> +     depends on IA64 || X86 || ARM64
>> >>       depends on PCI
>> >>       select PNP
>> >>       default y
>>
>> OK
>>
>> What do the ARM64 maintainers think?
>
> I'm unsure about whether or not we want 'default y' here, but I'd like
> to wait for Catalin to come back from his 2-week holiday before going
> anywhere with this patch.

Ack to that, but ...

> It's only fair that his opinion should be
> taken into account, and there's not a huge rush for this. I do consider
> "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
> any significant AML code) and therefore don't view this as a blocking
> issue.
>

... this patch will only affect those systems. DT-based systems, even
if they provide an ACPI description as well, will not invoke the ACPI
code unless you go out of your way to either boot without a DT or pass
'acpi=force' on the command line. On the other hand, it will make
generic kernels (defconfig, etc) bootable on ACPI only systems, which
currently require special kernel builds. Another important reason for
this change is to get more build testing coverage for the arm64 ACPI
code that we had so much fuss about, e.g, by the kbuild test robot.

> We should also take into account the large amount of ongoing ACPI work
> (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
> etc), and decide whether or not that's currently in a state where we want
> to encourage people to start using this in their arm64 kernels.
>

The question is not about using it, the question is about
incorporating it into the default build. The runtime opt-in is not
going away with this patch.

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Will Deacon]

On Thu, Mar 31, 2016 at 03:20:03PM +0200, Ard Biesheuvel wrote:
> On 31 March 2016 at 14:36, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote:
> >> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
> >> > On 2016/3/31 1:58, Mark Brown wrote:
> >> >> When ACPI was originally merged for arm64 it had only been tested on
> >> >> emulators and not on real physical platforms and no platforms were
> >> >> relying on it.  This meant that there were concerns that there might be
> >> >> serious issues attempting to use it on practical systems so it had a
> >> >> dependency on EXPERT added to warn people that it was in an early stage
> >> >> of development with very little practical testing.  Since then things
> >> >> have moved on a bit.  We have seen people testing on real hardware and
> >> >> now have people starting to produce some platforms (the most prominent
> >> >> being the 96boards Cello) which only have ACPI support and which build
> >> >> and run to some useful extent with mainline.
> >> >>
> >> >> This is not to say that ACPI support or support for these systems is
> >> >> completely done, there are still areas being worked on such as PCI, but
> >> >> at this point it seems that we can be reasonably sure that ACPI will be
> >> >> viable for use on ARM64 and that the already merged support works for
> >> >> the cases it handles.  For the AMD Seattle based platforms support
> >> >> outside of PCI has been fairly complete in mainline a few releases now.
> >> >>
> >> >> This is also not to say that we don't have vendors working with ACPI who
> >> >> are trying do things that we would not consider optimal but it does not
> >> >> appear that the EXPERT dependency is having a substantial impact on
> >> >> these vendors.
> >> >>
> >> >> Given all this it seems that at this point the EXPERT dependency mainly
> >> >> creates inconvenience for users with systems that are doing the right
> >> >> thing and gets in the way of including the ACPI code in the testing that
> >> >> people are doing on mainline.  Removing it should help our ongoing
> >> >> testing cover those platforms with only ACPI support and help ensure
> >> >> that when ACPI code is merged any problems it causes for other users are
> >> >> more easily discovered.
> >> >>
> >> >> Signed-off-by: Mark Brown <broonie@kernel.org>
> >> >
> >> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> >
> >> >> ---
> >> >>  drivers/acpi/Kconfig | 2 +-
> >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> >> >> index 82b96ee8624c..bf5dc1ac3446 100644
> >> >> --- a/drivers/acpi/Kconfig
> >> >> +++ b/drivers/acpi/Kconfig
> >> >> @@ -5,7 +5,7 @@
> >> >>  menuconfig ACPI
> >> >>       bool "ACPI (Advanced Configuration and Power Interface) Support"
> >> >>       depends on !IA64_HP_SIM
> >> >> -     depends on IA64 || X86 || (ARM64 && EXPERT)
> >> >> +     depends on IA64 || X86 || ARM64
> >> >>       depends on PCI
> >> >>       select PNP
> >> >>       default y
> >>
> >> OK
> >>
> >> What do the ARM64 maintainers think?
> >
> > I'm unsure about whether or not we want 'default y' here, but I'd like
> > to wait for Catalin to come back from his 2-week holiday before going
> > anywhere with this patch.
> 
> Ack to that, but ...
> 
> > It's only fair that his opinion should be
> > taken into account, and there's not a huge rush for this. I do consider
> > "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
> > any significant AML code) and therefore don't view this as a blocking
> > issue.
> >
> 
> ... this patch will only affect those systems. DT-based systems, even
> if they provide an ACPI description as well, will not invoke the ACPI
> code unless you go out of your way to either boot without a DT or pass
> 'acpi=force' on the command line. On the other hand, it will make
> generic kernels (defconfig, etc) bootable on ACPI only systems, which
> currently require special kernel builds. Another important reason for
> this change is to get more build testing coverage for the arm64 ACPI
> code that we had so much fuss about, e.g, by the kbuild test robot.

I'd really like to get away from the concept of ACPI-only systems. Would
we reject a .dtb contribution for such a machine?

> > We should also take into account the large amount of ongoing ACPI work
> > (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
> > etc), and decide whether or not that's currently in a state where we want
> > to encourage people to start using this in their arm64 kernels.
> >
> 
> The question is not about using it, the question is about
> incorporating it into the default build. The runtime opt-in is not
> going away with this patch.

I understand that, but I still think that removing the dependency on
EXPERT is indicative of saying "this stuff is good to be used by the
masses", irrespective of a cmdline option. Maybe that's true, but it's
not immediately obvious to me, with all the patches in flight.

Will

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Will Deacon]

On Thu, Mar 31, 2016 at 03:20:03PM +0200, Ard Biesheuvel wrote:
> On 31 March 2016 at 14:36, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote:
> >> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
> >> > On 2016/3/31 1:58, Mark Brown wrote:
> >> >> When ACPI was originally merged for arm64 it had only been tested on
> >> >> emulators and not on real physical platforms and no platforms were
> >> >> relying on it.  This meant that there were concerns that there might be
> >> >> serious issues attempting to use it on practical systems so it had a
> >> >> dependency on EXPERT added to warn people that it was in an early stage
> >> >> of development with very little practical testing.  Since then things
> >> >> have moved on a bit.  We have seen people testing on real hardware and
> >> >> now have people starting to produce some platforms (the most prominent
> >> >> being the 96boards Cello) which only have ACPI support and which build
> >> >> and run to some useful extent with mainline.
> >> >>
> >> >> This is not to say that ACPI support or support for these systems is
> >> >> completely done, there are still areas being worked on such as PCI, but
> >> >> at this point it seems that we can be reasonably sure that ACPI will be
> >> >> viable for use on ARM64 and that the already merged support works for
> >> >> the cases it handles.  For the AMD Seattle based platforms support
> >> >> outside of PCI has been fairly complete in mainline a few releases now.
> >> >>
> >> >> This is also not to say that we don't have vendors working with ACPI who
> >> >> are trying do things that we would not consider optimal but it does not
> >> >> appear that the EXPERT dependency is having a substantial impact on
> >> >> these vendors.
> >> >>
> >> >> Given all this it seems that at this point the EXPERT dependency mainly
> >> >> creates inconvenience for users with systems that are doing the right
> >> >> thing and gets in the way of including the ACPI code in the testing that
> >> >> people are doing on mainline.  Removing it should help our ongoing
> >> >> testing cover those platforms with only ACPI support and help ensure
> >> >> that when ACPI code is merged any problems it causes for other users are
> >> >> more easily discovered.
> >> >>
> >> >> Signed-off-by: Mark Brown <broonie@kernel.org>
> >> >
> >> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> >
> >> >> ---
> >> >>  drivers/acpi/Kconfig | 2 +-
> >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> >> >> index 82b96ee8624c..bf5dc1ac3446 100644
> >> >> --- a/drivers/acpi/Kconfig
> >> >> +++ b/drivers/acpi/Kconfig
> >> >> @@ -5,7 +5,7 @@
> >> >>  menuconfig ACPI
> >> >>       bool "ACPI (Advanced Configuration and Power Interface) Support"
> >> >>       depends on !IA64_HP_SIM
> >> >> -     depends on IA64 || X86 || (ARM64 && EXPERT)
> >> >> +     depends on IA64 || X86 || ARM64
> >> >>       depends on PCI
> >> >>       select PNP
> >> >>       default y
> >>
> >> OK
> >>
> >> What do the ARM64 maintainers think?
> >
> > I'm unsure about whether or not we want 'default y' here, but I'd like
> > to wait for Catalin to come back from his 2-week holiday before going
> > anywhere with this patch.
> 
> Ack to that, but ...
> 
> > It's only fair that his opinion should be
> > taken into account, and there's not a huge rush for this. I do consider
> > "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
> > any significant AML code) and therefore don't view this as a blocking
> > issue.
> >
> 
> ... this patch will only affect those systems. DT-based systems, even
> if they provide an ACPI description as well, will not invoke the ACPI
> code unless you go out of your way to either boot without a DT or pass
> 'acpi=force' on the command line. On the other hand, it will make
> generic kernels (defconfig, etc) bootable on ACPI only systems, which
> currently require special kernel builds. Another important reason for
> this change is to get more build testing coverage for the arm64 ACPI
> code that we had so much fuss about, e.g, by the kbuild test robot.

I'd really like to get away from the concept of ACPI-only systems. Would
we reject a .dtb contribution for such a machine?

> > We should also take into account the large amount of ongoing ACPI work
> > (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
> > etc), and decide whether or not that's currently in a state where we want
> > to encourage people to start using this in their arm64 kernels.
> >
> 
> The question is not about using it, the question is about
> incorporating it into the default build. The runtime opt-in is not
> going away with this patch.

I understand that, but I still think that removing the dependency on
EXPERT is indicative of saying "this stuff is good to be used by the
masses", irrespective of a cmdline option. Maybe that's true, but it's
not immediately obvious to me, with all the patches in flight.

Will

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Ard Biesheuvel]

On 31 March 2016 at 15:38, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Mar 31, 2016 at 03:20:03PM +0200, Ard Biesheuvel wrote:
>> On 31 March 2016 at 14:36, Will Deacon <will.deacon@arm.com> wrote:
>> > On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote:
>> >> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
>> >> > On 2016/3/31 1:58, Mark Brown wrote:
>> >> >> When ACPI was originally merged for arm64 it had only been tested on
>> >> >> emulators and not on real physical platforms and no platforms were
>> >> >> relying on it.  This meant that there were concerns that there might be
>> >> >> serious issues attempting to use it on practical systems so it had a
>> >> >> dependency on EXPERT added to warn people that it was in an early stage
>> >> >> of development with very little practical testing.  Since then things
>> >> >> have moved on a bit.  We have seen people testing on real hardware and
>> >> >> now have people starting to produce some platforms (the most prominent
>> >> >> being the 96boards Cello) which only have ACPI support and which build
>> >> >> and run to some useful extent with mainline.
>> >> >>
>> >> >> This is not to say that ACPI support or support for these systems is
>> >> >> completely done, there are still areas being worked on such as PCI, but
>> >> >> at this point it seems that we can be reasonably sure that ACPI will be
>> >> >> viable for use on ARM64 and that the already merged support works for
>> >> >> the cases it handles.  For the AMD Seattle based platforms support
>> >> >> outside of PCI has been fairly complete in mainline a few releases now.
>> >> >>
>> >> >> This is also not to say that we don't have vendors working with ACPI who
>> >> >> are trying do things that we would not consider optimal but it does not
>> >> >> appear that the EXPERT dependency is having a substantial impact on
>> >> >> these vendors.
>> >> >>
>> >> >> Given all this it seems that at this point the EXPERT dependency mainly
>> >> >> creates inconvenience for users with systems that are doing the right
>> >> >> thing and gets in the way of including the ACPI code in the testing that
>> >> >> people are doing on mainline.  Removing it should help our ongoing
>> >> >> testing cover those platforms with only ACPI support and help ensure
>> >> >> that when ACPI code is merged any problems it causes for other users are
>> >> >> more easily discovered.
>> >> >>
>> >> >> Signed-off-by: Mark Brown <broonie@kernel.org>
>> >> >
>> >> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>> >> >
>> >> >> ---
>> >> >>  drivers/acpi/Kconfig | 2 +-
>> >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> >> >> index 82b96ee8624c..bf5dc1ac3446 100644
>> >> >> --- a/drivers/acpi/Kconfig
>> >> >> +++ b/drivers/acpi/Kconfig
>> >> >> @@ -5,7 +5,7 @@
>> >> >>  menuconfig ACPI
>> >> >>       bool "ACPI (Advanced Configuration and Power Interface) Support"
>> >> >>       depends on !IA64_HP_SIM
>> >> >> -     depends on IA64 || X86 || (ARM64 && EXPERT)
>> >> >> +     depends on IA64 || X86 || ARM64
>> >> >>       depends on PCI
>> >> >>       select PNP
>> >> >>       default y
>> >>
>> >> OK
>> >>
>> >> What do the ARM64 maintainers think?
>> >
>> > I'm unsure about whether or not we want 'default y' here, but I'd like
>> > to wait for Catalin to come back from his 2-week holiday before going
>> > anywhere with this patch.
>>
>> Ack to that, but ...
>>
>> > It's only fair that his opinion should be
>> > taken into account, and there's not a huge rush for this. I do consider
>> > "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
>> > any significant AML code) and therefore don't view this as a blocking
>> > issue.
>> >
>>
>> ... this patch will only affect those systems. DT-based systems, even
>> if they provide an ACPI description as well, will not invoke the ACPI
>> code unless you go out of your way to either boot without a DT or pass
>> 'acpi=force' on the command line. On the other hand, it will make
>> generic kernels (defconfig, etc) bootable on ACPI only systems, which
>> currently require special kernel builds. Another important reason for
>> this change is to get more build testing coverage for the arm64 ACPI
>> code that we had so much fuss about, e.g, by the kbuild test robot.
>
> I'd really like to get away from the concept of ACPI-only systems. Would
> we reject a .dtb contribution for such a machine?
>

Absolutely not, and I expect such contributions will appear sooner
rather than later.

But the point of ACPI is the abstraction, and the ridiculous churn in
DTB's carried in mainline clearly shows the need for that*. So there
will be ACPI-only systems because the drivers are coded against the
abstracted interface, and DT is simply not a drop-in replacement in
that case.

* of course, with the whole DSD debacle and the heterogeneity of the
ARM ecosystem compared to the standardized PC, it remains to be seen
if these systems require firmware upgrades less often than there are
DT changes in the upstream tree, but at least the patches are applied
on the correct [hardware] side in this case.

>> > We should also take into account the large amount of ongoing ACPI work
>> > (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
>> > etc), and decide whether or not that's currently in a state where we want
>> > to encourage people to start using this in their arm64 kernels.
>> >
>>
>> The question is not about using it, the question is about
>> incorporating it into the default build. The runtime opt-in is not
>> going away with this patch.
>
> I understand that, but I still think that removing the dependency on
> EXPERT is indicative of saying "this stuff is good to be used by the
> masses", irrespective of a cmdline option. Maybe that's true, but it's
> not immediately obvious to me, with all the patches in flight.
>

Well, we are not cc'ing to stable, are we? Or do you think the current
stuff is so broken that we should even protect users of the upstream
HEAD branch against it?

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Ard Biesheuvel]

On 31 March 2016 at 15:38, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Mar 31, 2016 at 03:20:03PM +0200, Ard Biesheuvel wrote:
>> On 31 March 2016 at 14:36, Will Deacon <will.deacon@arm.com> wrote:
>> > On Thu, Mar 31, 2016 at 02:04:05PM +0200, Rafael J. Wysocki wrote:
>> >> On Thu, Mar 31, 2016 at 5:44 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
>> >> > On 2016/3/31 1:58, Mark Brown wrote:
>> >> >> When ACPI was originally merged for arm64 it had only been tested on
>> >> >> emulators and not on real physical platforms and no platforms were
>> >> >> relying on it.  This meant that there were concerns that there might be
>> >> >> serious issues attempting to use it on practical systems so it had a
>> >> >> dependency on EXPERT added to warn people that it was in an early stage
>> >> >> of development with very little practical testing.  Since then things
>> >> >> have moved on a bit.  We have seen people testing on real hardware and
>> >> >> now have people starting to produce some platforms (the most prominent
>> >> >> being the 96boards Cello) which only have ACPI support and which build
>> >> >> and run to some useful extent with mainline.
>> >> >>
>> >> >> This is not to say that ACPI support or support for these systems is
>> >> >> completely done, there are still areas being worked on such as PCI, but
>> >> >> at this point it seems that we can be reasonably sure that ACPI will be
>> >> >> viable for use on ARM64 and that the already merged support works for
>> >> >> the cases it handles.  For the AMD Seattle based platforms support
>> >> >> outside of PCI has been fairly complete in mainline a few releases now.
>> >> >>
>> >> >> This is also not to say that we don't have vendors working with ACPI who
>> >> >> are trying do things that we would not consider optimal but it does not
>> >> >> appear that the EXPERT dependency is having a substantial impact on
>> >> >> these vendors.
>> >> >>
>> >> >> Given all this it seems that at this point the EXPERT dependency mainly
>> >> >> creates inconvenience for users with systems that are doing the right
>> >> >> thing and gets in the way of including the ACPI code in the testing that
>> >> >> people are doing on mainline.  Removing it should help our ongoing
>> >> >> testing cover those platforms with only ACPI support and help ensure
>> >> >> that when ACPI code is merged any problems it causes for other users are
>> >> >> more easily discovered.
>> >> >>
>> >> >> Signed-off-by: Mark Brown <broonie@kernel.org>
>> >> >
>> >> > Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>> >> >
>> >> >> ---
>> >> >>  drivers/acpi/Kconfig | 2 +-
>> >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> >> >> index 82b96ee8624c..bf5dc1ac3446 100644
>> >> >> --- a/drivers/acpi/Kconfig
>> >> >> +++ b/drivers/acpi/Kconfig
>> >> >> @@ -5,7 +5,7 @@
>> >> >>  menuconfig ACPI
>> >> >>       bool "ACPI (Advanced Configuration and Power Interface) Support"
>> >> >>       depends on !IA64_HP_SIM
>> >> >> -     depends on IA64 || X86 || (ARM64 && EXPERT)
>> >> >> +     depends on IA64 || X86 || ARM64
>> >> >>       depends on PCI
>> >> >>       select PNP
>> >> >>       default y
>> >>
>> >> OK
>> >>
>> >> What do the ARM64 maintainers think?
>> >
>> > I'm unsure about whether or not we want 'default y' here, but I'd like
>> > to wait for Catalin to come back from his 2-week holiday before going
>> > anywhere with this patch.
>>
>> Ack to that, but ...
>>
>> > It's only fair that his opinion should be
>> > taken into account, and there's not a huge rush for this. I do consider
>> > "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
>> > any significant AML code) and therefore don't view this as a blocking
>> > issue.
>> >
>>
>> ... this patch will only affect those systems. DT-based systems, even
>> if they provide an ACPI description as well, will not invoke the ACPI
>> code unless you go out of your way to either boot without a DT or pass
>> 'acpi=force' on the command line. On the other hand, it will make
>> generic kernels (defconfig, etc) bootable on ACPI only systems, which
>> currently require special kernel builds. Another important reason for
>> this change is to get more build testing coverage for the arm64 ACPI
>> code that we had so much fuss about, e.g, by the kbuild test robot.
>
> I'd really like to get away from the concept of ACPI-only systems. Would
> we reject a .dtb contribution for such a machine?
>

Absolutely not, and I expect such contributions will appear sooner
rather than later.

But the point of ACPI is the abstraction, and the ridiculous churn in
DTB's carried in mainline clearly shows the need for that*. So there
will be ACPI-only systems because the drivers are coded against the
abstracted interface, and DT is simply not a drop-in replacement in
that case.

* of course, with the whole DSD debacle and the heterogeneity of the
ARM ecosystem compared to the standardized PC, it remains to be seen
if these systems require firmware upgrades less often than there are
DT changes in the upstream tree, but at least the patches are applied
on the correct [hardware] side in this case.

>> > We should also take into account the large amount of ongoing ACPI work
>> > (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
>> > etc), and decide whether or not that's currently in a state where we want
>> > to encourage people to start using this in their arm64 kernels.
>> >
>>
>> The question is not about using it, the question is about
>> incorporating it into the default build. The runtime opt-in is not
>> going away with this patch.
>
> I understand that, but I still think that removing the dependency on
> EXPERT is indicative of saying "this stuff is good to be used by the
> masses", irrespective of a cmdline option. Maybe that's true, but it's
> not immediately obvious to me, with all the patches in flight.
>

Well, we are not cc'ing to stable, are we? Or do you think the current
stuff is so broken that we should even protect users of the upstream
HEAD branch against it?

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

On Thu, Mar 31, 2016 at 01:36:50PM +0100, Will Deacon wrote:

> I'm unsure about whether or not we want 'default y' here, but I'd like

I can easily do followup patches which change that to be "default y if
!ARM64" (or default y if $OTHER_ARCHES) and adding CONFIG_ACPI to
defconfig (for the test coverage) if that helps?  I think that's
perfectly reasonable.  As Ard says if both DT and ACPI are built in then
the kernel will continue to prefer DT if it finds one.

> to wait for Catalin to come back from his 2-week holiday before going
> anywhere with this patch. It's only fair that his opinion should be
> taken into account, and there's not a huge rush for this. I do consider

It definitely makes sense to get Catalin's input.  I do think that this
is something we don't want to defer indefinitely though, I think we're
hurting ourselves more than we're helping.

> "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
> any significant AML code) and therefore don't view this as a blocking
> issue.

I think people with a system with no DT provided might disagree on that
one, and that this isn't really about end users or even distros but
rather about the people working upstream and especially doing test and
QA work upstream.

> We should also take into account the large amount of ongoing ACPI work
> (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
> etc), and decide whether or not that's currently in a state where we want
> to encourage people to start using this in their arm64 kernels.

My perception is that the EXPERT dependency is not having a meaningful
impact on people who want to use ACPI, they're just going ahead and
doing it anyway and expecting that distros will ship kernels which
enable ACPI (which realistically the ones that don't currently are going
to do as they start encountering these platforms).  There doesn't seem
to be much sign that decisions about shipping systems are being guided
by this and the work that's happening on ACPI is going on regardless,
some of it x86 focused.

The kernel will still continue to prefer DT on arm64 systems so it's
still the default upstream.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

On Thu, Mar 31, 2016 at 01:36:50PM +0100, Will Deacon wrote:

> I'm unsure about whether or not we want 'default y' here, but I'd like

I can easily do followup patches which change that to be "default y if
!ARM64" (or default y if $OTHER_ARCHES) and adding CONFIG_ACPI to
defconfig (for the test coverage) if that helps?  I think that's
perfectly reasonable.  As Ard says if both DT and ACPI are built in then
the kernel will continue to prefer DT if it finds one.

> to wait for Catalin to come back from his 2-week holiday before going
> anywhere with this patch. It's only fair that his opinion should be
> taken into account, and there's not a huge rush for this. I do consider

It definitely makes sense to get Catalin's input.  I do think that this
is something we don't want to defer indefinitely though, I think we're
hurting ourselves more than we're helping.

> "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
> any significant AML code) and therefore don't view this as a blocking
> issue.

I think people with a system with no DT provided might disagree on that
one, and that this isn't really about end users or even distros but
rather about the people working upstream and especially doing test and
QA work upstream.

> We should also take into account the large amount of ongoing ACPI work
> (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
> etc), and decide whether or not that's currently in a state where we want
> to encourage people to start using this in their arm64 kernels.

My perception is that the EXPERT dependency is not having a meaningful
impact on people who want to use ACPI, they're just going ahead and
doing it anyway and expecting that distros will ship kernels which
enable ACPI (which realistically the ones that don't currently are going
to do as they start encountering these platforms).  There doesn't seem
to be much sign that decisions about shipping systems are being guided
by this and the work that's happening on ACPI is going on regardless,
some of it x86 focused.

The kernel will still continue to prefer DT on arm64 systems so it's
still the default upstream.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160331/b5cf37c5/attachment.sig>

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

On Thu, Mar 31, 2016 at 04:48:44PM +0200, Ard Biesheuvel wrote:
> On 31 March 2016 at 15:38, Will Deacon <will.deacon@arm.com> wrote:

> > I'd really like to get away from the concept of ACPI-only systems. Would
> > we reject a .dtb contribution for such a machine?

> Absolutely not, and I expect such contributions will appear sooner
> rather than later.

> But the point of ACPI is the abstraction, and the ridiculous churn in
> DTB's carried in mainline clearly shows the need for that*. So there
> will be ACPI-only systems because the drivers are coded against the
> abstracted interface, and DT is simply not a drop-in replacement in
> that case.

It's also worth remembering that just because we have a DT in tree that
doesn't mean that people running actual systems are going to use it.
For some systems there will be a user community that wants to do that
but that won't be universal, there are going to be people who just use
the default firmware.

> > I understand that, but I still think that removing the dependency on
> > EXPERT is indicative of saying "this stuff is good to be used by the
> > masses", irrespective of a cmdline option. Maybe that's true, but it's
> > not immediately obvious to me, with all the patches in flight.

> Well, we are not cc'ing to stable, are we? Or do you think the current
> stuff is so broken that we should even protect users of the upstream
> HEAD branch against it?

Like I said in the other mail I'm also just not sure that this is
something that people deciding what firmware to ship on their systems
are paying much attention to.  People are coming to their own assessment
based on their own testing and other factors.  Where I see this having
an impact is more on having the rest of the upstream community keeping
an eye on what the ACPI people are doing.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

On Thu, Mar 31, 2016 at 04:48:44PM +0200, Ard Biesheuvel wrote:
> On 31 March 2016 at 15:38, Will Deacon <will.deacon@arm.com> wrote:

> > I'd really like to get away from the concept of ACPI-only systems. Would
> > we reject a .dtb contribution for such a machine?

> Absolutely not, and I expect such contributions will appear sooner
> rather than later.

> But the point of ACPI is the abstraction, and the ridiculous churn in
> DTB's carried in mainline clearly shows the need for that*. So there
> will be ACPI-only systems because the drivers are coded against the
> abstracted interface, and DT is simply not a drop-in replacement in
> that case.

It's also worth remembering that just because we have a DT in tree that
doesn't mean that people running actual systems are going to use it.
For some systems there will be a user community that wants to do that
but that won't be universal, there are going to be people who just use
the default firmware.

> > I understand that, but I still think that removing the dependency on
> > EXPERT is indicative of saying "this stuff is good to be used by the
> > masses", irrespective of a cmdline option. Maybe that's true, but it's
> > not immediately obvious to me, with all the patches in flight.

> Well, we are not cc'ing to stable, are we? Or do you think the current
> stuff is so broken that we should even protect users of the upstream
> HEAD branch against it?

Like I said in the other mail I'm also just not sure that this is
something that people deciding what firmware to ship on their systems
are paying much attention to.  People are coming to their own assessment
based on their own testing and other factors.  Where I see this having
an impact is more on having the rest of the upstream community keeping
an eye on what the ACPI people are doing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160331/01725641/attachment.sig>

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Catalin Marinas]

On Wed, Mar 30, 2016 at 10:58:38AM -0700, Mark Brown wrote:
> When ACPI was originally merged for arm64 it had only been tested on
> emulators and not on real physical platforms and no platforms were
> relying on it.  This meant that there were concerns that there might be
> serious issues attempting to use it on practical systems so it had a
> dependency on EXPERT added to warn people that it was in an early stage
> of development with very little practical testing.  Since then things
> have moved on a bit.  We have seen people testing on real hardware and
> now have people starting to produce some platforms (the most prominent
> being the 96boards Cello) which only have ACPI support and which build
> and run to some useful extent with mainline.
> 
> This is not to say that ACPI support or support for these systems is
> completely done, there are still areas being worked on such as PCI, but
> at this point it seems that we can be reasonably sure that ACPI will be
> viable for use on ARM64 and that the already merged support works for
> the cases it handles.  For the AMD Seattle based platforms support
> outside of PCI has been fairly complete in mainline a few releases now.
> 
> This is also not to say that we don't have vendors working with ACPI who
> are trying do things that we would not consider optimal but it does not
> appear that the EXPERT dependency is having a substantial impact on
> these vendors.
> 
> Given all this it seems that at this point the EXPERT dependency mainly
> creates inconvenience for users with systems that are doing the right
> thing and gets in the way of including the ACPI code in the testing that
> people are doing on mainline.  Removing it should help our ongoing
> testing cover those platforms with only ACPI support and help ensure
> that when ACPI code is merged any problems it causes for other users are
> more easily discovered.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>

I'm fine with dropping the EXPERT dependency (of course, not a cc
stable). While arm64 ACPI is not "done" yet (nor is DT; there are
important ongoing developments like PCIe, IORT), I think the core arm64
ACPI support passed the EXPERT stage. I also don't think a default y
would imply any maintainer endorsement; vendors targeting ACPI are
already doing this for various reasons (distro requirement, certain ACPI
features like RAS). But, hopefully, it will encourage more vendors to
start upstreaming their ACPI-related patches.

However, building ACPI by default on arm64 doesn't mean that we can
ignore potential misuses like PRP0001+_DSD blindly following DT
(mis)concepts, breaking compatibility with older/newer firmware (this
goes in both directions) or using ACPI for SoCs where it is clearly not
suitable (e.g. non-SBSA). Such patches should be NAK'ed accordingly.

> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee8624c..bf5dc1ac3446 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,7 +5,7 @@
>  menuconfig ACPI
>  	bool "ACPI (Advanced Configuration and Power Interface) Support"
>  	depends on !IA64_HP_SIM
> -	depends on IA64 || X86 || (ARM64 && EXPERT)
> +	depends on IA64 || X86 || ARM64
>  	depends on PCI
>  	select PNP
>  	default y

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

That said, I'd like to see an opinion from the arm-soc maintainers since
they were active on the original arm64 ACPI threads introducing this
dependency (and I think they have the right to veto ;)).

-- 
Catalin

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Catalin Marinas]

On Wed, Mar 30, 2016 at 10:58:38AM -0700, Mark Brown wrote:
> When ACPI was originally merged for arm64 it had only been tested on
> emulators and not on real physical platforms and no platforms were
> relying on it.  This meant that there were concerns that there might be
> serious issues attempting to use it on practical systems so it had a
> dependency on EXPERT added to warn people that it was in an early stage
> of development with very little practical testing.  Since then things
> have moved on a bit.  We have seen people testing on real hardware and
> now have people starting to produce some platforms (the most prominent
> being the 96boards Cello) which only have ACPI support and which build
> and run to some useful extent with mainline.
> 
> This is not to say that ACPI support or support for these systems is
> completely done, there are still areas being worked on such as PCI, but
> at this point it seems that we can be reasonably sure that ACPI will be
> viable for use on ARM64 and that the already merged support works for
> the cases it handles.  For the AMD Seattle based platforms support
> outside of PCI has been fairly complete in mainline a few releases now.
> 
> This is also not to say that we don't have vendors working with ACPI who
> are trying do things that we would not consider optimal but it does not
> appear that the EXPERT dependency is having a substantial impact on
> these vendors.
> 
> Given all this it seems that at this point the EXPERT dependency mainly
> creates inconvenience for users with systems that are doing the right
> thing and gets in the way of including the ACPI code in the testing that
> people are doing on mainline.  Removing it should help our ongoing
> testing cover those platforms with only ACPI support and help ensure
> that when ACPI code is merged any problems it causes for other users are
> more easily discovered.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>

I'm fine with dropping the EXPERT dependency (of course, not a cc
stable). While arm64 ACPI is not "done" yet (nor is DT; there are
important ongoing developments like PCIe, IORT), I think the core arm64
ACPI support passed the EXPERT stage. I also don't think a default y
would imply any maintainer endorsement; vendors targeting ACPI are
already doing this for various reasons (distro requirement, certain ACPI
features like RAS). But, hopefully, it will encourage more vendors to
start upstreaming their ACPI-related patches.

However, building ACPI by default on arm64 doesn't mean that we can
ignore potential misuses like PRP0001+_DSD blindly following DT
(mis)concepts, breaking compatibility with older/newer firmware (this
goes in both directions) or using ACPI for SoCs where it is clearly not
suitable (e.g. non-SBSA). Such patches should be NAK'ed accordingly.

> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee8624c..bf5dc1ac3446 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,7 +5,7 @@
>  menuconfig ACPI
>  	bool "ACPI (Advanced Configuration and Power Interface) Support"
>  	depends on !IA64_HP_SIM
> -	depends on IA64 || X86 || (ARM64 && EXPERT)
> +	depends on IA64 || X86 || ARM64
>  	depends on PCI
>  	select PNP
>  	default y

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

That said, I'd like to see an opinion from the arm-soc maintainers since
they were active on the original arm64 ACPI threads introducing this
dependency (and I think they have the right to veto ;)).

-- 
Catalin

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

On Tue, Apr 12, 2016 at 06:23:15PM +0100, Catalin Marinas wrote:

> I'm fine with dropping the EXPERT dependency (of course, not a cc
> stable). While arm64 ACPI is not "done" yet (nor is DT; there are
> important ongoing developments like PCIe, IORT), I think the core arm64
> ACPI support passed the EXPERT stage. I also don't think a default y
> would imply any maintainer endorsement; vendors targeting ACPI are
> already doing this for various reasons (distro requirement, certain ACPI

So you're OK with the current patch?

> features like RAS). But, hopefully, it will encourage more vendors to
> start upstreaming their ACPI-related patches.

Yes, and also help include ACPI systems in the work we're doing testing
things upstream.

> However, building ACPI by default on arm64 doesn't mean that we can
> ignore potential misuses like PRP0001+_DSD blindly following DT
> (mis)concepts, breaking compatibility with older/newer firmware (this
> goes in both directions) or using ACPI for SoCs where it is clearly not
> suitable (e.g. non-SBSA). Such patches should be NAK'ed accordingly.

Yes, I'm very concerned about some of the activity I'm seeing there
myself - it does seem likely that we're going to have to extend ACPI for
arm64 SoCs simply because things like SBSA are so bare bones but we need
to pay attention to what's going on there to promote best practices and
try to get people producing firmwares that make well thought through
decisions regarding their ACPI usage.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

On Tue, Apr 12, 2016 at 06:23:15PM +0100, Catalin Marinas wrote:

> I'm fine with dropping the EXPERT dependency (of course, not a cc
> stable). While arm64 ACPI is not "done" yet (nor is DT; there are
> important ongoing developments like PCIe, IORT), I think the core arm64
> ACPI support passed the EXPERT stage. I also don't think a default y
> would imply any maintainer endorsement; vendors targeting ACPI are
> already doing this for various reasons (distro requirement, certain ACPI

So you're OK with the current patch?

> features like RAS). But, hopefully, it will encourage more vendors to
> start upstreaming their ACPI-related patches.

Yes, and also help include ACPI systems in the work we're doing testing
things upstream.

> However, building ACPI by default on arm64 doesn't mean that we can
> ignore potential misuses like PRP0001+_DSD blindly following DT
> (mis)concepts, breaking compatibility with older/newer firmware (this
> goes in both directions) or using ACPI for SoCs where it is clearly not
> suitable (e.g. non-SBSA). Such patches should be NAK'ed accordingly.

Yes, I'm very concerned about some of the activity I'm seeing there
myself - it does seem likely that we're going to have to extend ACPI for
arm64 SoCs simply because things like SBSA are so bare bones but we need
to pay attention to what's going on there to promote best practices and
try to get people producing firmwares that make well thought through
decisions regarding their ACPI usage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160413/cd774a02/attachment.sig>

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Catalin Marinas]

On Wed, Apr 13, 2016 at 06:25:53AM +0100, Mark Brown wrote:
> On Tue, Apr 12, 2016 at 06:23:15PM +0100, Catalin Marinas wrote:
> > I'm fine with dropping the EXPERT dependency (of course, not a cc
> > stable). While arm64 ACPI is not "done" yet (nor is DT; there are
> > important ongoing developments like PCIe, IORT), I think the core arm64
> > ACPI support passed the EXPERT stage. I also don't think a default y
> > would imply any maintainer endorsement; vendors targeting ACPI are
> > already doing this for various reasons (distro requirement, certain ACPI
> 
> So you're OK with the current patch?

Yes, I posted an ack in the previous reply (with a note that Will and
the arm-soc maintainers still have a right to veto this change).

-- 
Catalin

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Catalin Marinas]

On Wed, Apr 13, 2016 at 06:25:53AM +0100, Mark Brown wrote:
> On Tue, Apr 12, 2016 at 06:23:15PM +0100, Catalin Marinas wrote:
> > I'm fine with dropping the EXPERT dependency (of course, not a cc
> > stable). While arm64 ACPI is not "done" yet (nor is DT; there are
> > important ongoing developments like PCIe, IORT), I think the core arm64
> > ACPI support passed the EXPERT stage. I also don't think a default y
> > would imply any maintainer endorsement; vendors targeting ACPI are
> > already doing this for various reasons (distro requirement, certain ACPI
> 
> So you're OK with the current patch?

Yes, I posted an ack in the previous reply (with a note that Will and
the arm-soc maintainers still have a right to veto this change).

-- 
Catalin

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

On Wed, Apr 13, 2016 at 09:51:39AM +0100, Catalin Marinas wrote:
> On Wed, Apr 13, 2016 at 06:25:53AM +0100, Mark Brown wrote:

> > So you're OK with the current patch?

> Yes, I posted an ack in the previous reply (with a note that Will and
> the arm-soc maintainers still have a right to veto this change).

Oh, sorry - I missed that somehow.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

On Wed, Apr 13, 2016 at 09:51:39AM +0100, Catalin Marinas wrote:
> On Wed, Apr 13, 2016 at 06:25:53AM +0100, Mark Brown wrote:

> > So you're OK with the current patch?

> Yes, I posted an ack in the previous reply (with a note that Will and
> the arm-soc maintainers still have a right to veto this change).

Oh, sorry - I missed that somehow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160413/0ab7cd83/attachment.sig>

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Olof Johansson]

On Tue, Apr 12, 2016 at 10:23 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Wed, Mar 30, 2016 at 10:58:38AM -0700, Mark Brown wrote:
>> When ACPI was originally merged for arm64 it had only been tested on
>> emulators and not on real physical platforms and no platforms were
>> relying on it.  This meant that there were concerns that there might be
>> serious issues attempting to use it on practical systems so it had a
>> dependency on EXPERT added to warn people that it was in an early stage
>> of development with very little practical testing.  Since then things
>> have moved on a bit.  We have seen people testing on real hardware and
>> now have people starting to produce some platforms (the most prominent
>> being the 96boards Cello) which only have ACPI support and which build
>> and run to some useful extent with mainline.
>>
>> This is not to say that ACPI support or support for these systems is
>> completely done, there are still areas being worked on such as PCI, but
>> at this point it seems that we can be reasonably sure that ACPI will be
>> viable for use on ARM64 and that the already merged support works for
>> the cases it handles.  For the AMD Seattle based platforms support
>> outside of PCI has been fairly complete in mainline a few releases now.
>>
>> This is also not to say that we don't have vendors working with ACPI who
>> are trying do things that we would not consider optimal but it does not
>> appear that the EXPERT dependency is having a substantial impact on
>> these vendors.
>>
>> Given all this it seems that at this point the EXPERT dependency mainly
>> creates inconvenience for users with systems that are doing the right
>> thing and gets in the way of including the ACPI code in the testing that
>> people are doing on mainline.  Removing it should help our ongoing
>> testing cover those platforms with only ACPI support and help ensure
>> that when ACPI code is merged any problems it causes for other users are
>> more easily discovered.
>>
>> Signed-off-by: Mark Brown <broonie@kernel.org>
>
> I'm fine with dropping the EXPERT dependency (of course, not a cc
> stable). While arm64 ACPI is not "done" yet (nor is DT; there are
> important ongoing developments like PCIe, IORT), I think the core arm64
> ACPI support passed the EXPERT stage. I also don't think a default y
> would imply any maintainer endorsement; vendors targeting ACPI are
> already doing this for various reasons (distro requirement, certain ACPI
> features like RAS). But, hopefully, it will encourage more vendors to
> start upstreaming their ACPI-related patches.
>
> However, building ACPI by default on arm64 doesn't mean that we can
> ignore potential misuses like PRP0001+_DSD blindly following DT
> (mis)concepts, breaking compatibility with older/newer firmware (this
> goes in both directions) or using ACPI for SoCs where it is clearly not
> suitable (e.g. non-SBSA). Such patches should be NAK'ed accordingly.
>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 82b96ee8624c..bf5dc1ac3446 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -5,7 +5,7 @@
>>  menuconfig ACPI
>>       bool "ACPI (Advanced Configuration and Power Interface) Support"
>>       depends on !IA64_HP_SIM
>> -     depends on IA64 || X86 || (ARM64 && EXPERT)
>> +     depends on IA64 || X86 || ARM64
>>       depends on PCI
>>       select PNP
>>       default y
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> That said, I'd like to see an opinion from the arm-soc maintainers since
> they were active on the original arm64 ACPI threads introducing this
> dependency (and I think they have the right to veto ;)).

Switch the default from y to n on ARM64 (or default !ARM64) and I'll
be happy to ack it.

Mostly because it doesn't make sense for people building their own
configs for embedded systems to get it turned on by default. Anyone
running on a server is likely to clone an existing distro config in
the first place.


-Olof

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Olof Johansson]

On Tue, Apr 12, 2016 at 10:23 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Wed, Mar 30, 2016 at 10:58:38AM -0700, Mark Brown wrote:
>> When ACPI was originally merged for arm64 it had only been tested on
>> emulators and not on real physical platforms and no platforms were
>> relying on it.  This meant that there were concerns that there might be
>> serious issues attempting to use it on practical systems so it had a
>> dependency on EXPERT added to warn people that it was in an early stage
>> of development with very little practical testing.  Since then things
>> have moved on a bit.  We have seen people testing on real hardware and
>> now have people starting to produce some platforms (the most prominent
>> being the 96boards Cello) which only have ACPI support and which build
>> and run to some useful extent with mainline.
>>
>> This is not to say that ACPI support or support for these systems is
>> completely done, there are still areas being worked on such as PCI, but
>> at this point it seems that we can be reasonably sure that ACPI will be
>> viable for use on ARM64 and that the already merged support works for
>> the cases it handles.  For the AMD Seattle based platforms support
>> outside of PCI has been fairly complete in mainline a few releases now.
>>
>> This is also not to say that we don't have vendors working with ACPI who
>> are trying do things that we would not consider optimal but it does not
>> appear that the EXPERT dependency is having a substantial impact on
>> these vendors.
>>
>> Given all this it seems that at this point the EXPERT dependency mainly
>> creates inconvenience for users with systems that are doing the right
>> thing and gets in the way of including the ACPI code in the testing that
>> people are doing on mainline.  Removing it should help our ongoing
>> testing cover those platforms with only ACPI support and help ensure
>> that when ACPI code is merged any problems it causes for other users are
>> more easily discovered.
>>
>> Signed-off-by: Mark Brown <broonie@kernel.org>
>
> I'm fine with dropping the EXPERT dependency (of course, not a cc
> stable). While arm64 ACPI is not "done" yet (nor is DT; there are
> important ongoing developments like PCIe, IORT), I think the core arm64
> ACPI support passed the EXPERT stage. I also don't think a default y
> would imply any maintainer endorsement; vendors targeting ACPI are
> already doing this for various reasons (distro requirement, certain ACPI
> features like RAS). But, hopefully, it will encourage more vendors to
> start upstreaming their ACPI-related patches.
>
> However, building ACPI by default on arm64 doesn't mean that we can
> ignore potential misuses like PRP0001+_DSD blindly following DT
> (mis)concepts, breaking compatibility with older/newer firmware (this
> goes in both directions) or using ACPI for SoCs where it is clearly not
> suitable (e.g. non-SBSA). Such patches should be NAK'ed accordingly.
>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 82b96ee8624c..bf5dc1ac3446 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -5,7 +5,7 @@
>>  menuconfig ACPI
>>       bool "ACPI (Advanced Configuration and Power Interface) Support"
>>       depends on !IA64_HP_SIM
>> -     depends on IA64 || X86 || (ARM64 && EXPERT)
>> +     depends on IA64 || X86 || ARM64
>>       depends on PCI
>>       select PNP
>>       default y
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> That said, I'd like to see an opinion from the arm-soc maintainers since
> they were active on the original arm64 ACPI threads introducing this
> dependency (and I think they have the right to veto ;)).

Switch the default from y to n on ARM64 (or default !ARM64) and I'll
be happy to ack it.

Mostly because it doesn't make sense for people building their own
configs for embedded systems to get it turned on by default. Anyone
running on a server is likely to clone an existing distro config in
the first place.


-Olof

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Thu, Apr 14, 2016 at 11:02:15AM -0700, Olof Johansson wrote:

> Switch the default from y to n on ARM64 (or default !ARM64) and I'll
> be happy to ack it.

> Mostly because it doesn't make sense for people building their own
> configs for embedded systems to get it turned on by default. Anyone
> running on a server is likely to clone an existing distro config in
> the first place.

I can send a followup patch for that (I actually already wrote that
after the discussion with Will), but I do think we should enable it in
defconfig for the testing.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

On Thu, Apr 14, 2016 at 11:02:15AM -0700, Olof Johansson wrote:

> Switch the default from y to n on ARM64 (or default !ARM64) and I'll
> be happy to ack it.

> Mostly because it doesn't make sense for people building their own
> configs for embedded systems to get it turned on by default. Anyone
> running on a server is likely to clone an existing distro config in
> the first place.

I can send a followup patch for that (I actually already wrote that
after the discussion with Will), but I do think we should enable it in
defconfig for the testing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160414/d74b8087/attachment.sig>

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Olof Johansson]

On Thu, Apr 14, 2016 at 11:25 AM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Apr 14, 2016 at 11:02:15AM -0700, Olof Johansson wrote:
>
>> Switch the default from y to n on ARM64 (or default !ARM64) and I'll
>> be happy to ack it.
>
>> Mostly because it doesn't make sense for people building their own
>> configs for embedded systems to get it turned on by default. Anyone
>> running on a server is likely to clone an existing distro config in
>> the first place.
>
> I can send a followup patch for that (I actually already wrote that
> after the discussion with Will), but I do think we should enable it in
> defconfig for the testing.

That sounds good.

So, to clarify: a follow-up patch (to arm@kernel.org) to turn on ACPI
in arm64 defconfig, and a respin of this patch to change the default.


-Olof

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Olof Johansson]

On Thu, Apr 14, 2016 at 11:25 AM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Apr 14, 2016 at 11:02:15AM -0700, Olof Johansson wrote:
>
>> Switch the default from y to n on ARM64 (or default !ARM64) and I'll
>> be happy to ack it.
>
>> Mostly because it doesn't make sense for people building their own
>> configs for embedded systems to get it turned on by default. Anyone
>> running on a server is likely to clone an existing distro config in
>> the first place.
>
> I can send a followup patch for that (I actually already wrote that
> after the discussion with Will), but I do think we should enable it in
> defconfig for the testing.

That sounds good.

So, to clarify: a follow-up patch (to arm at kernel.org) to turn on ACPI
in arm64 defconfig, and a respin of this patch to change the default.


-Olof

Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On Thu, Apr 14, 2016 at 11:49:11AM -0700, Olof Johansson wrote:

> So, to clarify: a follow-up patch (to arm@kernel.org) to turn on ACPI
> in arm64 defconfig, and a respin of this patch to change the default.

Yes.  Well, I actually had and additional patch to change the default to
be y only for x86 and IA-64 separately to this one remove the EXPERT
dependency but that's just bikeshedding.  Will send tomorrow unless
there's other comments.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown]

On Thu, Apr 14, 2016 at 11:49:11AM -0700, Olof Johansson wrote:

> So, to clarify: a follow-up patch (to arm at kernel.org) to turn on ACPI
> in arm64 defconfig, and a respin of this patch to change the default.

Yes.  Well, I actually had and additional patch to change the default to
be y only for x86 and IA-64 separately to this one remove the EXPERT
dependency but that's just bikeshedding.  Will send tomorrow unless
there's other comments.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160414/234f4630/attachment.sig>