[PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Sudeep Holla]

Hi,

This tiny series is to enable Platform Runtime Mechanism(PRM) support on
ARM64. Not much changes. Just enabling the build and moving the config
option so that it is not listed under the topmost menu for ARM64.

Regards,
Sudeep

v1[1]->v2:
	- Changed arch_efi_call_virt() to use typeof instead of forced
	  typecasting to void pointer
	- Added change in PRMT driver to move handler_addr type to void
	  pointer

[1] https://lore.kernel.org/linux-acpi/20220624152331.4009502-1-sudeep.holla@arm.com

Sudeep Holla (4):
  ACPI: PRM: Change handler_addr type to void pointer
  arm64: efi: Simplify arch_efi_call_virt() macro by using typeof()
  ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64
  ACPI: Move PRM config option under the main ACPI config

 arch/arm64/include/asm/efi.h |  3 +--
 drivers/acpi/Kconfig         | 30 +++++++++++++++---------------
 drivers/acpi/prmt.c          |  4 ++--
 3 files changed, 18 insertions(+), 19 deletions(-)

--
2.37.0

[PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Sudeep Holla]

Hi,

This tiny series is to enable Platform Runtime Mechanism(PRM) support on
ARM64. Not much changes. Just enabling the build and moving the config
option so that it is not listed under the topmost menu for ARM64.

Regards,
Sudeep

v1[1]->v2:
	- Changed arch_efi_call_virt() to use typeof instead of forced
	  typecasting to void pointer
	- Added change in PRMT driver to move handler_addr type to void
	  pointer

[1] https://lore.kernel.org/linux-acpi/20220624152331.4009502-1-sudeep.holla@arm.com

Sudeep Holla (4):
  ACPI: PRM: Change handler_addr type to void pointer
  arm64: efi: Simplify arch_efi_call_virt() macro by using typeof()
  ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64
  ACPI: Move PRM config option under the main ACPI config

 arch/arm64/include/asm/efi.h |  3 +--
 drivers/acpi/Kconfig         | 30 +++++++++++++++---------------
 drivers/acpi/prmt.c          |  4 ++--
 3 files changed, 18 insertions(+), 19 deletions(-)

--
2.37.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 1/4] ACPI: PRM: Change handler_addr type to void pointer

[Sudeep Holla]

handler_addr is a virtial address passed to efi_call_virt_pointer.
While x86 currently type cast it into the pointer in it's arch specific
arch_efi_call_virt() implementation, ARM64 is restrictive for right
reasons.

Convert the handler_addr type from u64 to void pointer.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/acpi/prmt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/prmt.c b/drivers/acpi/prmt.c
index 4d3a219c67f8..998101cf16e4 100644
--- a/drivers/acpi/prmt.c
+++ b/drivers/acpi/prmt.c
@@ -53,7 +53,7 @@ static LIST_HEAD(prm_module_list);
 
 struct prm_handler_info {
 	guid_t guid;
-	u64 handler_addr;
+	void *handler_addr;
 	u64 static_data_buffer_addr;
 	u64 acpi_param_buffer_addr;
 
@@ -148,7 +148,7 @@ acpi_parse_prmt(union acpi_subtable_headers *header, const unsigned long end)
 		th = &tm->handlers[cur_handler];
 
 		guid_copy(&th->guid, (guid_t *)handler_info->handler_guid);
-		th->handler_addr = efi_pa_va_lookup(handler_info->handler_address);
+		th->handler_addr = (void *)efi_pa_va_lookup(handler_info->handler_address);
 		th->static_data_buffer_addr = efi_pa_va_lookup(handler_info->static_data_buffer_address);
 		th->acpi_param_buffer_addr = efi_pa_va_lookup(handler_info->acpi_param_buffer_address);
 	} while (++cur_handler < tm->handler_count && (handler_info = get_next_handler(handler_info)));
-- 
2.37.0

[PATCH v2 1/4] ACPI: PRM: Change handler_addr type to void pointer

[Sudeep Holla]

handler_addr is a virtial address passed to efi_call_virt_pointer.
While x86 currently type cast it into the pointer in it's arch specific
arch_efi_call_virt() implementation, ARM64 is restrictive for right
reasons.

Convert the handler_addr type from u64 to void pointer.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/acpi/prmt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/prmt.c b/drivers/acpi/prmt.c
index 4d3a219c67f8..998101cf16e4 100644
--- a/drivers/acpi/prmt.c
+++ b/drivers/acpi/prmt.c
@@ -53,7 +53,7 @@ static LIST_HEAD(prm_module_list);
 
 struct prm_handler_info {
 	guid_t guid;
-	u64 handler_addr;
+	void *handler_addr;
 	u64 static_data_buffer_addr;
 	u64 acpi_param_buffer_addr;
 
@@ -148,7 +148,7 @@ acpi_parse_prmt(union acpi_subtable_headers *header, const unsigned long end)
 		th = &tm->handlers[cur_handler];
 
 		guid_copy(&th->guid, (guid_t *)handler_info->handler_guid);
-		th->handler_addr = efi_pa_va_lookup(handler_info->handler_address);
+		th->handler_addr = (void *)efi_pa_va_lookup(handler_info->handler_address);
 		th->static_data_buffer_addr = efi_pa_va_lookup(handler_info->static_data_buffer_address);
 		th->acpi_param_buffer_addr = efi_pa_va_lookup(handler_info->acpi_param_buffer_address);
 	} while (++cur_handler < tm->handler_count && (handler_info = get_next_handler(handler_info)));
-- 
2.37.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 2/4] arm64: efi: Simplify arch_efi_call_virt() macro by using typeof()

[Sudeep Holla]

Currently, the arch_efi_call_virt() assumes all users of it will have
defined a type 'efi_##f##_t' to make use of it. It is unnecessarily
forcing the users to create a new typedef when __efi_rt_asm_wrapper()
actually expects void pointer.

Simplify the arch_efi_call_virt() macro by using typeof(p->f) which must
be a pointer as required by __efi_rt_asm_wrapper() and eliminate the
explicit need for efi_##f##_t type for every user of this macro.

This is needed now in preparation to enable PRMT support on ARM64.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 arch/arm64/include/asm/efi.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index ad55079abe47..53376cdab175 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -29,8 +29,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
 
 #define arch_efi_call_virt(p, f, args...)				\
 ({									\
-	efi_##f##_t *__f;						\
-	__f = p->f;							\
+	typeof(p->f) __f = p->f;					\
 	__efi_rt_asm_wrapper(__f, #f, args);				\
 })
 
-- 
2.37.0

[PATCH v2 2/4] arm64: efi: Simplify arch_efi_call_virt() macro by using typeof()

[Sudeep Holla]

Currently, the arch_efi_call_virt() assumes all users of it will have
defined a type 'efi_##f##_t' to make use of it. It is unnecessarily
forcing the users to create a new typedef when __efi_rt_asm_wrapper()
actually expects void pointer.

Simplify the arch_efi_call_virt() macro by using typeof(p->f) which must
be a pointer as required by __efi_rt_asm_wrapper() and eliminate the
explicit need for efi_##f##_t type for every user of this macro.

This is needed now in preparation to enable PRMT support on ARM64.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 arch/arm64/include/asm/efi.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index ad55079abe47..53376cdab175 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -29,8 +29,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
 
 #define arch_efi_call_virt(p, f, args...)				\
 ({									\
-	efi_##f##_t *__f;						\
-	__f = p->f;							\
+	typeof(p->f) __f = p->f;					\
 	__efi_rt_asm_wrapper(__f, #f, args);				\
 })
 
-- 
2.37.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 3/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Sudeep Holla]

There is interest to make use of PRM(Platform Runtime Mechanism) even on
ARM64 ACPI platforms. Allow PRM to be enabled on ARM64 platforms. It will
be enabled by default as on x86_64.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/acpi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1e34f846508f..d08b7408f0a5 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -592,7 +592,7 @@ config X86_PM_TIMER
 
 config ACPI_PRMT
 	bool "Platform Runtime Mechanism Support"
-	depends on EFI && X86_64
+	depends on EFI && (X86_64 || ARM64)
 	default y
 	help
 	  Platform Runtime Mechanism (PRM) is a firmware interface exposing a
-- 
2.37.0

[PATCH v2 3/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Sudeep Holla]

There is interest to make use of PRM(Platform Runtime Mechanism) even on
ARM64 ACPI platforms. Allow PRM to be enabled on ARM64 platforms. It will
be enabled by default as on x86_64.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/acpi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1e34f846508f..d08b7408f0a5 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -592,7 +592,7 @@ config X86_PM_TIMER
 
 config ACPI_PRMT
 	bool "Platform Runtime Mechanism Support"
-	depends on EFI && X86_64
+	depends on EFI && (X86_64 || ARM64)
 	default y
 	help
 	  Platform Runtime Mechanism (PRM) is a firmware interface exposing a
-- 
2.37.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 4/4] ACPI: Move PRM config option under the main ACPI config

[Sudeep Holla]

Currently PRM(Platform Runtime Mechanism) config option is listed along
with the main ACPI (Advanced Configuration and Power Interface) option
at the same level. On ARM64 platforms unlike x86, ACPI option is listed
at the topmost level of configuration menu. It is rather very confusing
to see PRM option also listed along with ACPI in the topmost level.

Move the same under ACPI config option. No functional change, just changes
the level of visibility of this option under the configuration menu.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/acpi/Kconfig | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index d08b7408f0a5..218b5b59df31 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -572,6 +572,21 @@ source "drivers/acpi/pmic/Kconfig"
 config ACPI_VIOT
 	bool
 
+config ACPI_PRMT
+	bool "Platform Runtime Mechanism Support"
+	depends on EFI && (X86_64 || ARM64)
+	default y
+	help
+	  Platform Runtime Mechanism (PRM) is a firmware interface exposing a
+	  set of binary executables that can be called from the AML interpreter
+	  or directly from device drivers.
+
+	  Say Y to enable the AML interpreter to execute the PRM code.
+
+	  While this feature is optional in principle, leaving it out may
+	  substantially increase computational overhead related to the
+	  initialization of some server systems.
+
 endif	# ACPI
 
 config X86_PM_TIMER
@@ -589,18 +604,3 @@ config X86_PM_TIMER
 
 	  You should nearly always say Y here because many modern
 	  systems require this timer.
-
-config ACPI_PRMT
-	bool "Platform Runtime Mechanism Support"
-	depends on EFI && (X86_64 || ARM64)
-	default y
-	help
-	  Platform Runtime Mechanism (PRM) is a firmware interface exposing a
-	  set of binary executables that can be called from the AML interpreter
-	  or directly from device drivers.
-
-	  Say Y to enable the AML interpreter to execute the PRM code.
-
-	  While this feature is optional in principle, leaving it out may
-	  substantially increase computational overhead related to the
-	  initialization of some server systems.
-- 
2.37.0

[PATCH v2 4/4] ACPI: Move PRM config option under the main ACPI config

[Sudeep Holla]

Currently PRM(Platform Runtime Mechanism) config option is listed along
with the main ACPI (Advanced Configuration and Power Interface) option
at the same level. On ARM64 platforms unlike x86, ACPI option is listed
at the topmost level of configuration menu. It is rather very confusing
to see PRM option also listed along with ACPI in the topmost level.

Move the same under ACPI config option. No functional change, just changes
the level of visibility of this option under the configuration menu.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/acpi/Kconfig | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index d08b7408f0a5..218b5b59df31 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -572,6 +572,21 @@ source "drivers/acpi/pmic/Kconfig"
 config ACPI_VIOT
 	bool
 
+config ACPI_PRMT
+	bool "Platform Runtime Mechanism Support"
+	depends on EFI && (X86_64 || ARM64)
+	default y
+	help
+	  Platform Runtime Mechanism (PRM) is a firmware interface exposing a
+	  set of binary executables that can be called from the AML interpreter
+	  or directly from device drivers.
+
+	  Say Y to enable the AML interpreter to execute the PRM code.
+
+	  While this feature is optional in principle, leaving it out may
+	  substantially increase computational overhead related to the
+	  initialization of some server systems.
+
 endif	# ACPI
 
 config X86_PM_TIMER
@@ -589,18 +604,3 @@ config X86_PM_TIMER
 
 	  You should nearly always say Y here because many modern
 	  systems require this timer.
-
-config ACPI_PRMT
-	bool "Platform Runtime Mechanism Support"
-	depends on EFI && (X86_64 || ARM64)
-	default y
-	help
-	  Platform Runtime Mechanism (PRM) is a firmware interface exposing a
-	  set of binary executables that can be called from the AML interpreter
-	  or directly from device drivers.
-
-	  Say Y to enable the AML interpreter to execute the PRM code.
-
-	  While this feature is optional in principle, leaving it out may
-	  substantially increase computational overhead related to the
-	  initialization of some server systems.
-- 
2.37.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/4] ACPI: PRM: Change handler_addr type to void pointer

[Ard Biesheuvel]

On Tue, 28 Jun 2022 at 14:53, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> handler_addr is a virtial address passed to efi_call_virt_pointer.
> While x86 currently type cast it into the pointer in it's arch specific
> arch_efi_call_virt() implementation, ARM64 is restrictive for right
> reasons.
>
> Convert the handler_addr type from u64 to void pointer.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

> ---
>  drivers/acpi/prmt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/prmt.c b/drivers/acpi/prmt.c
> index 4d3a219c67f8..998101cf16e4 100644
> --- a/drivers/acpi/prmt.c
> +++ b/drivers/acpi/prmt.c
> @@ -53,7 +53,7 @@ static LIST_HEAD(prm_module_list);
>
>  struct prm_handler_info {
>         guid_t guid;
> -       u64 handler_addr;
> +       void *handler_addr;
>         u64 static_data_buffer_addr;
>         u64 acpi_param_buffer_addr;
>
> @@ -148,7 +148,7 @@ acpi_parse_prmt(union acpi_subtable_headers *header, const unsigned long end)
>                 th = &tm->handlers[cur_handler];
>
>                 guid_copy(&th->guid, (guid_t *)handler_info->handler_guid);
> -               th->handler_addr = efi_pa_va_lookup(handler_info->handler_address);
> +               th->handler_addr = (void *)efi_pa_va_lookup(handler_info->handler_address);
>                 th->static_data_buffer_addr = efi_pa_va_lookup(handler_info->static_data_buffer_address);
>                 th->acpi_param_buffer_addr = efi_pa_va_lookup(handler_info->acpi_param_buffer_address);
>         } while (++cur_handler < tm->handler_count && (handler_info = get_next_handler(handler_info)));
> --
> 2.37.0
>

Re: [PATCH v2 1/4] ACPI: PRM: Change handler_addr type to void pointer

[Ard Biesheuvel]

On Tue, 28 Jun 2022 at 14:53, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> handler_addr is a virtial address passed to efi_call_virt_pointer.
> While x86 currently type cast it into the pointer in it's arch specific
> arch_efi_call_virt() implementation, ARM64 is restrictive for right
> reasons.
>
> Convert the handler_addr type from u64 to void pointer.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

> ---
>  drivers/acpi/prmt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/prmt.c b/drivers/acpi/prmt.c
> index 4d3a219c67f8..998101cf16e4 100644
> --- a/drivers/acpi/prmt.c
> +++ b/drivers/acpi/prmt.c
> @@ -53,7 +53,7 @@ static LIST_HEAD(prm_module_list);
>
>  struct prm_handler_info {
>         guid_t guid;
> -       u64 handler_addr;
> +       void *handler_addr;
>         u64 static_data_buffer_addr;
>         u64 acpi_param_buffer_addr;
>
> @@ -148,7 +148,7 @@ acpi_parse_prmt(union acpi_subtable_headers *header, const unsigned long end)
>                 th = &tm->handlers[cur_handler];
>
>                 guid_copy(&th->guid, (guid_t *)handler_info->handler_guid);
> -               th->handler_addr = efi_pa_va_lookup(handler_info->handler_address);
> +               th->handler_addr = (void *)efi_pa_va_lookup(handler_info->handler_address);
>                 th->static_data_buffer_addr = efi_pa_va_lookup(handler_info->static_data_buffer_address);
>                 th->acpi_param_buffer_addr = efi_pa_va_lookup(handler_info->acpi_param_buffer_address);
>         } while (++cur_handler < tm->handler_count && (handler_info = get_next_handler(handler_info)));
> --
> 2.37.0
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/4] arm64: efi: Simplify arch_efi_call_virt() macro by using typeof()

[Ard Biesheuvel]

On Tue, 28 Jun 2022 at 14:53, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Currently, the arch_efi_call_virt() assumes all users of it will have
> defined a type 'efi_##f##_t' to make use of it. It is unnecessarily
> forcing the users to create a new typedef when __efi_rt_asm_wrapper()
> actually expects void pointer.
>
> Simplify the arch_efi_call_virt() macro by using typeof(p->f) which must
> be a pointer as required by __efi_rt_asm_wrapper() and eliminate the
> explicit need for efi_##f##_t type for every user of this macro.
>
> This is needed now in preparation to enable PRMT support on ARM64.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  arch/arm64/include/asm/efi.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
> index ad55079abe47..53376cdab175 100644
> --- a/arch/arm64/include/asm/efi.h
> +++ b/arch/arm64/include/asm/efi.h
> @@ -29,8 +29,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
>
>  #define arch_efi_call_virt(p, f, args...)                              \
>  ({                                                                     \
> -       efi_##f##_t *__f;                                               \
> -       __f = p->f;                                                     \
> +       typeof(p->f) __f = p->f;                                        \
>         __efi_rt_asm_wrapper(__f, #f, args);                            \
>  })
>

Similar to the other patches, we could simply do

#define arch_efi_call_virt(p, f, args...) \
        __efi_rt_asm_wrapper((p)->f, #f, args)

here.

Note, though, that the second argument stringifies the struct field
name, which will contain "handler_addr" in the case of PRM, but this
is fine (we shouldn't hit that diagnostic for new code anyway, as it
is only used to check whether X18 was corrupted by the firmware)

Re: [PATCH v2 2/4] arm64: efi: Simplify arch_efi_call_virt() macro by using typeof()

[Ard Biesheuvel]

On Tue, 28 Jun 2022 at 14:53, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Currently, the arch_efi_call_virt() assumes all users of it will have
> defined a type 'efi_##f##_t' to make use of it. It is unnecessarily
> forcing the users to create a new typedef when __efi_rt_asm_wrapper()
> actually expects void pointer.
>
> Simplify the arch_efi_call_virt() macro by using typeof(p->f) which must
> be a pointer as required by __efi_rt_asm_wrapper() and eliminate the
> explicit need for efi_##f##_t type for every user of this macro.
>
> This is needed now in preparation to enable PRMT support on ARM64.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  arch/arm64/include/asm/efi.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
> index ad55079abe47..53376cdab175 100644
> --- a/arch/arm64/include/asm/efi.h
> +++ b/arch/arm64/include/asm/efi.h
> @@ -29,8 +29,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
>
>  #define arch_efi_call_virt(p, f, args...)                              \
>  ({                                                                     \
> -       efi_##f##_t *__f;                                               \
> -       __f = p->f;                                                     \
> +       typeof(p->f) __f = p->f;                                        \
>         __efi_rt_asm_wrapper(__f, #f, args);                            \
>  })
>

Similar to the other patches, we could simply do

#define arch_efi_call_virt(p, f, args...) \
        __efi_rt_asm_wrapper((p)->f, #f, args)

here.

Note, though, that the second argument stringifies the struct field
name, which will contain "handler_addr" in the case of PRM, but this
is fine (we shouldn't hit that diagnostic for new code anyway, as it
is only used to check whether X18 was corrupted by the firmware)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Ard Biesheuvel]

On Tue, 28 Jun 2022 at 14:54, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> There is interest to make use of PRM(Platform Runtime Mechanism) even on
> ARM64 ACPI platforms. Allow PRM to be enabled on ARM64 platforms. It will
> be enabled by default as on x86_64.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

> ---
>  drivers/acpi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 1e34f846508f..d08b7408f0a5 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -592,7 +592,7 @@ config X86_PM_TIMER
>
>  config ACPI_PRMT
>         bool "Platform Runtime Mechanism Support"
> -       depends on EFI && X86_64
> +       depends on EFI && (X86_64 || ARM64)
>         default y
>         help
>           Platform Runtime Mechanism (PRM) is a firmware interface exposing a
> --
> 2.37.0
>

Re: [PATCH v2 3/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Ard Biesheuvel]

On Tue, 28 Jun 2022 at 14:54, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> There is interest to make use of PRM(Platform Runtime Mechanism) even on
> ARM64 ACPI platforms. Allow PRM to be enabled on ARM64 platforms. It will
> be enabled by default as on x86_64.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

> ---
>  drivers/acpi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 1e34f846508f..d08b7408f0a5 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -592,7 +592,7 @@ config X86_PM_TIMER
>
>  config ACPI_PRMT
>         bool "Platform Runtime Mechanism Support"
> -       depends on EFI && X86_64
> +       depends on EFI && (X86_64 || ARM64)
>         default y
>         help
>           Platform Runtime Mechanism (PRM) is a firmware interface exposing a
> --
> 2.37.0
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 4/4] ACPI: Move PRM config option under the main ACPI config

[Ard Biesheuvel]

On Tue, 28 Jun 2022 at 14:54, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Currently PRM(Platform Runtime Mechanism) config option is listed along
> with the main ACPI (Advanced Configuration and Power Interface) option
> at the same level. On ARM64 platforms unlike x86, ACPI option is listed
> at the topmost level of configuration menu. It is rather very confusing
> to see PRM option also listed along with ACPI in the topmost level.
>
> Move the same under ACPI config option. No functional change, just changes
> the level of visibility of this option under the configuration menu.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

> ---
>  drivers/acpi/Kconfig | 30 +++++++++++++++---------------
>  1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index d08b7408f0a5..218b5b59df31 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -572,6 +572,21 @@ source "drivers/acpi/pmic/Kconfig"
>  config ACPI_VIOT
>         bool
>
> +config ACPI_PRMT
> +       bool "Platform Runtime Mechanism Support"
> +       depends on EFI && (X86_64 || ARM64)
> +       default y
> +       help
> +         Platform Runtime Mechanism (PRM) is a firmware interface exposing a
> +         set of binary executables that can be called from the AML interpreter
> +         or directly from device drivers.
> +
> +         Say Y to enable the AML interpreter to execute the PRM code.
> +
> +         While this feature is optional in principle, leaving it out may
> +         substantially increase computational overhead related to the
> +         initialization of some server systems.
> +
>  endif  # ACPI
>
>  config X86_PM_TIMER
> @@ -589,18 +604,3 @@ config X86_PM_TIMER
>
>           You should nearly always say Y here because many modern
>           systems require this timer.
> -
> -config ACPI_PRMT
> -       bool "Platform Runtime Mechanism Support"
> -       depends on EFI && (X86_64 || ARM64)
> -       default y
> -       help
> -         Platform Runtime Mechanism (PRM) is a firmware interface exposing a
> -         set of binary executables that can be called from the AML interpreter
> -         or directly from device drivers.
> -
> -         Say Y to enable the AML interpreter to execute the PRM code.
> -
> -         While this feature is optional in principle, leaving it out may
> -         substantially increase computational overhead related to the
> -         initialization of some server systems.
> --
> 2.37.0
>

Re: [PATCH v2 4/4] ACPI: Move PRM config option under the main ACPI config

[Ard Biesheuvel]

On Tue, 28 Jun 2022 at 14:54, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Currently PRM(Platform Runtime Mechanism) config option is listed along
> with the main ACPI (Advanced Configuration and Power Interface) option
> at the same level. On ARM64 platforms unlike x86, ACPI option is listed
> at the topmost level of configuration menu. It is rather very confusing
> to see PRM option also listed along with ACPI in the topmost level.
>
> Move the same under ACPI config option. No functional change, just changes
> the level of visibility of this option under the configuration menu.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

> ---
>  drivers/acpi/Kconfig | 30 +++++++++++++++---------------
>  1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index d08b7408f0a5..218b5b59df31 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -572,6 +572,21 @@ source "drivers/acpi/pmic/Kconfig"
>  config ACPI_VIOT
>         bool
>
> +config ACPI_PRMT
> +       bool "Platform Runtime Mechanism Support"
> +       depends on EFI && (X86_64 || ARM64)
> +       default y
> +       help
> +         Platform Runtime Mechanism (PRM) is a firmware interface exposing a
> +         set of binary executables that can be called from the AML interpreter
> +         or directly from device drivers.
> +
> +         Say Y to enable the AML interpreter to execute the PRM code.
> +
> +         While this feature is optional in principle, leaving it out may
> +         substantially increase computational overhead related to the
> +         initialization of some server systems.
> +
>  endif  # ACPI
>
>  config X86_PM_TIMER
> @@ -589,18 +604,3 @@ config X86_PM_TIMER
>
>           You should nearly always say Y here because many modern
>           systems require this timer.
> -
> -config ACPI_PRMT
> -       bool "Platform Runtime Mechanism Support"
> -       depends on EFI && (X86_64 || ARM64)
> -       default y
> -       help
> -         Platform Runtime Mechanism (PRM) is a firmware interface exposing a
> -         set of binary executables that can be called from the AML interpreter
> -         or directly from device drivers.
> -
> -         Say Y to enable the AML interpreter to execute the PRM code.
> -
> -         While this feature is optional in principle, leaving it out may
> -         substantially increase computational overhead related to the
> -         initialization of some server systems.
> --
> 2.37.0
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Sudeep Holla]

Hi Rafael,

On Tue, Jun 28, 2022 at 01:53:42PM +0100, Sudeep Holla wrote:
> Hi,
> 
> This tiny series is to enable Platform Runtime Mechanism(PRM) support on
> ARM64. Not much changes. Just enabling the build and moving the config
> option so that it is not listed under the topmost menu for ARM64.
> 

Ard has slightly modified version of patch 2/4 which updates few other
arch code. Since the PRMT driver build is dependent on that, is it OK
for you to ACK if you agree with other 3 patches(1,3,4) so that it can
be routed via efi tree. Alternatively, Ard has offered to provide a stable
branch if needed.

-- 
Regards,
Sudeep

Re: [PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Sudeep Holla]

Hi Rafael,

On Tue, Jun 28, 2022 at 01:53:42PM +0100, Sudeep Holla wrote:
> Hi,
> 
> This tiny series is to enable Platform Runtime Mechanism(PRM) support on
> ARM64. Not much changes. Just enabling the build and moving the config
> option so that it is not listed under the topmost menu for ARM64.
> 

Ard has slightly modified version of patch 2/4 which updates few other
arch code. Since the PRMT driver build is dependent on that, is it OK
for you to ACK if you agree with other 3 patches(1,3,4) so that it can
be routed via efi tree. Alternatively, Ard has offered to provide a stable
branch if needed.

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Sudeep Holla]

On Wed, Jun 29, 2022 at 10:06:35AM +0100, Sudeep Holla wrote:
> Hi Rafael,
> 
> On Tue, Jun 28, 2022 at 01:53:42PM +0100, Sudeep Holla wrote:
> > Hi,
> > 
> > This tiny series is to enable Platform Runtime Mechanism(PRM) support on
> > ARM64. Not much changes. Just enabling the build and moving the config
> > option so that it is not listed under the topmost menu for ARM64.
> > 
> 
> Ard has slightly modified version of patch 2/4 which updates few other
> arch code. Since the PRMT driver build is dependent on that, is it OK
> for you to ACK if you agree with other 3 patches(1,3,4) so that it can
> be routed via efi tree. Alternatively, Ard has offered to provide a stable
> branch if needed.

Sorry pressed enter too early. I wanted to add reference to the commit in
Ard's efi queue I was referring[1] and the email where we discussed how
to deal with these PRMT patches[2]

-- 
Regards,
Sudeep

[1] https://git.kernel.org/efi/efi/c/8add9a3a2243
[2] https://lore.kernel.org/r/CAMj1kXFc7CaTV3vhJrskL+VZS2rAdb320Be1mhwX4VW=pSsdJA@mail.gmail.com

Re: [PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Sudeep Holla]

On Wed, Jun 29, 2022 at 10:06:35AM +0100, Sudeep Holla wrote:
> Hi Rafael,
> 
> On Tue, Jun 28, 2022 at 01:53:42PM +0100, Sudeep Holla wrote:
> > Hi,
> > 
> > This tiny series is to enable Platform Runtime Mechanism(PRM) support on
> > ARM64. Not much changes. Just enabling the build and moving the config
> > option so that it is not listed under the topmost menu for ARM64.
> > 
> 
> Ard has slightly modified version of patch 2/4 which updates few other
> arch code. Since the PRMT driver build is dependent on that, is it OK
> for you to ACK if you agree with other 3 patches(1,3,4) so that it can
> be routed via efi tree. Alternatively, Ard has offered to provide a stable
> branch if needed.

Sorry pressed enter too early. I wanted to add reference to the commit in
Ard's efi queue I was referring[1] and the email where we discussed how
to deal with these PRMT patches[2]

-- 
Regards,
Sudeep

[1] https://git.kernel.org/efi/efi/c/8add9a3a2243
[2] https://lore.kernel.org/r/CAMj1kXFc7CaTV3vhJrskL+VZS2rAdb320Be1mhwX4VW=pSsdJA@mail.gmail.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Rafael J. Wysocki]

On Wed, Jun 29, 2022 at 11:22 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Jun 29, 2022 at 10:06:35AM +0100, Sudeep Holla wrote:
> > Hi Rafael,
> >
> > On Tue, Jun 28, 2022 at 01:53:42PM +0100, Sudeep Holla wrote:
> > > Hi,
> > >
> > > This tiny series is to enable Platform Runtime Mechanism(PRM) support on
> > > ARM64. Not much changes. Just enabling the build and moving the config
> > > option so that it is not listed under the topmost menu for ARM64.
> > >
> >
> > Ard has slightly modified version of patch 2/4 which updates few other
> > arch code. Since the PRMT driver build is dependent on that, is it OK
> > for you to ACK if you agree with other 3 patches(1,3,4) so that it can
> > be routed via efi tree. Alternatively, Ard has offered to provide a stable
> > branch if needed.
>
> Sorry pressed enter too early. I wanted to add reference to the commit in
> Ard's efi queue I was referring[1] and the email where we discussed how
> to deal with these PRMT patches[2]

The ACPI changes in this series are fine with me, so please feel free to add

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

to the patches and route them through the EFI tree.

Thanks!

Re: [PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Rafael J. Wysocki]

On Wed, Jun 29, 2022 at 11:22 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Jun 29, 2022 at 10:06:35AM +0100, Sudeep Holla wrote:
> > Hi Rafael,
> >
> > On Tue, Jun 28, 2022 at 01:53:42PM +0100, Sudeep Holla wrote:
> > > Hi,
> > >
> > > This tiny series is to enable Platform Runtime Mechanism(PRM) support on
> > > ARM64. Not much changes. Just enabling the build and moving the config
> > > option so that it is not listed under the topmost menu for ARM64.
> > >
> >
> > Ard has slightly modified version of patch 2/4 which updates few other
> > arch code. Since the PRMT driver build is dependent on that, is it OK
> > for you to ACK if you agree with other 3 patches(1,3,4) so that it can
> > be routed via efi tree. Alternatively, Ard has offered to provide a stable
> > branch if needed.
>
> Sorry pressed enter too early. I wanted to add reference to the commit in
> Ard's efi queue I was referring[1] and the email where we discussed how
> to deal with these PRMT patches[2]

The ACPI changes in this series are fine with me, so please feel free to add

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

to the patches and route them through the EFI tree.

Thanks!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Sudeep Holla]

On Wed, Jun 29, 2022 at 09:12:39PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 29, 2022 at 11:22 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Wed, Jun 29, 2022 at 10:06:35AM +0100, Sudeep Holla wrote:
> > > Hi Rafael,
> > >
> > > On Tue, Jun 28, 2022 at 01:53:42PM +0100, Sudeep Holla wrote:
> > > > Hi,
> > > >
> > > > This tiny series is to enable Platform Runtime Mechanism(PRM) support on
> > > > ARM64. Not much changes. Just enabling the build and moving the config
> > > > option so that it is not listed under the topmost menu for ARM64.
> > > >
> > >
> > > Ard has slightly modified version of patch 2/4 which updates few other
> > > arch code. Since the PRMT driver build is dependent on that, is it OK
> > > for you to ACK if you agree with other 3 patches(1,3,4) so that it can
> > > be routed via efi tree. Alternatively, Ard has offered to provide a stable
> > > branch if needed.
> >
> > Sorry pressed enter too early. I wanted to add reference to the commit in
> > Ard's efi queue I was referring[1] and the email where we discussed how
> > to deal with these PRMT patches[2]
> 
> The ACPI changes in this series are fine with me, so please feel free to add
> 
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> to the patches and route them through the EFI tree.
> 

Thanks Rafael.

Hi Ard,

I assume you will pick up the patches(except 2/4 which is already in your
-next) with Rafael's ack.

-- 
Regards,
Sudeep

Re: [PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Sudeep Holla]

On Wed, Jun 29, 2022 at 09:12:39PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 29, 2022 at 11:22 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Wed, Jun 29, 2022 at 10:06:35AM +0100, Sudeep Holla wrote:
> > > Hi Rafael,
> > >
> > > On Tue, Jun 28, 2022 at 01:53:42PM +0100, Sudeep Holla wrote:
> > > > Hi,
> > > >
> > > > This tiny series is to enable Platform Runtime Mechanism(PRM) support on
> > > > ARM64. Not much changes. Just enabling the build and moving the config
> > > > option so that it is not listed under the topmost menu for ARM64.
> > > >
> > >
> > > Ard has slightly modified version of patch 2/4 which updates few other
> > > arch code. Since the PRMT driver build is dependent on that, is it OK
> > > for you to ACK if you agree with other 3 patches(1,3,4) so that it can
> > > be routed via efi tree. Alternatively, Ard has offered to provide a stable
> > > branch if needed.
> >
> > Sorry pressed enter too early. I wanted to add reference to the commit in
> > Ard's efi queue I was referring[1] and the email where we discussed how
> > to deal with these PRMT patches[2]
> 
> The ACPI changes in this series are fine with me, so please feel free to add
> 
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> to the patches and route them through the EFI tree.
> 

Thanks Rafael.

Hi Ard,

I assume you will pick up the patches(except 2/4 which is already in your
-next) with Rafael's ack.

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Ard Biesheuvel]

On Thu, 30 Jun 2022 at 15:03, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Jun 29, 2022 at 09:12:39PM +0200, Rafael J. Wysocki wrote:
> > On Wed, Jun 29, 2022 at 11:22 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > > On Wed, Jun 29, 2022 at 10:06:35AM +0100, Sudeep Holla wrote:
> > > > Hi Rafael,
> > > >
> > > > On Tue, Jun 28, 2022 at 01:53:42PM +0100, Sudeep Holla wrote:
> > > > > Hi,
> > > > >
> > > > > This tiny series is to enable Platform Runtime Mechanism(PRM) support on
> > > > > ARM64. Not much changes. Just enabling the build and moving the config
> > > > > option so that it is not listed under the topmost menu for ARM64.
> > > > >
> > > >
> > > > Ard has slightly modified version of patch 2/4 which updates few other
> > > > arch code. Since the PRMT driver build is dependent on that, is it OK
> > > > for you to ACK if you agree with other 3 patches(1,3,4) so that it can
> > > > be routed via efi tree. Alternatively, Ard has offered to provide a stable
> > > > branch if needed.
> > >
> > > Sorry pressed enter too early. I wanted to add reference to the commit in
> > > Ard's efi queue I was referring[1] and the email where we discussed how
> > > to deal with these PRMT patches[2]
> >
> > The ACPI changes in this series are fine with me, so please feel free to add
> >
> > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > to the patches and route them through the EFI tree.
> >
>
> Thanks Rafael.
>
> Hi Ard,
>
> I assume you will pick up the patches(except 2/4 which is already in your
> -next) with Rafael's ack.
>

OK, I've queued them up now.

Re: [PATCH v2 0/4] ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64

[Ard Biesheuvel]

On Thu, 30 Jun 2022 at 15:03, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Jun 29, 2022 at 09:12:39PM +0200, Rafael J. Wysocki wrote:
> > On Wed, Jun 29, 2022 at 11:22 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > > On Wed, Jun 29, 2022 at 10:06:35AM +0100, Sudeep Holla wrote:
> > > > Hi Rafael,
> > > >
> > > > On Tue, Jun 28, 2022 at 01:53:42PM +0100, Sudeep Holla wrote:
> > > > > Hi,
> > > > >
> > > > > This tiny series is to enable Platform Runtime Mechanism(PRM) support on
> > > > > ARM64. Not much changes. Just enabling the build and moving the config
> > > > > option so that it is not listed under the topmost menu for ARM64.
> > > > >
> > > >
> > > > Ard has slightly modified version of patch 2/4 which updates few other
> > > > arch code. Since the PRMT driver build is dependent on that, is it OK
> > > > for you to ACK if you agree with other 3 patches(1,3,4) so that it can
> > > > be routed via efi tree. Alternatively, Ard has offered to provide a stable
> > > > branch if needed.
> > >
> > > Sorry pressed enter too early. I wanted to add reference to the commit in
> > > Ard's efi queue I was referring[1] and the email where we discussed how
> > > to deal with these PRMT patches[2]
> >
> > The ACPI changes in this series are fine with me, so please feel free to add
> >
> > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > to the patches and route them through the EFI tree.
> >
>
> Thanks Rafael.
>
> Hi Ard,
>
> I assume you will pick up the patches(except 2/4 which is already in your
> -next) with Rafael's ack.
>

OK, I've queued them up now.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel