Re: [PATCH v2] mtd: slram: use memremap() instead of ioremap()

[Roy Franz]

ping - is this suitable for 4.15?

Thanks,
Roy


On Thu, Oct 19, 2017 at 3:55 PM, Roy Franz <rfr...@cavium.com> wrote:
> Convert slram to use memremap() to map the memory it uses to back an MTD
> device, as this is the proper interface for mapping memory. This change
> enables normal memory to be used to back an MTD device on arm64, as arm64
> prevents ioremap() being used on normal memory.
>
> Signed-off-by: Roy Franz <roy.fr...@cavium.com>
> Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Tested-by: David Daney <david.da...@cavium.com>
> ---
> Tested on arm64 simulation, using simulator to preload filesystem image into 
> RAM,
> and also tested on x86_64 using video card memory.  This is useful for 
> speeding
> up booting on (very slow) emulation environments by avoiding any processing of
> an initramfs.
> David Daney tested on MIPS64.
>
> v2: Fix typo in subject line, s/mdt/mtd/
> added acked-by/tested-by
>
>  drivers/mtd/devices/slram.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
> index 8087c36dc693..0ec85f316d24 100644
> --- a/drivers/mtd/devices/slram.c
> +++ b/drivers/mtd/devices/slram.c
> @@ -163,8 +163,9 @@ static int register_device(char *name, unsigned long 
> start, unsigned long length
> }
>
> if (!(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start =
> -   ioremap(start, length))) {
> -   E("slram: ioremap failed\n");
> +   memremap(start, length,
> +MEMREMAP_WB | MEMREMAP_WT | MEMREMAP_WC))) {
> +   E("slram: memremap failed\n");
> return -EIO;
> }
> ((slram_priv_t *)(*curmtd)->mtdinfo->priv)->end =
> @@ -186,7 +187,7 @@ static int register_device(char *name, unsigned long 
> start, unsigned long length
>
> if (mtd_device_register((*curmtd)->mtdinfo, NULL, 0))   {
> E("slram: Failed to register new device\n");
> -   iounmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
> +   memunmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
> kfree((*curmtd)->mtdinfo->priv);
> kfree((*curmtd)->mtdinfo);
> return(-EAGAIN);
> @@ -206,7 +207,7 @@ static void unregister_devices(void)
> while (slram_mtdlist) {
> nextitem = slram_mtdlist->next;
> mtd_device_unregister(slram_mtdlist->mtdinfo);
> -   iounmap(((slram_priv_t 
> *)slram_mtdlist->mtdinfo->priv)->start);
> +   memunmap(((slram_priv_t 
> *)slram_mtdlist->mtdinfo->priv)->start);
> kfree(slram_mtdlist->mtdinfo->priv);
> kfree(slram_mtdlist->mtdinfo);
> kfree(slram_mtdlist);
> --
> 2.11.0
>

Re: [PATCH v2] mtd: slram: use memremap() instead of ioremap()

[Roy Franz]

ping - is this suitable for 4.15?

Thanks,
Roy


On Thu, Oct 19, 2017 at 3:55 PM, Roy Franz  wrote:
> Convert slram to use memremap() to map the memory it uses to back an MTD
> device, as this is the proper interface for mapping memory. This change
> enables normal memory to be used to back an MTD device on arm64, as arm64
> prevents ioremap() being used on normal memory.
>
> Signed-off-by: Roy Franz 
> Acked-by: Ard Biesheuvel 
> Tested-by: David Daney 
> ---
> Tested on arm64 simulation, using simulator to preload filesystem image into 
> RAM,
> and also tested on x86_64 using video card memory.  This is useful for 
> speeding
> up booting on (very slow) emulation environments by avoiding any processing of
> an initramfs.
> David Daney tested on MIPS64.
>
> v2: Fix typo in subject line, s/mdt/mtd/
> added acked-by/tested-by
>
>  drivers/mtd/devices/slram.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
> index 8087c36dc693..0ec85f316d24 100644
> --- a/drivers/mtd/devices/slram.c
> +++ b/drivers/mtd/devices/slram.c
> @@ -163,8 +163,9 @@ static int register_device(char *name, unsigned long 
> start, unsigned long length
> }
>
> if (!(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start =
> -   ioremap(start, length))) {
> -   E("slram: ioremap failed\n");
> +   memremap(start, length,
> +MEMREMAP_WB | MEMREMAP_WT | MEMREMAP_WC))) {
> +   E("slram: memremap failed\n");
> return -EIO;
> }
> ((slram_priv_t *)(*curmtd)->mtdinfo->priv)->end =
> @@ -186,7 +187,7 @@ static int register_device(char *name, unsigned long 
> start, unsigned long length
>
> if (mtd_device_register((*curmtd)->mtdinfo, NULL, 0))   {
> E("slram: Failed to register new device\n");
> -   iounmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
> +   memunmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
> kfree((*curmtd)->mtdinfo->priv);
> kfree((*curmtd)->mtdinfo);
> return(-EAGAIN);
> @@ -206,7 +207,7 @@ static void unregister_devices(void)
> while (slram_mtdlist) {
> nextitem = slram_mtdlist->next;
> mtd_device_unregister(slram_mtdlist->mtdinfo);
> -   iounmap(((slram_priv_t 
> *)slram_mtdlist->mtdinfo->priv)->start);
> +   memunmap(((slram_priv_t 
> *)slram_mtdlist->mtdinfo->priv)->start);
> kfree(slram_mtdlist->mtdinfo->priv);
> kfree(slram_mtdlist->mtdinfo);
> kfree(slram_mtdlist);
> --
> 2.11.0
>

[PATCH v2] mtd: slram: use memremap() instead of ioremap()

[Roy Franz]

Convert slram to use memremap() to map the memory it uses to back an MTD
device, as this is the proper interface for mapping memory. This change
enables normal memory to be used to back an MTD device on arm64, as arm64
prevents ioremap() being used on normal memory.

Signed-off-by: Roy Franz <roy.fr...@cavium.com>
Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Tested-by: David Daney <david.da...@cavium.com>
---
Tested on arm64 simulation, using simulator to preload filesystem image into 
RAM,
and also tested on x86_64 using video card memory.  This is useful for speeding
up booting on (very slow) emulation environments by avoiding any processing of
an initramfs.
David Daney tested on MIPS64.

v2: Fix typo in subject line, s/mdt/mtd/
added acked-by/tested-by

 drivers/mtd/devices/slram.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
index 8087c36dc693..0ec85f316d24 100644
--- a/drivers/mtd/devices/slram.c
+++ b/drivers/mtd/devices/slram.c
@@ -163,8 +163,9 @@ static int register_device(char *name, unsigned long start, 
unsigned long length
}
 
if (!(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start =
-   ioremap(start, length))) {
-   E("slram: ioremap failed\n");
+   memremap(start, length,
+MEMREMAP_WB | MEMREMAP_WT | MEMREMAP_WC))) {
+   E("slram: memremap failed\n");
return -EIO;
}
((slram_priv_t *)(*curmtd)->mtdinfo->priv)->end =
@@ -186,7 +187,7 @@ static int register_device(char *name, unsigned long start, 
unsigned long length
 
if (mtd_device_register((*curmtd)->mtdinfo, NULL, 0))   {
E("slram: Failed to register new device\n");
-   iounmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
+   memunmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
kfree((*curmtd)->mtdinfo->priv);
kfree((*curmtd)->mtdinfo);
return(-EAGAIN);
@@ -206,7 +207,7 @@ static void unregister_devices(void)
while (slram_mtdlist) {
nextitem = slram_mtdlist->next;
mtd_device_unregister(slram_mtdlist->mtdinfo);
-   iounmap(((slram_priv_t *)slram_mtdlist->mtdinfo->priv)->start);
+   memunmap(((slram_priv_t *)slram_mtdlist->mtdinfo->priv)->start);
kfree(slram_mtdlist->mtdinfo->priv);
kfree(slram_mtdlist->mtdinfo);
kfree(slram_mtdlist);
-- 
2.11.0

[PATCH v2] mtd: slram: use memremap() instead of ioremap()

[Roy Franz]

Convert slram to use memremap() to map the memory it uses to back an MTD
device, as this is the proper interface for mapping memory. This change
enables normal memory to be used to back an MTD device on arm64, as arm64
prevents ioremap() being used on normal memory.

Signed-off-by: Roy Franz 
Acked-by: Ard Biesheuvel 
Tested-by: David Daney 
---
Tested on arm64 simulation, using simulator to preload filesystem image into 
RAM,
and also tested on x86_64 using video card memory.  This is useful for speeding
up booting on (very slow) emulation environments by avoiding any processing of
an initramfs.
David Daney tested on MIPS64.

v2: Fix typo in subject line, s/mdt/mtd/
added acked-by/tested-by

 drivers/mtd/devices/slram.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
index 8087c36dc693..0ec85f316d24 100644
--- a/drivers/mtd/devices/slram.c
+++ b/drivers/mtd/devices/slram.c
@@ -163,8 +163,9 @@ static int register_device(char *name, unsigned long start, 
unsigned long length
}
 
if (!(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start =
-   ioremap(start, length))) {
-   E("slram: ioremap failed\n");
+   memremap(start, length,
+MEMREMAP_WB | MEMREMAP_WT | MEMREMAP_WC))) {
+   E("slram: memremap failed\n");
return -EIO;
}
((slram_priv_t *)(*curmtd)->mtdinfo->priv)->end =
@@ -186,7 +187,7 @@ static int register_device(char *name, unsigned long start, 
unsigned long length
 
if (mtd_device_register((*curmtd)->mtdinfo, NULL, 0))   {
E("slram: Failed to register new device\n");
-   iounmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
+   memunmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
kfree((*curmtd)->mtdinfo->priv);
kfree((*curmtd)->mtdinfo);
return(-EAGAIN);
@@ -206,7 +207,7 @@ static void unregister_devices(void)
while (slram_mtdlist) {
nextitem = slram_mtdlist->next;
mtd_device_unregister(slram_mtdlist->mtdinfo);
-   iounmap(((slram_priv_t *)slram_mtdlist->mtdinfo->priv)->start);
+   memunmap(((slram_priv_t *)slram_mtdlist->mtdinfo->priv)->start);
kfree(slram_mtdlist->mtdinfo->priv);
kfree(slram_mtdlist->mtdinfo);
kfree(slram_mtdlist);
-- 
2.11.0

Re: [PATCH] mdt: slram: use memremap() instead of ioremap()

[Roy Franz]

On Thu, Oct 19, 2017 at 8:37 AM, Christoph Hellwig  wrote:
> s/mdt/mtd/ in the subject?

Yup, I'll repost a fixed version.

Re: [PATCH] mdt: slram: use memremap() instead of ioremap()

[Roy Franz]

On Thu, Oct 19, 2017 at 8:37 AM, Christoph Hellwig  wrote:
> s/mdt/mtd/ in the subject?

Yup, I'll repost a fixed version.

[PATCH] mdt: slram: use memremap() instead of ioremap()

[Roy Franz]

Convert slram to use memremap() to map the memory it uses to back an MTD
device, as this is the proper interface for mapping memory. This change
enables normal memory to be used to back an MTD device on arm64, as arm64
prevents ioremap() being used on normal memory.

Signed-off-by: Roy Franz <roy.fr...@cavium.com>
---
Tested on arm64 simulation, using simulator to preload filesystem image into 
RAM,
and also tested on x86_64 using video card memory.  This is useful for speeding
up booting on (very slow) emulation environments by avoiding any processing of
an initramfs.

 drivers/mtd/devices/slram.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
index 8087c36dc693..0ec85f316d24 100644
--- a/drivers/mtd/devices/slram.c
+++ b/drivers/mtd/devices/slram.c
@@ -163,8 +163,9 @@ static int register_device(char *name, unsigned long start, 
unsigned long length
}
 
if (!(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start =
-   ioremap(start, length))) {
-   E("slram: ioremap failed\n");
+   memremap(start, length,
+MEMREMAP_WB | MEMREMAP_WT | MEMREMAP_WC))) {
+   E("slram: memremap failed\n");
return -EIO;
}
((slram_priv_t *)(*curmtd)->mtdinfo->priv)->end =
@@ -186,7 +187,7 @@ static int register_device(char *name, unsigned long start, 
unsigned long length
 
if (mtd_device_register((*curmtd)->mtdinfo, NULL, 0))   {
E("slram: Failed to register new device\n");
-   iounmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
+   memunmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
kfree((*curmtd)->mtdinfo->priv);
kfree((*curmtd)->mtdinfo);
return(-EAGAIN);
@@ -206,7 +207,7 @@ static void unregister_devices(void)
while (slram_mtdlist) {
nextitem = slram_mtdlist->next;
mtd_device_unregister(slram_mtdlist->mtdinfo);
-   iounmap(((slram_priv_t *)slram_mtdlist->mtdinfo->priv)->start);
+   memunmap(((slram_priv_t *)slram_mtdlist->mtdinfo->priv)->start);
kfree(slram_mtdlist->mtdinfo->priv);
kfree(slram_mtdlist->mtdinfo);
kfree(slram_mtdlist);
-- 
2.11.0

[PATCH] mdt: slram: use memremap() instead of ioremap()

[Roy Franz]

Convert slram to use memremap() to map the memory it uses to back an MTD
device, as this is the proper interface for mapping memory. This change
enables normal memory to be used to back an MTD device on arm64, as arm64
prevents ioremap() being used on normal memory.

Signed-off-by: Roy Franz 
---
Tested on arm64 simulation, using simulator to preload filesystem image into 
RAM,
and also tested on x86_64 using video card memory.  This is useful for speeding
up booting on (very slow) emulation environments by avoiding any processing of
an initramfs.

 drivers/mtd/devices/slram.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
index 8087c36dc693..0ec85f316d24 100644
--- a/drivers/mtd/devices/slram.c
+++ b/drivers/mtd/devices/slram.c
@@ -163,8 +163,9 @@ static int register_device(char *name, unsigned long start, 
unsigned long length
}
 
if (!(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start =
-   ioremap(start, length))) {
-   E("slram: ioremap failed\n");
+   memremap(start, length,
+MEMREMAP_WB | MEMREMAP_WT | MEMREMAP_WC))) {
+   E("slram: memremap failed\n");
return -EIO;
}
((slram_priv_t *)(*curmtd)->mtdinfo->priv)->end =
@@ -186,7 +187,7 @@ static int register_device(char *name, unsigned long start, 
unsigned long length
 
if (mtd_device_register((*curmtd)->mtdinfo, NULL, 0))   {
E("slram: Failed to register new device\n");
-   iounmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
+   memunmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
kfree((*curmtd)->mtdinfo->priv);
kfree((*curmtd)->mtdinfo);
return(-EAGAIN);
@@ -206,7 +207,7 @@ static void unregister_devices(void)
while (slram_mtdlist) {
nextitem = slram_mtdlist->next;
mtd_device_unregister(slram_mtdlist->mtdinfo);
-   iounmap(((slram_priv_t *)slram_mtdlist->mtdinfo->priv)->start);
+   memunmap(((slram_priv_t *)slram_mtdlist->mtdinfo->priv)->start);
kfree(slram_mtdlist->mtdinfo->priv);
kfree(slram_mtdlist->mtdinfo);
kfree(slram_mtdlist);
-- 
2.11.0

Re: [RFC PATCH 3/8] firmware: arm_scmi: add common infrastructure and support for base protocol

[Roy Franz]

On Wed, Jun 7, 2017 at 9:10 AM, Sudeep Holla  wrote:
> The base protocol describes the properties of the implementation and
> provide generic error management. The base protocol provides commands
> to describe protocol version, discover implementation specific
> attributes and vendor/sub-vendor identification, list of protocols
> implemented and the various agents are in the system including OSPM
> and the platform. It also supports registering for notifications of
> platform errors.
>
> This protocol is mandatory. This patch adds support for the same along
> with some basic infrastructure to add support for other protocols.
>
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/firmware/arm_scmi/Makefile |   2 +-
>  drivers/firmware/arm_scmi/base.c   | 290 
> +
>  drivers/firmware/arm_scmi/common.h |  46 ++
>  drivers/firmware/arm_scmi/driver.c |  67 +
>  include/linux/scmi_protocol.h  |  28 
>  5 files changed, 432 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/arm_scmi/base.c
>
> diff --git a/drivers/firmware/arm_scmi/Makefile 
> b/drivers/firmware/arm_scmi/Makefile
> index 58e94c95e523..21d01d1d6b9c 100644
> --- a/drivers/firmware/arm_scmi/Makefile
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_ARM_SCMI_PROTOCOL)= arm_scmi.o
> -arm_scmi-y = driver.o
> +arm_scmi-y = base.o driver.o
> diff --git a/drivers/firmware/arm_scmi/base.c 
> b/drivers/firmware/arm_scmi/base.c
> new file mode 100644
> index ..1191a409ea73
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/base.c
> @@ -0,0 +1,290 @@
> +/*
> + * System Control and Management Interface (SCMI) Base Protocol
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program. If not, see .
> + */
> +
> +#include "common.h"
> +
> +enum scmi_base_protocol_cmd {
> +   BASE_DISCOVER_VENDOR = 0x3,
> +   BASE_DISCOVER_SUB_VENDOR = 0x4,
> +   BASE_DISCOVER_IMPLEMENT_VERSION = 0x5,
> +   BASE_DISCOVER_LIST_PROTOCOLS = 0x6,
> +   BASE_DISCOVER_AGENT = 0x7,
> +   BASE_NOTIFY_ERRORS = 0x8,
> +};
> +
> +struct scmi_msg_resp_base_attributes {
> +   u8 num_protocols;
> +   u8 num_agents;
> +   __le16 reserved;
> +} __packed;
> +
> +/**
> + * scmi_base_attributes_get() - gets the implementation details
> + * that are associated with the base protocol.
> + *
> + * @handle - SCMI entity handle
> + *
> + * Return: 0 on success, else appropriate SCMI error.
> + */
> +static int scmi_base_attributes_get(struct scmi_handle *handle)
> +{
> +   int ret;
> +   struct scmi_xfer *t;
> +   struct scmi_msg_resp_base_attributes *attr_info;
> +   struct scmi_revision_info *rev = handle->version;
> +
> +   ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
> +SCMI_PROTOCOL_BASE, 0, sizeof(*attr_info), 
> );
> +   if (ret)
> +   return ret;
> +
> +   ret = scmi_do_xfer(handle, t);
> +   if (!ret) {
> +   attr_info = (struct scmi_msg_resp_base_attributes *)t->rx.buf;
> +   rev->num_protocols = attr_info->num_protocols;
> +   rev->num_agents = attr_info->num_agents;
> +   }
> +
> +   scmi_put_one_xfer(handle, t);
> +   return ret;
> +}
> +
> +/**
> + * scmi_base_vendor_id_get() - gets vendor/subvendor identifier ASCII string.
> + *
> + * @handle - SCMI entity handle
> + * @sub_vendor - specify true if sub-vendor ID is needed
> + *
> + * Return: 0 on success, else appropriate SCMI error.
> + */
> +static int scmi_base_vendor_id_get(struct scmi_handle *handle, bool 
> sub_vendor)
> +{
> +   u8 cmd;
> +   int ret, size;
> +   char *vendor_id;
> +   struct scmi_xfer *t;
> +   struct scmi_revision_info *rev = handle->version;
> +
> +   if (sub_vendor) {
> +   cmd = BASE_DISCOVER_SUB_VENDOR;
> +   vendor_id = rev->sub_vendor_id;
> +   size = ARRAY_SIZE(rev->sub_vendor_id);
> +   } else {
> +   cmd = BASE_DISCOVER_VENDOR;
> +   vendor_id = rev->vendor_id;
> +   size = ARRAY_SIZE(rev->vendor_id);
> +   }
> +
> +   ret = scmi_one_xfer_init(handle, cmd, SCMI_PROTOCOL_BASE, 0, size, 
> );
> +   if (ret)
> +   return ret;
> +
> +   ret = scmi_do_xfer(handle, t);

Re: [RFC PATCH 3/8] firmware: arm_scmi: add common infrastructure and support for base protocol

[Roy Franz]

On Wed, Jun 7, 2017 at 9:10 AM, Sudeep Holla  wrote:
> The base protocol describes the properties of the implementation and
> provide generic error management. The base protocol provides commands
> to describe protocol version, discover implementation specific
> attributes and vendor/sub-vendor identification, list of protocols
> implemented and the various agents are in the system including OSPM
> and the platform. It also supports registering for notifications of
> platform errors.
>
> This protocol is mandatory. This patch adds support for the same along
> with some basic infrastructure to add support for other protocols.
>
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/firmware/arm_scmi/Makefile |   2 +-
>  drivers/firmware/arm_scmi/base.c   | 290 
> +
>  drivers/firmware/arm_scmi/common.h |  46 ++
>  drivers/firmware/arm_scmi/driver.c |  67 +
>  include/linux/scmi_protocol.h  |  28 
>  5 files changed, 432 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/arm_scmi/base.c
>
> diff --git a/drivers/firmware/arm_scmi/Makefile 
> b/drivers/firmware/arm_scmi/Makefile
> index 58e94c95e523..21d01d1d6b9c 100644
> --- a/drivers/firmware/arm_scmi/Makefile
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_ARM_SCMI_PROTOCOL)= arm_scmi.o
> -arm_scmi-y = driver.o
> +arm_scmi-y = base.o driver.o
> diff --git a/drivers/firmware/arm_scmi/base.c 
> b/drivers/firmware/arm_scmi/base.c
> new file mode 100644
> index ..1191a409ea73
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/base.c
> @@ -0,0 +1,290 @@
> +/*
> + * System Control and Management Interface (SCMI) Base Protocol
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program. If not, see .
> + */
> +
> +#include "common.h"
> +
> +enum scmi_base_protocol_cmd {
> +   BASE_DISCOVER_VENDOR = 0x3,
> +   BASE_DISCOVER_SUB_VENDOR = 0x4,
> +   BASE_DISCOVER_IMPLEMENT_VERSION = 0x5,
> +   BASE_DISCOVER_LIST_PROTOCOLS = 0x6,
> +   BASE_DISCOVER_AGENT = 0x7,
> +   BASE_NOTIFY_ERRORS = 0x8,
> +};
> +
> +struct scmi_msg_resp_base_attributes {
> +   u8 num_protocols;
> +   u8 num_agents;
> +   __le16 reserved;
> +} __packed;
> +
> +/**
> + * scmi_base_attributes_get() - gets the implementation details
> + * that are associated with the base protocol.
> + *
> + * @handle - SCMI entity handle
> + *
> + * Return: 0 on success, else appropriate SCMI error.
> + */
> +static int scmi_base_attributes_get(struct scmi_handle *handle)
> +{
> +   int ret;
> +   struct scmi_xfer *t;
> +   struct scmi_msg_resp_base_attributes *attr_info;
> +   struct scmi_revision_info *rev = handle->version;
> +
> +   ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
> +SCMI_PROTOCOL_BASE, 0, sizeof(*attr_info), 
> );
> +   if (ret)
> +   return ret;
> +
> +   ret = scmi_do_xfer(handle, t);
> +   if (!ret) {
> +   attr_info = (struct scmi_msg_resp_base_attributes *)t->rx.buf;
> +   rev->num_protocols = attr_info->num_protocols;
> +   rev->num_agents = attr_info->num_agents;
> +   }
> +
> +   scmi_put_one_xfer(handle, t);
> +   return ret;
> +}
> +
> +/**
> + * scmi_base_vendor_id_get() - gets vendor/subvendor identifier ASCII string.
> + *
> + * @handle - SCMI entity handle
> + * @sub_vendor - specify true if sub-vendor ID is needed
> + *
> + * Return: 0 on success, else appropriate SCMI error.
> + */
> +static int scmi_base_vendor_id_get(struct scmi_handle *handle, bool 
> sub_vendor)
> +{
> +   u8 cmd;
> +   int ret, size;
> +   char *vendor_id;
> +   struct scmi_xfer *t;
> +   struct scmi_revision_info *rev = handle->version;
> +
> +   if (sub_vendor) {
> +   cmd = BASE_DISCOVER_SUB_VENDOR;
> +   vendor_id = rev->sub_vendor_id;
> +   size = ARRAY_SIZE(rev->sub_vendor_id);
> +   } else {
> +   cmd = BASE_DISCOVER_VENDOR;
> +   vendor_id = rev->vendor_id;
> +   size = ARRAY_SIZE(rev->vendor_id);
> +   }
> +
> +   ret = scmi_one_xfer_init(handle, cmd, SCMI_PROTOCOL_BASE, 0, size, 
> );
> +   if (ret)
> +   return ret;
> +
> +   ret = scmi_do_xfer(handle, t);
> +   if (!ret)
> +   

Re: [RFC PATCH 5/8] firmware: arm_scmi: add initial support for clock protocol

[Roy Franz]

On Wed, Jun 7, 2017 at 9:10 AM, Sudeep Holla  wrote:
> The clock protocol is intended for management of clocks. It is used to
> enable or disable clocks, and to set and get the clock rates. This
> protocol provides commands to describe the protocol version, discover
> various implementation specific attributes, describe a clock, enable
> and disable a clock and get/set the rate of the clock synchronously or
> asynchronously.
>
> This patch adds initial support for the clock protocol.
>
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/firmware/arm_scmi/Makefile |   2 +-
>  drivers/firmware/arm_scmi/clock.c  | 340 
> +
>  drivers/firmware/arm_scmi/common.h |   1 +
>  include/linux/scmi_protocol.h  |  18 ++
>  4 files changed, 360 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/arm_scmi/clock.c
>
> diff --git a/drivers/firmware/arm_scmi/Makefile 
> b/drivers/firmware/arm_scmi/Makefile
> index 159de726ee45..6836b1f38f7f 100644
> --- a/drivers/firmware/arm_scmi/Makefile
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_ARM_SCMI_PROTOCOL)= arm_scmi.o
> -arm_scmi-y = base.o driver.o perf.o
> +arm_scmi-y = base.o clock.o driver.o perf.o
> diff --git a/drivers/firmware/arm_scmi/clock.c 
> b/drivers/firmware/arm_scmi/clock.c
> new file mode 100644
> index ..e02827a48ab7
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/clock.c
> @@ -0,0 +1,340 @@
> +/*
> + * System Control and Management Interface (SCMI) Clock Protocol
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program. If not, see .
> + */
> +
> +#include "common.h"
> +
> +enum scmi_clock_protocol_cmd {
> +   CLOCK_ATTRIBUTES = 0x3,
> +   CLOCK_DESCRIBE_RATES = 0x4,
> +   CLOCK_RATE_SET = 0x5,
> +   CLOCK_RATE_GET = 0x6,
> +   CLOCK_CONFIG_SET = 0x7,
> +};
> +
> +struct scmi_msg_resp_clock_protocol_attributes {
> +   __le16 num_clocks;
> +   u8 max_async_req;
> +   u8 reserved;
> +} __packed;
> +
> +struct scmi_msg_resp_clock_attributes {
> +   __le32 attributes;
> +#defineCLOCK_ENABLEBIT(0)
> +   u8 name[SCMI_MAX_STR_SIZE];
> +} __packed;
> +
> +struct scmi_clock_set_config {
> +   __le32 id;
> +   __le32 attributes;
> +} __packed;
> +
> +struct scmi_msg_clock_describe_rates {
> +   __le32 id;
> +   __le32 rate_index;
> +} __packed;
> +
> +struct scmi_msg_resp_clock_describe_rates {
> +   __le16 num_returned;
> +#define NUM_RETURNED_MASK  (0xfff)
> +#define RATE_DISCRETE(x)   ((x) & BIT(12))
> +   __le16 num_remaining;
> +   struct {
> +   __le32 value_low;
> +   __le32 value_high;
> +   } rate[0];
> +#define RATE_TO_U64(X) \
> +({ \
> +   typeof(X) x = (X);  \
> +   le32_to_cpu((x).value_low) | (u64)le32_to_cpu((x).value_high) >> 32; \
> +})
> +} __packed;
> +
> +struct scmi_clock_set_rate {
> +   __le32 flags;
> +#define CLOCK_SET_ASYSCBIT(0)
> +#define CLOCK_SET_DELAYED  BIT(1)
> +#define CLOCK_ROUND_UP BIT(2)
> +#define CLOCK_ROUND_AUTO   BIT(3)
> +   __le32 id;
> +   __le32 value_low;
> +   __le32 value_high;
> +} __packed;
> +
> +struct clock_info {
> +   u32 attributes;
> +   char name[SCMI_MAX_STR_SIZE];
> +   union {
> +   int num_rates;
> +   u64 rates[MAX_NUM_RATES];
> +   struct {
> +   u64 min_rate;
> +   u64 max_rate;
> +   u64 step_size;
> +   } range;
> +   };
> +};
> +
> +struct scmi_clock_info {
> +   int num_clocks;
> +   int max_async_req;
> +   struct clock_info *clk;
> +};
> +
> +static struct scmi_clock_info clocks;
> +
> +static int scmi_clock_protocol_attributes_get(struct scmi_handle *handle,
> + struct scmi_clock_info *clocks)
> +{
> +   int ret;
> +   struct scmi_xfer *t;
> +   struct scmi_msg_resp_clock_protocol_attributes *attr;
> +
> +   ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
> +SCMI_PROTOCOL_CLOCK, 0, sizeof(*attr), );
> +   if (ret)
> +   return ret;
> +
> +   attr = (struct scmi_msg_resp_clock_protocol_attributes 

Re: [RFC PATCH 5/8] firmware: arm_scmi: add initial support for clock protocol

[Roy Franz]

On Wed, Jun 7, 2017 at 9:10 AM, Sudeep Holla  wrote:
> The clock protocol is intended for management of clocks. It is used to
> enable or disable clocks, and to set and get the clock rates. This
> protocol provides commands to describe the protocol version, discover
> various implementation specific attributes, describe a clock, enable
> and disable a clock and get/set the rate of the clock synchronously or
> asynchronously.
>
> This patch adds initial support for the clock protocol.
>
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/firmware/arm_scmi/Makefile |   2 +-
>  drivers/firmware/arm_scmi/clock.c  | 340 
> +
>  drivers/firmware/arm_scmi/common.h |   1 +
>  include/linux/scmi_protocol.h  |  18 ++
>  4 files changed, 360 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/arm_scmi/clock.c
>
> diff --git a/drivers/firmware/arm_scmi/Makefile 
> b/drivers/firmware/arm_scmi/Makefile
> index 159de726ee45..6836b1f38f7f 100644
> --- a/drivers/firmware/arm_scmi/Makefile
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_ARM_SCMI_PROTOCOL)= arm_scmi.o
> -arm_scmi-y = base.o driver.o perf.o
> +arm_scmi-y = base.o clock.o driver.o perf.o
> diff --git a/drivers/firmware/arm_scmi/clock.c 
> b/drivers/firmware/arm_scmi/clock.c
> new file mode 100644
> index ..e02827a48ab7
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/clock.c
> @@ -0,0 +1,340 @@
> +/*
> + * System Control and Management Interface (SCMI) Clock Protocol
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program. If not, see .
> + */
> +
> +#include "common.h"
> +
> +enum scmi_clock_protocol_cmd {
> +   CLOCK_ATTRIBUTES = 0x3,
> +   CLOCK_DESCRIBE_RATES = 0x4,
> +   CLOCK_RATE_SET = 0x5,
> +   CLOCK_RATE_GET = 0x6,
> +   CLOCK_CONFIG_SET = 0x7,
> +};
> +
> +struct scmi_msg_resp_clock_protocol_attributes {
> +   __le16 num_clocks;
> +   u8 max_async_req;
> +   u8 reserved;
> +} __packed;
> +
> +struct scmi_msg_resp_clock_attributes {
> +   __le32 attributes;
> +#defineCLOCK_ENABLEBIT(0)
> +   u8 name[SCMI_MAX_STR_SIZE];
> +} __packed;
> +
> +struct scmi_clock_set_config {
> +   __le32 id;
> +   __le32 attributes;
> +} __packed;
> +
> +struct scmi_msg_clock_describe_rates {
> +   __le32 id;
> +   __le32 rate_index;
> +} __packed;
> +
> +struct scmi_msg_resp_clock_describe_rates {
> +   __le16 num_returned;
> +#define NUM_RETURNED_MASK  (0xfff)
> +#define RATE_DISCRETE(x)   ((x) & BIT(12))
> +   __le16 num_remaining;
> +   struct {
> +   __le32 value_low;
> +   __le32 value_high;
> +   } rate[0];
> +#define RATE_TO_U64(X) \
> +({ \
> +   typeof(X) x = (X);  \
> +   le32_to_cpu((x).value_low) | (u64)le32_to_cpu((x).value_high) >> 32; \
> +})
> +} __packed;
> +
> +struct scmi_clock_set_rate {
> +   __le32 flags;
> +#define CLOCK_SET_ASYSCBIT(0)
> +#define CLOCK_SET_DELAYED  BIT(1)
> +#define CLOCK_ROUND_UP BIT(2)
> +#define CLOCK_ROUND_AUTO   BIT(3)
> +   __le32 id;
> +   __le32 value_low;
> +   __le32 value_high;
> +} __packed;
> +
> +struct clock_info {
> +   u32 attributes;
> +   char name[SCMI_MAX_STR_SIZE];
> +   union {
> +   int num_rates;
> +   u64 rates[MAX_NUM_RATES];
> +   struct {
> +   u64 min_rate;
> +   u64 max_rate;
> +   u64 step_size;
> +   } range;
> +   };
> +};
> +
> +struct scmi_clock_info {
> +   int num_clocks;
> +   int max_async_req;
> +   struct clock_info *clk;
> +};
> +
> +static struct scmi_clock_info clocks;
> +
> +static int scmi_clock_protocol_attributes_get(struct scmi_handle *handle,
> + struct scmi_clock_info *clocks)
> +{
> +   int ret;
> +   struct scmi_xfer *t;
> +   struct scmi_msg_resp_clock_protocol_attributes *attr;
> +
> +   ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
> +SCMI_PROTOCOL_CLOCK, 0, sizeof(*attr), );
> +   if (ret)
> +   return ret;
> +
> +   attr = (struct scmi_msg_resp_clock_protocol_attributes *)t->rx.buf;
> +
> +   ret = 

Re: [RFC PATCH 7/8] firmware: arm_scmi: add initial support for sensor protocol

[Roy Franz]

On Wed, Jun 7, 2017 at 9:10 AM, Sudeep Holla  wrote:
> The sensor protocol provides functions to manage platform sensors, and
> provides the commands to describe the protocol version and the various
> attribute flags. It also provides commands to discover various sensors
> implemented and managed by the platform, read any sensor synchronously
> or asynchronously as allowed by the platform, program sensor attributes
> and/or configurations, if applicable.
>
> This patch adds support for most of the above features.
>
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/firmware/arm_scmi/Makefile  |   2 +-
>  drivers/firmware/arm_scmi/sensors.c | 269 
> 
>  include/linux/scmi_protocol.h   |  17 +++
>  3 files changed, 287 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/arm_scmi/sensors.c
>
> diff --git a/drivers/firmware/arm_scmi/Makefile 
> b/drivers/firmware/arm_scmi/Makefile
> index 52ecc08556a2..f9dee5ad0aa0 100644
> --- a/drivers/firmware/arm_scmi/Makefile
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_ARM_SCMI_PROTOCOL)= arm_scmi.o
> -arm_scmi-y = base.o clock.o driver.o perf.o power.o
> +arm_scmi-y = base.o clock.o driver.o perf.o power.o sensors.o
> diff --git a/drivers/firmware/arm_scmi/sensors.c 
> b/drivers/firmware/arm_scmi/sensors.c
> new file mode 100644
> index ..d8cee8c6cb99
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/sensors.c
> @@ -0,0 +1,269 @@
> +/*
> + * System Control and Management Interface (SCMI) Sensor Protocol
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program. If not, see .
> + */
> +
> +#include "common.h"
> +
> +enum scmi_sensor_protocol_cmd {
> +   SENSOR_DESCRIPTION_GET = 0x3,
> +   SENSOR_CONFIG_SET = 0x4,
> +   SENSOR_TRIP_POINT_SET = 0x5,
> +   SENSOR_READING_GET = 0x6,
> +};
> +
> +struct scmi_msg_resp_sensor_attributes {
> +   __le16 num_sensors;
> +   u8 max_requests;
> +   u8 reserved;
> +   __le32 reg_addr_low;
> +   __le32 reg_addr_high;
> +   __le32 reg_size;
> +} __packed;
> +
> +struct scmi_msg_resp_sensor_description {
> +   __le16 num_returned;
> +   __le16 num_remaining;
> +   struct {
> +   __le32 id;
> +   __le32 attributes_low;
> +#define SUPPORTS_ASYNC_READ(x) ((x) & BIT(31))
> +#define NUM_TRIP_POINTS(x) (((x) >> 4) & 0xff)
> +   __le32 attributes_high;
> +#define SENSOR_TYPE(x) ((x) & 0xff)
> +#define SENSOR_SCALE(x)(((x) >> 11) & 0x3f)
> +#define SENSOR_UPDATE_SCALE(x) (((x) >> 22) & 0x1f)
> +#define SENSOR_UPDATE_BASE(x)  (((x) >> 27) & 0x1f)
> +   u8 name[SCMI_MAX_STR_SIZE];
> +   } desc[0];
> +} __packed;
> +
> +struct scmi_msg_set_sensor_config {
> +   __le32 id;
> +   __le32 event_control;
> +} __packed;
> +
> +struct scmi_msg_set_sensor_trip_point {
> +   __le32 id;
> +   __le32 event_control;
> +#define SENSOR_TP_EVENT_MASK   (0x3)
> +#define SENSOR_TP_DISABLED 0x0
> +#define SENSOR_TP_POSITIVE 0x1
> +#define SENSOR_TP_NEGATIVE 0x2
> +#define SENSOR_TP_BOTH 0x3
> +#define SENSOR_TP_ID(x)(((x) & 0xff) << 4)
> +   __le32 value_low;
> +   __le32 value_high;
> +} __packed;
> +
> +struct scmi_msg_sensor_reading_get {
> +   __le32 id;
> +   __le32 flags;
> +#define SENSOR_READ_ASYNC  BIT(0)
> +} __packed;
> +
> +struct scmi_sensors_info {
> +   int num_sensors;
> +   int max_requests;
> +   u64 reg_addr;
> +   u32 reg_size;
> +};
> +
> +static struct scmi_sensors_info sensor_info;
> +
> +static int scmi_sensor_attributes_get(struct scmi_handle *handle,
> + struct scmi_sensors_info *sensor_info)
> +{
> +   int ret;
> +   struct scmi_xfer *t;
> +   struct scmi_msg_resp_sensor_attributes *attr;
> +
> +   ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
> +SCMI_PROTOCOL_SENSOR, 0, sizeof(*attr), );
> +   if (ret)
> +   return ret;
> +
> +   attr = (struct scmi_msg_resp_sensor_attributes *)t->rx.buf;
> +
> +   ret = scmi_do_xfer(handle, t);
> +   if (!ret) {
> +   sensor_info->num_sensors = le16_to_cpu(attr->num_sensors);
> +   

Re: [RFC PATCH 7/8] firmware: arm_scmi: add initial support for sensor protocol

[Roy Franz]

On Wed, Jun 7, 2017 at 9:10 AM, Sudeep Holla  wrote:
> The sensor protocol provides functions to manage platform sensors, and
> provides the commands to describe the protocol version and the various
> attribute flags. It also provides commands to discover various sensors
> implemented and managed by the platform, read any sensor synchronously
> or asynchronously as allowed by the platform, program sensor attributes
> and/or configurations, if applicable.
>
> This patch adds support for most of the above features.
>
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/firmware/arm_scmi/Makefile  |   2 +-
>  drivers/firmware/arm_scmi/sensors.c | 269 
> 
>  include/linux/scmi_protocol.h   |  17 +++
>  3 files changed, 287 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/arm_scmi/sensors.c
>
> diff --git a/drivers/firmware/arm_scmi/Makefile 
> b/drivers/firmware/arm_scmi/Makefile
> index 52ecc08556a2..f9dee5ad0aa0 100644
> --- a/drivers/firmware/arm_scmi/Makefile
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_ARM_SCMI_PROTOCOL)= arm_scmi.o
> -arm_scmi-y = base.o clock.o driver.o perf.o power.o
> +arm_scmi-y = base.o clock.o driver.o perf.o power.o sensors.o
> diff --git a/drivers/firmware/arm_scmi/sensors.c 
> b/drivers/firmware/arm_scmi/sensors.c
> new file mode 100644
> index ..d8cee8c6cb99
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/sensors.c
> @@ -0,0 +1,269 @@
> +/*
> + * System Control and Management Interface (SCMI) Sensor Protocol
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program. If not, see .
> + */
> +
> +#include "common.h"
> +
> +enum scmi_sensor_protocol_cmd {
> +   SENSOR_DESCRIPTION_GET = 0x3,
> +   SENSOR_CONFIG_SET = 0x4,
> +   SENSOR_TRIP_POINT_SET = 0x5,
> +   SENSOR_READING_GET = 0x6,
> +};
> +
> +struct scmi_msg_resp_sensor_attributes {
> +   __le16 num_sensors;
> +   u8 max_requests;
> +   u8 reserved;
> +   __le32 reg_addr_low;
> +   __le32 reg_addr_high;
> +   __le32 reg_size;
> +} __packed;
> +
> +struct scmi_msg_resp_sensor_description {
> +   __le16 num_returned;
> +   __le16 num_remaining;
> +   struct {
> +   __le32 id;
> +   __le32 attributes_low;
> +#define SUPPORTS_ASYNC_READ(x) ((x) & BIT(31))
> +#define NUM_TRIP_POINTS(x) (((x) >> 4) & 0xff)
> +   __le32 attributes_high;
> +#define SENSOR_TYPE(x) ((x) & 0xff)
> +#define SENSOR_SCALE(x)(((x) >> 11) & 0x3f)
> +#define SENSOR_UPDATE_SCALE(x) (((x) >> 22) & 0x1f)
> +#define SENSOR_UPDATE_BASE(x)  (((x) >> 27) & 0x1f)
> +   u8 name[SCMI_MAX_STR_SIZE];
> +   } desc[0];
> +} __packed;
> +
> +struct scmi_msg_set_sensor_config {
> +   __le32 id;
> +   __le32 event_control;
> +} __packed;
> +
> +struct scmi_msg_set_sensor_trip_point {
> +   __le32 id;
> +   __le32 event_control;
> +#define SENSOR_TP_EVENT_MASK   (0x3)
> +#define SENSOR_TP_DISABLED 0x0
> +#define SENSOR_TP_POSITIVE 0x1
> +#define SENSOR_TP_NEGATIVE 0x2
> +#define SENSOR_TP_BOTH 0x3
> +#define SENSOR_TP_ID(x)(((x) & 0xff) << 4)
> +   __le32 value_low;
> +   __le32 value_high;
> +} __packed;
> +
> +struct scmi_msg_sensor_reading_get {
> +   __le32 id;
> +   __le32 flags;
> +#define SENSOR_READ_ASYNC  BIT(0)
> +} __packed;
> +
> +struct scmi_sensors_info {
> +   int num_sensors;
> +   int max_requests;
> +   u64 reg_addr;
> +   u32 reg_size;
> +};
> +
> +static struct scmi_sensors_info sensor_info;
> +
> +static int scmi_sensor_attributes_get(struct scmi_handle *handle,
> + struct scmi_sensors_info *sensor_info)
> +{
> +   int ret;
> +   struct scmi_xfer *t;
> +   struct scmi_msg_resp_sensor_attributes *attr;
> +
> +   ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
> +SCMI_PROTOCOL_SENSOR, 0, sizeof(*attr), );
> +   if (ret)
> +   return ret;
> +
> +   attr = (struct scmi_msg_resp_sensor_attributes *)t->rx.buf;
> +
> +   ret = scmi_do_xfer(handle, t);
> +   if (!ret) {
> +   sensor_info->num_sensors = le16_to_cpu(attr->num_sensors);
> +   sensor_info->max_requests = le16_to_cpu(attr->max_requests);
> +  

Re: [RFC PATCH 2/8] firmware: arm_scmi: add basic driver infrastructure for SCMI

[Roy Franz]

On Wed, Jun 7, 2017 at 9:10 AM, Sudeep Holla  wrote:
> The SCMI is intended to allow OSPM to manage various functions that are
> provided by the hardware platform it is running on, including power and
> performance functions. SCMI provides two levels of abstraction, protocols
> and transports. Protocols define individual groups of system control and
> management messages. A protocol specification describes the messages
> that it supports. Transports describe the method by which protocol
> messages are communicated between agents and the platform.
>
> This patch adds basic infrastructure to manage the message allocation,
> initialisation, packing/unpacking and shared memory management.
>
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/firmware/Kconfig   |  21 ++
>  drivers/firmware/Makefile  |   1 +
>  drivers/firmware/arm_scmi/Makefile |   2 +
>  drivers/firmware/arm_scmi/common.h |  74 
>  drivers/firmware/arm_scmi/driver.c | 737 
> +
>  include/linux/scmi_protocol.h  |  48 +++
>  6 files changed, 883 insertions(+)
>  create mode 100644 drivers/firmware/arm_scmi/Makefile
>  create mode 100644 drivers/firmware/arm_scmi/common.h
>  create mode 100644 drivers/firmware/arm_scmi/driver.c
>  create mode 100644 include/linux/scmi_protocol.h
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 6e4ed5a9c6fd..c3d1a12763ce 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -19,6 +19,27 @@ config ARM_PSCI_CHECKER
>   on and off through hotplug, so for now torture tests and PSCI 
> checker
>   are mutually exclusive.
>
> +config ARM_SCMI_PROTOCOL
> +   tristate "ARM System Control and Management Interface (SCMI) Message 
> Protocol"
> +   depends on ARM || ARM64 || COMPILE_TEST
> +   depends on MAILBOX
> +   help
> + ARM System Control and Management Interface (SCMI) protocol is a
> + set of operating system-independent software interfaces that are
> + used in system management. SCMI is extensible and currently provides
> + interfaces for: Discovery and self-description of the interfaces
> + it supports, Power domain management which is the ability to place
> + a given device or domain into the various power-saving states that
> + it supports, Performance management which is the ability to control
> + the performance of a domain that is composed of compute engines
> + such as application processors and other accelerators, Clock
> + management which is the ability to set and inquire rates on platform
> + managed clocks and Sensor management which is the ability to read
> + sensor data, and be notified of sensor value.
> +
> + This protocol library provides interface for all the client drivers
> + making use of the features offered by the SCMI.
> +
>  config ARM_SCPI_PROTOCOL
> tristate "ARM System Control and Power Interface (SCPI) Message 
> Protocol"
> depends on ARM || ARM64 || COMPILE_TEST
> diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
> index a37f12e8d137..91d3ff62c653 100644
> --- a/drivers/firmware/Makefile
> +++ b/drivers/firmware/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_QCOM_SCM_32) += qcom_scm-32.o
>  CFLAGS_qcom_scm-32.o :=$(call as-instr,.arch armv7-a\n.arch_extension 
> sec,-DREQUIRES_SEC=1) -march=armv7-a
>  obj-$(CONFIG_TI_SCI_PROTOCOL)  += ti_sci.o
>
> +obj-$(CONFIG_ARM_SCMI_PROTOCOL)+= arm_scmi/
>  obj-y  += broadcom/
>  obj-y  += meson/
>  obj-$(CONFIG_GOOGLE_FIRMWARE)  += google/
> diff --git a/drivers/firmware/arm_scmi/Makefile 
> b/drivers/firmware/arm_scmi/Makefile
> new file mode 100644
> index ..58e94c95e523
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_ARM_SCMI_PROTOCOL)= arm_scmi.o
> +arm_scmi-y = driver.o
> diff --git a/drivers/firmware/arm_scmi/common.h 
> b/drivers/firmware/arm_scmi/common.h
> new file mode 100644
> index ..a3038efa3a8d
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -0,0 +1,74 @@
> +/*
> + * System Control and Management Interface (SCMI) Message Protocol
> + * driver common header file containing some definitions, structures
> + * and function prototypes used in all the different SCMI protocols.
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * 

Re: [RFC PATCH 2/8] firmware: arm_scmi: add basic driver infrastructure for SCMI

[Roy Franz]

On Wed, Jun 7, 2017 at 9:10 AM, Sudeep Holla  wrote:
> The SCMI is intended to allow OSPM to manage various functions that are
> provided by the hardware platform it is running on, including power and
> performance functions. SCMI provides two levels of abstraction, protocols
> and transports. Protocols define individual groups of system control and
> management messages. A protocol specification describes the messages
> that it supports. Transports describe the method by which protocol
> messages are communicated between agents and the platform.
>
> This patch adds basic infrastructure to manage the message allocation,
> initialisation, packing/unpacking and shared memory management.
>
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/firmware/Kconfig   |  21 ++
>  drivers/firmware/Makefile  |   1 +
>  drivers/firmware/arm_scmi/Makefile |   2 +
>  drivers/firmware/arm_scmi/common.h |  74 
>  drivers/firmware/arm_scmi/driver.c | 737 
> +
>  include/linux/scmi_protocol.h  |  48 +++
>  6 files changed, 883 insertions(+)
>  create mode 100644 drivers/firmware/arm_scmi/Makefile
>  create mode 100644 drivers/firmware/arm_scmi/common.h
>  create mode 100644 drivers/firmware/arm_scmi/driver.c
>  create mode 100644 include/linux/scmi_protocol.h
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 6e4ed5a9c6fd..c3d1a12763ce 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -19,6 +19,27 @@ config ARM_PSCI_CHECKER
>   on and off through hotplug, so for now torture tests and PSCI 
> checker
>   are mutually exclusive.
>
> +config ARM_SCMI_PROTOCOL
> +   tristate "ARM System Control and Management Interface (SCMI) Message 
> Protocol"
> +   depends on ARM || ARM64 || COMPILE_TEST
> +   depends on MAILBOX
> +   help
> + ARM System Control and Management Interface (SCMI) protocol is a
> + set of operating system-independent software interfaces that are
> + used in system management. SCMI is extensible and currently provides
> + interfaces for: Discovery and self-description of the interfaces
> + it supports, Power domain management which is the ability to place
> + a given device or domain into the various power-saving states that
> + it supports, Performance management which is the ability to control
> + the performance of a domain that is composed of compute engines
> + such as application processors and other accelerators, Clock
> + management which is the ability to set and inquire rates on platform
> + managed clocks and Sensor management which is the ability to read
> + sensor data, and be notified of sensor value.
> +
> + This protocol library provides interface for all the client drivers
> + making use of the features offered by the SCMI.
> +
>  config ARM_SCPI_PROTOCOL
> tristate "ARM System Control and Power Interface (SCPI) Message 
> Protocol"
> depends on ARM || ARM64 || COMPILE_TEST
> diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
> index a37f12e8d137..91d3ff62c653 100644
> --- a/drivers/firmware/Makefile
> +++ b/drivers/firmware/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_QCOM_SCM_32) += qcom_scm-32.o
>  CFLAGS_qcom_scm-32.o :=$(call as-instr,.arch armv7-a\n.arch_extension 
> sec,-DREQUIRES_SEC=1) -march=armv7-a
>  obj-$(CONFIG_TI_SCI_PROTOCOL)  += ti_sci.o
>
> +obj-$(CONFIG_ARM_SCMI_PROTOCOL)+= arm_scmi/
>  obj-y  += broadcom/
>  obj-y  += meson/
>  obj-$(CONFIG_GOOGLE_FIRMWARE)  += google/
> diff --git a/drivers/firmware/arm_scmi/Makefile 
> b/drivers/firmware/arm_scmi/Makefile
> new file mode 100644
> index ..58e94c95e523
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_ARM_SCMI_PROTOCOL)= arm_scmi.o
> +arm_scmi-y = driver.o
> diff --git a/drivers/firmware/arm_scmi/common.h 
> b/drivers/firmware/arm_scmi/common.h
> new file mode 100644
> index ..a3038efa3a8d
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -0,0 +1,74 @@
> +/*
> + * System Control and Management Interface (SCMI) Message Protocol
> + * driver common header file containing some definitions, structures
> + * and function prototypes used in all the different SCMI protocols.
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have 

Re: [PATCH v2] efi: Config options to assign versions in the PE-COFF header

[Roy Franz (HPE)]

On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin  wrote:
> On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote:
>> On 13 April 2017 at 04:58, Gary Lin  wrote:
>> > This commit adds the new config options to allow the user to modify the
>> > following fields in the PE-COFF header.
>> >
>> > UINT16 MajorOperatingSystemVersion
>> > UINT16 MinorOperatingSystemVersion
>> > UINT16 MajorImageVersion
>> > UINT16 MinorImageVersion
>> >
>> > Those fields are mainly for the executables or libraries in Windows NT
>> > or higher to specify the minimum supported Windows version and the
>> > version of the image itself.
>> >
>> > Given the fact that those fields are ignored in UEFI, we can safely reuse
>> > those fields for other purposes, e.g. Security Version(*).
>> >
>> > (*) https://github.com/lcp/shim/wiki/Security-Version
>> >
>> > v2 changes:
>> > - Modify the header direct instead of using an external script as
>> >   suggested by Ard Biesheuvel
>> > - Include arm and arm64
>> >
>>
>> Thanks for the update. Could we put the Kconfig changes in
>> drivers/firmware/efi/Kconfig, rather than duplicating them 3 times?
>
> Sure. Will send a v3 to update Kconfig.
>
> Thanks,
>
> Gary Lin

I think it would be nice to have a comment in the code (or maybe help
in the kconfig, or Documentation/efi-stub.txt) that indicates the
expected use of these variables, as the field names and PE/COFF spec
won't help here.

Thanks,
Roy

>
>>
>> > Cc: Russell King 
>> > Cc: Matt Fleming 
>> > Cc: Ard Biesheuvel 
>> > Cc: Catalin Marinas 
>> > Cc: Will Deacon 
>> > Cc: Thomas Gleixner 
>> > Cc: Ingo Molnar 
>> > Cc: "H. Peter Anvin" 
>> > Cc: Joey Lee 
>> > Cc: Vojtech Pavlik 
>> > Signed-off-by: Gary Lin 
>> > ---
>> >  arch/arm/Kconfig  | 24 
>> >  arch/arm/boot/compressed/efi-header.S |  8 
>> >  arch/arm64/Kconfig| 24 
>> >  arch/arm64/kernel/head.S  |  8 
>> >  arch/x86/Kconfig  | 24 
>> >  arch/x86/boot/header.S|  8 
>> >  6 files changed, 84 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> > index 0d4e71b42c77..4965ad2ccc23 100644
>> > --- a/arch/arm/Kconfig
>> > +++ b/arch/arm/Kconfig
>> > @@ -2090,6 +2090,30 @@ config EFI
>> >   is only useful for kernels that may run on systems that have
>> >   UEFI firmware.
>> >
>> > +config EFI_MAJOR_OS
>> > +   hex "EFI Major OS Version"
>> > +   range 0x0 0x
>> > +   default "0x0"
>> > +   depends on EFI_STUB
>> > +
>> > +config EFI_MINOR_OS
>> > +   hex "EFI Minor OS Version"
>> > +   range 0x0 0x
>> > +   default "0x0"
>> > +   depends on EFI_STUB
>> > +
>> > +config EFI_MAJOR_IMAGE
>> > +   hex "EFI Major Image Version"
>> > +   range 0x0 0x
>> > +   default "0x0"
>> > +   depends on EFI_STUB
>> > +
>> > +config EFI_MINOR_IMAGE
>> > +   hex "EFI Minor Image Version"
>> > +   range 0x0 0x
>> > +   default "0x0"
>> > +   depends on EFI_STUB
>> > +
>> >  endmenu
>> >
>> >  menu "CPU Power Management"
>> > diff --git a/arch/arm/boot/compressed/efi-header.S 
>> > b/arch/arm/boot/compressed/efi-header.S
>> > index 9d5dc4fda3c1..67715472a76f 100644
>> > --- a/arch/arm/boot/compressed/efi-header.S
>> > +++ b/arch/arm/boot/compressed/efi-header.S
>> > @@ -69,10 +69,10 @@ extra_header_fields:
>> > .long   0   @ ImageBase
>> > .long   0x200   @ SectionAlignment
>> > .long   0x200   @ FileAlignment
>> > -   .short  0   @ 
>> > MajorOperatingSystemVersion
>> > -   .short  0   @ 
>> > MinorOperatingSystemVersion
>> > -   .short  0   @ MajorImageVersion
>> > -   .short  0   @ MinorImageVersion
>> > +   .short  CONFIG_EFI_MAJOR_OS @ 
>> > MajorOperatingSystemVersion
>> > +   .short  CONFIG_EFI_MINOR_OS @ 
>> > MinorOperatingSystemVersion
>> > +   .short  CONFIG_EFI_MAJOR_IMAGE  @ MajorImageVersion
>> > +   .short  CONFIG_EFI_MINOR_IMAGE  @ MinorImageVersion
>> > .short  0   @ MajorSubsystemVersion
>> > .short  0   @ MinorSubsystemVersion
>> > .long   0   @ Win32VersionValue
>> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> > index 3741859765cf..c782c422e58c 100644
>> > --- a/arch/arm64/Kconfig
>> > +++ b/arch/arm64/Kconfig
>> > @@ 

Re: [PATCH v2] efi: Config options to assign versions in the PE-COFF header

[Roy Franz (HPE)]

On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin  wrote:
> On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote:
>> On 13 April 2017 at 04:58, Gary Lin  wrote:
>> > This commit adds the new config options to allow the user to modify the
>> > following fields in the PE-COFF header.
>> >
>> > UINT16 MajorOperatingSystemVersion
>> > UINT16 MinorOperatingSystemVersion
>> > UINT16 MajorImageVersion
>> > UINT16 MinorImageVersion
>> >
>> > Those fields are mainly for the executables or libraries in Windows NT
>> > or higher to specify the minimum supported Windows version and the
>> > version of the image itself.
>> >
>> > Given the fact that those fields are ignored in UEFI, we can safely reuse
>> > those fields for other purposes, e.g. Security Version(*).
>> >
>> > (*) https://github.com/lcp/shim/wiki/Security-Version
>> >
>> > v2 changes:
>> > - Modify the header direct instead of using an external script as
>> >   suggested by Ard Biesheuvel
>> > - Include arm and arm64
>> >
>>
>> Thanks for the update. Could we put the Kconfig changes in
>> drivers/firmware/efi/Kconfig, rather than duplicating them 3 times?
>
> Sure. Will send a v3 to update Kconfig.
>
> Thanks,
>
> Gary Lin

I think it would be nice to have a comment in the code (or maybe help
in the kconfig, or Documentation/efi-stub.txt) that indicates the
expected use of these variables, as the field names and PE/COFF spec
won't help here.

Thanks,
Roy

>
>>
>> > Cc: Russell King 
>> > Cc: Matt Fleming 
>> > Cc: Ard Biesheuvel 
>> > Cc: Catalin Marinas 
>> > Cc: Will Deacon 
>> > Cc: Thomas Gleixner 
>> > Cc: Ingo Molnar 
>> > Cc: "H. Peter Anvin" 
>> > Cc: Joey Lee 
>> > Cc: Vojtech Pavlik 
>> > Signed-off-by: Gary Lin 
>> > ---
>> >  arch/arm/Kconfig  | 24 
>> >  arch/arm/boot/compressed/efi-header.S |  8 
>> >  arch/arm64/Kconfig| 24 
>> >  arch/arm64/kernel/head.S  |  8 
>> >  arch/x86/Kconfig  | 24 
>> >  arch/x86/boot/header.S|  8 
>> >  6 files changed, 84 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> > index 0d4e71b42c77..4965ad2ccc23 100644
>> > --- a/arch/arm/Kconfig
>> > +++ b/arch/arm/Kconfig
>> > @@ -2090,6 +2090,30 @@ config EFI
>> >   is only useful for kernels that may run on systems that have
>> >   UEFI firmware.
>> >
>> > +config EFI_MAJOR_OS
>> > +   hex "EFI Major OS Version"
>> > +   range 0x0 0x
>> > +   default "0x0"
>> > +   depends on EFI_STUB
>> > +
>> > +config EFI_MINOR_OS
>> > +   hex "EFI Minor OS Version"
>> > +   range 0x0 0x
>> > +   default "0x0"
>> > +   depends on EFI_STUB
>> > +
>> > +config EFI_MAJOR_IMAGE
>> > +   hex "EFI Major Image Version"
>> > +   range 0x0 0x
>> > +   default "0x0"
>> > +   depends on EFI_STUB
>> > +
>> > +config EFI_MINOR_IMAGE
>> > +   hex "EFI Minor Image Version"
>> > +   range 0x0 0x
>> > +   default "0x0"
>> > +   depends on EFI_STUB
>> > +
>> >  endmenu
>> >
>> >  menu "CPU Power Management"
>> > diff --git a/arch/arm/boot/compressed/efi-header.S 
>> > b/arch/arm/boot/compressed/efi-header.S
>> > index 9d5dc4fda3c1..67715472a76f 100644
>> > --- a/arch/arm/boot/compressed/efi-header.S
>> > +++ b/arch/arm/boot/compressed/efi-header.S
>> > @@ -69,10 +69,10 @@ extra_header_fields:
>> > .long   0   @ ImageBase
>> > .long   0x200   @ SectionAlignment
>> > .long   0x200   @ FileAlignment
>> > -   .short  0   @ 
>> > MajorOperatingSystemVersion
>> > -   .short  0   @ 
>> > MinorOperatingSystemVersion
>> > -   .short  0   @ MajorImageVersion
>> > -   .short  0   @ MinorImageVersion
>> > +   .short  CONFIG_EFI_MAJOR_OS @ 
>> > MajorOperatingSystemVersion
>> > +   .short  CONFIG_EFI_MINOR_OS @ 
>> > MinorOperatingSystemVersion
>> > +   .short  CONFIG_EFI_MAJOR_IMAGE  @ MajorImageVersion
>> > +   .short  CONFIG_EFI_MINOR_IMAGE  @ MinorImageVersion
>> > .short  0   @ MajorSubsystemVersion
>> > .short  0   @ MinorSubsystemVersion
>> > .long   0   @ Win32VersionValue
>> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> > index 3741859765cf..c782c422e58c 100644
>> > --- a/arch/arm64/Kconfig
>> > +++ b/arch/arm64/Kconfig
>> > @@ -1033,6 +1033,30 @@ config EFI
>> >   allow the kernel to be booted as an EFI application. This
>> >   is only useful on systems that have UEFI firmware.
>> >
>> > +config EFI_MAJOR_OS
>> > +   hex "EFI Major OS Version"
>> > +   range 

[tip:efi/core] efi/libstub: Fix allocation size calculations

[tip-bot for Roy Franz]

Commit-ID:  5b88a31c222c47cb8997021cc8a576927ba0e77f
Gitweb: http://git.kernel.org/tip/5b88a31c222c47cb8997021cc8a576927ba0e77f
Author: Roy Franz <roy.fr...@hpe.com>
AuthorDate: Sat, 12 Nov 2016 21:32:29 +
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Sun, 13 Nov 2016 08:23:14 +0100

efi/libstub: Fix allocation size calculations

Adjust the size used in calculations to match the actual size of allocation
that will be performed based on EFI size/alignment constraints.
efi_high_alloc() and efi_low_alloc() use the passed size in bytes directly
to find space in the memory map for the allocation, rather than the actual
allocation size that has been adjusted for size and alignment constraints.
This results in failed allocations and retries in efi_high_alloc().  The
same error is present in efi_low_alloc(), although failure will only happen
if the lowest memory block is small.
Also use EFI_PAGE_SIZE consistently and remove use of EFI_PAGE_SHIFT to
calculate page size.

Signed-off-by: Roy Franz <roy.fr...@hpe.com>
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20161112213237.8804-2-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 drivers/firmware/efi/libstub/efi-stub-helper.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index aded106..4b74bf8 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -186,14 +186,16 @@ efi_status_t efi_high_alloc(efi_system_table_t 
*sys_table_arg,
goto fail;
 
/*
-* Enforce minimum alignment that EFI requires when requesting
-* a specific address.  We are doing page-based allocations,
-* so we must be aligned to a page.
+* Enforce minimum alignment that EFI or Linux requires when
+* requesting a specific address.  We are doing page-based (or
+* larger) allocations, and both the address and size must meet
+* alignment constraints.
 */
if (align < EFI_ALLOC_ALIGN)
align = EFI_ALLOC_ALIGN;
 
-   nr_pages = round_up(size, EFI_ALLOC_ALIGN) / EFI_PAGE_SIZE;
+   size = round_up(size, EFI_ALLOC_ALIGN);
+   nr_pages = size / EFI_PAGE_SIZE;
 again:
for (i = 0; i < map_size / desc_size; i++) {
efi_memory_desc_t *desc;
@@ -208,7 +210,7 @@ again:
continue;
 
start = desc->phys_addr;
-   end = start + desc->num_pages * (1UL << EFI_PAGE_SHIFT);
+   end = start + desc->num_pages * EFI_PAGE_SIZE;
 
if (end > max)
end = max;
@@ -278,14 +280,16 @@ efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
goto fail;
 
/*
-* Enforce minimum alignment that EFI requires when requesting
-* a specific address.  We are doing page-based allocations,
-* so we must be aligned to a page.
+* Enforce minimum alignment that EFI or Linux requires when
+* requesting a specific address.  We are doing page-based (or
+* larger) allocations, and both the address and size must meet
+* alignment constraints.
 */
if (align < EFI_ALLOC_ALIGN)
align = EFI_ALLOC_ALIGN;
 
-   nr_pages = round_up(size, EFI_ALLOC_ALIGN) / EFI_PAGE_SIZE;
+   size = round_up(size, EFI_ALLOC_ALIGN);
+   nr_pages = size / EFI_PAGE_SIZE;
for (i = 0; i < map_size / desc_size; i++) {
efi_memory_desc_t *desc;
unsigned long m = (unsigned long)map;
@@ -300,7 +304,7 @@ efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
continue;
 
start = desc->phys_addr;
-   end = start + desc->num_pages * (1UL << EFI_PAGE_SHIFT);
+   end = start + desc->num_pages * EFI_PAGE_SIZE;
 
/*
 * Don't allocate at 0x0. It will confuse code that

[tip:efi/core] efi/libstub: Fix allocation size calculations

[tip-bot for Roy Franz]

Commit-ID:  5b88a31c222c47cb8997021cc8a576927ba0e77f
Gitweb: http://git.kernel.org/tip/5b88a31c222c47cb8997021cc8a576927ba0e77f
Author: Roy Franz 
AuthorDate: Sat, 12 Nov 2016 21:32:29 +
Committer:  Ingo Molnar 
CommitDate: Sun, 13 Nov 2016 08:23:14 +0100

efi/libstub: Fix allocation size calculations

Adjust the size used in calculations to match the actual size of allocation
that will be performed based on EFI size/alignment constraints.
efi_high_alloc() and efi_low_alloc() use the passed size in bytes directly
to find space in the memory map for the allocation, rather than the actual
allocation size that has been adjusted for size and alignment constraints.
This results in failed allocations and retries in efi_high_alloc().  The
same error is present in efi_low_alloc(), although failure will only happen
if the lowest memory block is small.
Also use EFI_PAGE_SIZE consistently and remove use of EFI_PAGE_SHIFT to
calculate page size.

Signed-off-by: Roy Franz 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20161112213237.8804-2-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/libstub/efi-stub-helper.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index aded106..4b74bf8 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -186,14 +186,16 @@ efi_status_t efi_high_alloc(efi_system_table_t 
*sys_table_arg,
goto fail;
 
/*
-* Enforce minimum alignment that EFI requires when requesting
-* a specific address.  We are doing page-based allocations,
-* so we must be aligned to a page.
+* Enforce minimum alignment that EFI or Linux requires when
+* requesting a specific address.  We are doing page-based (or
+* larger) allocations, and both the address and size must meet
+* alignment constraints.
 */
if (align < EFI_ALLOC_ALIGN)
align = EFI_ALLOC_ALIGN;
 
-   nr_pages = round_up(size, EFI_ALLOC_ALIGN) / EFI_PAGE_SIZE;
+   size = round_up(size, EFI_ALLOC_ALIGN);
+   nr_pages = size / EFI_PAGE_SIZE;
 again:
for (i = 0; i < map_size / desc_size; i++) {
efi_memory_desc_t *desc;
@@ -208,7 +210,7 @@ again:
continue;
 
start = desc->phys_addr;
-   end = start + desc->num_pages * (1UL << EFI_PAGE_SHIFT);
+   end = start + desc->num_pages * EFI_PAGE_SIZE;
 
if (end > max)
end = max;
@@ -278,14 +280,16 @@ efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
goto fail;
 
/*
-* Enforce minimum alignment that EFI requires when requesting
-* a specific address.  We are doing page-based allocations,
-* so we must be aligned to a page.
+* Enforce minimum alignment that EFI or Linux requires when
+* requesting a specific address.  We are doing page-based (or
+* larger) allocations, and both the address and size must meet
+* alignment constraints.
 */
if (align < EFI_ALLOC_ALIGN)
align = EFI_ALLOC_ALIGN;
 
-   nr_pages = round_up(size, EFI_ALLOC_ALIGN) / EFI_PAGE_SIZE;
+   size = round_up(size, EFI_ALLOC_ALIGN);
+   nr_pages = size / EFI_PAGE_SIZE;
for (i = 0; i < map_size / desc_size; i++) {
efi_memory_desc_t *desc;
unsigned long m = (unsigned long)map;
@@ -300,7 +304,7 @@ efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
continue;
 
start = desc->phys_addr;
-   end = start + desc->num_pages * (1UL << EFI_PAGE_SHIFT);
+   end = start + desc->num_pages * EFI_PAGE_SIZE;
 
/*
 * Don't allocate at 0x0. It will confuse code that

Re: [PATCH v5 0/1] ARM64: ACPI: Update documentation for latest specification version

[Roy Franz (HPE)]

On Mon, May 2, 2016 at 1:19 PM, Al Stone <a...@redhat.com> wrote:
> On 04/25/2016 03:21 PM, Al Stone wrote:
>> The ACPI 6.1 specification was recently released at the end of January
>> 2016, but the arm64 kernel documentation for the use of ACPI was written
>> for the 5.1 version of the spec.  There were significant additions to the
>> spec that had not yet been mentioned -- for example, the 6.0 mechanisms
>> added to make it easier to define processors and low power idle states,
>> as well as the 6.1 addition allowing regular interrupts (not just from
>> GPIO) be used to signal ACPI general purpose events.
>>
>> This patch reflects going back through and examining the specs in detail
>> and updating content appropriately.  Whilst there, a few odds and ends of
>> typos were caught as well.  This brings the documentation up to date with
>> ACPI 6.1 for arm64.
>>
>> Changes for v5:
>>-- Miscellaneous typos and corrections (Lorenzo Pieralisi)
>>-- Add linux-acpi@ ML to the distribution list (Alexey Klimov)
>>-- Corrections to CPPC information (Alexey Klimov)
>>-- ACK from Lorenzo Pieralisi
>>-- Updated bibliographic info (Al Stone)
>>
>> Changes for v4:
>>-- Clarify that IORT can sometimes be optional (Jon Masters).
>>-- Remove "Use as needed" descriptions of ACPI objects; they provide
>>   no substantive information and doing so simplifies maintenance of
>>   this document over time.  These have been replaced with a simpler
>>   notice that states that unless otherwise noted, do what the ACPI
>>   specification says is needed.
>>-- Corrected the _OSI object usage recommendation; it described kernel
>>   behavior that does not exist (Al Stone).
>>
>> Changes for v3:
>>-- Clarify use of _LPI/_RDI (Vikas Sajjan)
>>-- Whitespace cleanup as pointed out by checkpatch
>>
>> Changes for v2:
>>-- Clean up white space (Harb Abdulhahmid)
>>-- Clarification on _CCA usage (Harb Abdulhamid)
>>-- IORT moved to required from recommended (Hanjun Guo)
>>-- Clarify IORT description (Hanjun Guo)
>>
>>
>> Al Stone (1):
>>   ARM64: ACPI: Update documentation for latest specification version
>>
>>  Documentation/arm64/acpi_object_usage.txt | 343 
>> --
>>  Documentation/arm64/arm-acpi.txt  |  40 ++--
>>  2 files changed, 213 insertions(+), 170 deletions(-)
>>
>
> Ping?  If there are no further comments, can this be pulled in through
> either the documentation or arm64 tree?
>
> Thanks.

I've read through this - looks good to me.  I think it provides useful
guidance to
reference as we work on getting good ACPI support provided by various platforms
under development.

Reviewed-by: Roy Franz <roy.fr...@hpe.com>

>
> --
> ciao,
> al
> ---
> Al Stone
> Software Engineer
> Red Hat, Inc.
> a...@redhat.com
> ---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/1] ARM64: ACPI: Update documentation for latest specification version

[Roy Franz (HPE)]

On Mon, May 2, 2016 at 1:19 PM, Al Stone  wrote:
> On 04/25/2016 03:21 PM, Al Stone wrote:
>> The ACPI 6.1 specification was recently released at the end of January
>> 2016, but the arm64 kernel documentation for the use of ACPI was written
>> for the 5.1 version of the spec.  There were significant additions to the
>> spec that had not yet been mentioned -- for example, the 6.0 mechanisms
>> added to make it easier to define processors and low power idle states,
>> as well as the 6.1 addition allowing regular interrupts (not just from
>> GPIO) be used to signal ACPI general purpose events.
>>
>> This patch reflects going back through and examining the specs in detail
>> and updating content appropriately.  Whilst there, a few odds and ends of
>> typos were caught as well.  This brings the documentation up to date with
>> ACPI 6.1 for arm64.
>>
>> Changes for v5:
>>-- Miscellaneous typos and corrections (Lorenzo Pieralisi)
>>-- Add linux-acpi@ ML to the distribution list (Alexey Klimov)
>>-- Corrections to CPPC information (Alexey Klimov)
>>-- ACK from Lorenzo Pieralisi
>>-- Updated bibliographic info (Al Stone)
>>
>> Changes for v4:
>>-- Clarify that IORT can sometimes be optional (Jon Masters).
>>-- Remove "Use as needed" descriptions of ACPI objects; they provide
>>   no substantive information and doing so simplifies maintenance of
>>   this document over time.  These have been replaced with a simpler
>>   notice that states that unless otherwise noted, do what the ACPI
>>   specification says is needed.
>>-- Corrected the _OSI object usage recommendation; it described kernel
>>   behavior that does not exist (Al Stone).
>>
>> Changes for v3:
>>-- Clarify use of _LPI/_RDI (Vikas Sajjan)
>>-- Whitespace cleanup as pointed out by checkpatch
>>
>> Changes for v2:
>>-- Clean up white space (Harb Abdulhahmid)
>>-- Clarification on _CCA usage (Harb Abdulhamid)
>>-- IORT moved to required from recommended (Hanjun Guo)
>>-- Clarify IORT description (Hanjun Guo)
>>
>>
>> Al Stone (1):
>>   ARM64: ACPI: Update documentation for latest specification version
>>
>>  Documentation/arm64/acpi_object_usage.txt | 343 
>> --
>>  Documentation/arm64/arm-acpi.txt  |  40 ++--
>>  2 files changed, 213 insertions(+), 170 deletions(-)
>>
>
> Ping?  If there are no further comments, can this be pulled in through
> either the documentation or arm64 tree?
>
> Thanks.

I've read through this - looks good to me.  I think it provides useful
guidance to
reference as we work on getting good ACPI support provided by various platforms
under development.

Reviewed-by: Roy Franz 

>
> --
> ciao,
> al
> ---
> Al Stone
> Software Engineer
> Red Hat, Inc.
> a...@redhat.com
> ---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch v2 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Roy Franz]

On Mon, Apr 20, 2015 at 3:19 AM, Ivan Khoronzhuk
 wrote:
> Some utils, like dmidecode and smbios, need to access SMBIOS entry
> table area in order to get information like SMBIOS version, size, etc.
> Currently it's done via /dev/mem. But for situation when /dev/mem
> usage is disabled, the utils have to use dmi sysfs instead, which
> doesn't represent SMBIOS entry and adds code/delay redundancy when direct
> access for table is needed.
>
> So this patch creates dmi/tables and adds SMBIOS entry point to allow
> utils in question to work correctly without /dev/mem. Also patch adds
> raw dmi table to simplify dmi table processing in user space, as
> proposed by Jean Delvare.
>
> Signed-off-by: Ivan Khoronzhuk 

Tested-by: Roy Franz 

Tested with dmidecode w/patches to read tables from sysfs.  The dmidecode
patches are posted on dmidecode-devel and should be commited upstream soon.

Thanks,
Roy

> ---
>  .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
>  drivers/firmware/dmi-sysfs.c   | 17 +++--
>  drivers/firmware/dmi_scan.c| 82 
> ++
>  include/linux/dmi.h|  2 +
>  4 files changed, 114 insertions(+), 9 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables 
> b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
> new file mode 100644
> index 000..ff3cac8
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
> @@ -0,0 +1,22 @@
> +What:  /sys/firmware/dmi/tables/
> +Date:  April 2015
> +Contact:   Ivan Khoronzhuk 
> +Description:
> +   The firmware provides DMI structures as a packed list of
> +   data referenced by a SMBIOS table entry point. The SMBIOS
> +   entry point contains general information, like SMBIOS
> +   version, DMI table size, etc. The structure, content and
> +   size of SMBIOS entry point is dependent on SMBIOS version.
> +   The format of SMBIOS entry point and DMI structures
> +   can be read in SMBIOS specification.
> +
> +   The dmi/tables provides raw SMBIOS entry point and DMI tables
> +   through sysfs as an alternative to utilities reading them
> +   from /dev/mem. The raw SMBIOS entry point and DMI table are
> +   presented as binary attributes and are accessible via:
> +
> +   /sys/firmware/dmi/tables/smbios_entry_point
> +   /sys/firmware/dmi/tables/DMI
> +
> +   The complete DMI information can be obtained using these two
> +   tables.
> diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
> index e0f1cb3..ef76e5e 100644
> --- a/drivers/firmware/dmi-sysfs.c
> +++ b/drivers/firmware/dmi-sysfs.c
> @@ -566,7 +566,6 @@ static struct kobj_type dmi_sysfs_entry_ktype = {
> .default_attrs = dmi_sysfs_entry_attrs,
>  };
>
> -static struct kobject *dmi_kobj;
>  static struct kset *dmi_kset;
>
>  /* Global count of all instances seen.  Only for setup */
> @@ -648,17 +647,20 @@ static void cleanup_entry_list(void)
>
>  static int __init dmi_sysfs_init(void)
>  {
> -   int error = -ENOMEM;
> +   int error;
> int val;
>
> -   /* Set up our directory */
> -   dmi_kobj = kobject_create_and_add("dmi", firmware_kobj);
> -   if (!dmi_kobj)
> +   if (!dmi_kobj) {
> +   pr_err("dmi-sysfs: dmi entry is absent.\n");
> +   error = -ENODATA;
> goto err;
> +   }
>
> dmi_kset = kset_create_and_add("entries", NULL, dmi_kobj);
> -   if (!dmi_kset)
> +   if (!dmi_kset) {
> +   error = -ENOMEM;
> goto err;
> +   }
>
> val = 0;
> error = dmi_walk(dmi_sysfs_register_handle, );
> @@ -675,7 +677,6 @@ static int __init dmi_sysfs_init(void)
>  err:
> cleanup_entry_list();
> kset_unregister(dmi_kset);
> -   kobject_put(dmi_kobj);
> return error;
>  }
>
> @@ -685,8 +686,6 @@ static void __exit dmi_sysfs_exit(void)
> pr_debug("dmi-sysfs: unloading.\n");
> cleanup_entry_list();
> kset_unregister(dmi_kset);
> -   kobject_del(dmi_kobj);
> -   kobject_put(dmi_kobj);
>  }
>
>  module_init(dmi_sysfs_init);
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index a864a6b..9705be2 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -10,6 +10,9 @@
>

Re: [Patch v2 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Roy Franz]

On Mon, Apr 20, 2015 at 3:19 AM, Ivan Khoronzhuk
ivan.khoronz...@globallogic.com wrote:
 Some utils, like dmidecode and smbios, need to access SMBIOS entry
 table area in order to get information like SMBIOS version, size, etc.
 Currently it's done via /dev/mem. But for situation when /dev/mem
 usage is disabled, the utils have to use dmi sysfs instead, which
 doesn't represent SMBIOS entry and adds code/delay redundancy when direct
 access for table is needed.

 So this patch creates dmi/tables and adds SMBIOS entry point to allow
 utils in question to work correctly without /dev/mem. Also patch adds
 raw dmi table to simplify dmi table processing in user space, as
 proposed by Jean Delvare.

 Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@globallogic.com

Tested-by: Roy Franz roy.fr...@linaro.org

Tested with dmidecode w/patches to read tables from sysfs.  The dmidecode
patches are posted on dmidecode-devel and should be commited upstream soon.

Thanks,
Roy

 ---
  .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
  drivers/firmware/dmi-sysfs.c   | 17 +++--
  drivers/firmware/dmi_scan.c| 82 
 ++
  include/linux/dmi.h|  2 +
  4 files changed, 114 insertions(+), 9 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables

 diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables 
 b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
 new file mode 100644
 index 000..ff3cac8
 --- /dev/null
 +++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
 @@ -0,0 +1,22 @@
 +What:  /sys/firmware/dmi/tables/
 +Date:  April 2015
 +Contact:   Ivan Khoronzhuk ivan.khoronz...@globallogic.com
 +Description:
 +   The firmware provides DMI structures as a packed list of
 +   data referenced by a SMBIOS table entry point. The SMBIOS
 +   entry point contains general information, like SMBIOS
 +   version, DMI table size, etc. The structure, content and
 +   size of SMBIOS entry point is dependent on SMBIOS version.
 +   The format of SMBIOS entry point and DMI structures
 +   can be read in SMBIOS specification.
 +
 +   The dmi/tables provides raw SMBIOS entry point and DMI tables
 +   through sysfs as an alternative to utilities reading them
 +   from /dev/mem. The raw SMBIOS entry point and DMI table are
 +   presented as binary attributes and are accessible via:
 +
 +   /sys/firmware/dmi/tables/smbios_entry_point
 +   /sys/firmware/dmi/tables/DMI
 +
 +   The complete DMI information can be obtained using these two
 +   tables.
 diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
 index e0f1cb3..ef76e5e 100644
 --- a/drivers/firmware/dmi-sysfs.c
 +++ b/drivers/firmware/dmi-sysfs.c
 @@ -566,7 +566,6 @@ static struct kobj_type dmi_sysfs_entry_ktype = {
 .default_attrs = dmi_sysfs_entry_attrs,
  };

 -static struct kobject *dmi_kobj;
  static struct kset *dmi_kset;

  /* Global count of all instances seen.  Only for setup */
 @@ -648,17 +647,20 @@ static void cleanup_entry_list(void)

  static int __init dmi_sysfs_init(void)
  {
 -   int error = -ENOMEM;
 +   int error;
 int val;

 -   /* Set up our directory */
 -   dmi_kobj = kobject_create_and_add(dmi, firmware_kobj);
 -   if (!dmi_kobj)
 +   if (!dmi_kobj) {
 +   pr_err(dmi-sysfs: dmi entry is absent.\n);
 +   error = -ENODATA;
 goto err;
 +   }

 dmi_kset = kset_create_and_add(entries, NULL, dmi_kobj);
 -   if (!dmi_kset)
 +   if (!dmi_kset) {
 +   error = -ENOMEM;
 goto err;
 +   }

 val = 0;
 error = dmi_walk(dmi_sysfs_register_handle, val);
 @@ -675,7 +677,6 @@ static int __init dmi_sysfs_init(void)
  err:
 cleanup_entry_list();
 kset_unregister(dmi_kset);
 -   kobject_put(dmi_kobj);
 return error;
  }

 @@ -685,8 +686,6 @@ static void __exit dmi_sysfs_exit(void)
 pr_debug(dmi-sysfs: unloading.\n);
 cleanup_entry_list();
 kset_unregister(dmi_kset);
 -   kobject_del(dmi_kobj);
 -   kobject_put(dmi_kobj);
  }

  module_init(dmi_sysfs_init);
 diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
 index a864a6b..9705be2 100644
 --- a/drivers/firmware/dmi_scan.c
 +++ b/drivers/firmware/dmi_scan.c
 @@ -10,6 +10,9 @@
  #include asm/dmi.h
  #include asm/unaligned.h

 +struct kobject *dmi_kobj;
 +EXPORT_SYMBOL_GPL(dmi_kobj);
 +
  /*
   * DMI stands for Desktop Management Interface.  It is part
   * of and an antecedent to, SMBIOS, which stands for System
 @@ -20,6 +23,9 @@ static const char dmi_empty_string[] = ;
  static u32 dmi_ver __initdata;
  static u32 dmi_len;
  static u16

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Roy Franz]

On Wed, Apr 15, 2015 at 11:48 PM, Jean Delvare  wrote:
> Hi Roy,
>
> On Wed, 15 Apr 2015 17:54:51 -0700, Roy Franz wrote:
>> On Tue, Apr 14, 2015 at 9:19 PM, Roy Franz  wrote:
>> > I have made modifications to dmidecode to support this interface, and it
>> > works quite nicely for dmidecode. (changes posted to dmidecode-devel list)
>> > The only open issue I am aware of is how the SMBIOS v3 entry point
>> > will be handled,
>> > especially in cases where there is a v2 and a v3 entry point.
>> > In principal I think this a good change - are there any other open issues?
>>
>> I looked at the SMBIOS spec again, and the platform can provide either or
>> both of the 32-bit and 64-bit entry points.  The spec says that an
>> implementation
>> "should" provide a 32-bit entry point for compatibility.
>>
>> These 2 entry point structures can both point to the same SMBIOS
>> structure table,
>> or two distinct ones.  If distinct, the one referenced by the 32-bit
>> entry point must be
>> a consistent subset of the 64-bit one.
>> There does not seem to be any prohibition from using new SMBIOS v3 structures
>> in a table referenced by a 32-bit entry point, so backwards
>> compatibility is completely
>> up to the implementation.
>
> What do you mean with "new SMBIOS v3 structures"? I took a brief look
> at the change log at the end of the SMBIOS 3.0.0 specification, and all
> I can see are new enumerated values for existing fields, as well as 3
> new fields in the type 4 structure. I can't see any new structure type.
> Either way this is all backwards compatible, which is why both entry
> points can point to the same table.
Sorry, I used that imprecisely - I was referring to the new things defined
in the 3.0 specification in addition to the new entry point.  It sounds like
there is not much.
>
>> Since the point of this patchset (and related changes to dmidecode) is
>> to provide the
>> SMBIOS information without using /dev/mem, I think the interface we
>> define should
>> support all the cases outlined in the specification.  I would like to
>> avoid a case where
>> we're back to using /dev/mem to deal with the dual entry/dual table
>> case if that becomes
>> important down the road.
>>
>> Here's a proposal for files in /sys/firmware/dmi/tables:
>>
>> smbios_entry_point32   -  32 bit (existing entry point type), if it exists.
>> smbios_entry_point64   -  64 bit entry, new in SMBIOS v3.0
>> DMI32 -  smbios structure tables referenced by
>> 32 bit entry point, if it exists
>> DMI64 -  smbios structure tables referenced by
>> 64 bit entry point, if it exists.
>>  symlink to DMI32 if identical
>> smbios_entry_point- symlink to smbios_entry_point64 if it exists,
>> otherwise symlink to smbios_entry_point64
>> DMI   - symlink to DMI64 if it exists,
>> otherwise symlink to DMI32
>>
>> These last two would provide names to the 'preferred' tables, and
>> names that would always exist on all systems, which
>> I think is a nice property to have.
>>
>> Thoughts?
>
> The idea was discussed before, and discarded. The question is, what use
> cases do you envision from a user-space application perspective? As you
> found out, the table pointed to by the _SM3_ entry point must be a
> super-set of the one pointed to by the _SM_ entry point, so for a
> compliant implementation there is no reason to follow the _SM_ entry
> point when both exist. And if only one entry point exists, there is
> nothing to choose from.
>
> The kernel itself will have to choose one of the entry points when it
> comes to dmi_scan and dmi-id. It can't provide two sets of DMI strings.
> So it seems reasonable to only expose though sysfs that one entry point
> and table that the kernel itself used.
>
> The only case where it would make some sense to expose everything to
> user-space is for BIOS debugging purpose: if both entry points exist
> and point to different tables, and if the _SM3_ table is broken and
> the _SM_ table is correct, then you may want to be able to temporarily
> read the _SM_ table instead of the _SM3_ table, to check what needs to
> be fixed in the latter. But I would argue that this is beyond the scope
> of our code: neither the kernel nor dmidecode are DMI table or BIOS
> authoring tools.
>
> If there really ever is a need to ignore the _SM3_ entry point, I'd
> rather have a kernel boot parameter for this. This would guarantee that
> the kernel and user-space applications always

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Roy Franz]

On Wed, Apr 15, 2015 at 11:48 PM, Jean Delvare jdelv...@suse.de wrote:
 Hi Roy,

 On Wed, 15 Apr 2015 17:54:51 -0700, Roy Franz wrote:
 On Tue, Apr 14, 2015 at 9:19 PM, Roy Franz roy.fr...@linaro.org wrote:
  I have made modifications to dmidecode to support this interface, and it
  works quite nicely for dmidecode. (changes posted to dmidecode-devel list)
  The only open issue I am aware of is how the SMBIOS v3 entry point
  will be handled,
  especially in cases where there is a v2 and a v3 entry point.
  In principal I think this a good change - are there any other open issues?

 I looked at the SMBIOS spec again, and the platform can provide either or
 both of the 32-bit and 64-bit entry points.  The spec says that an
 implementation
 should provide a 32-bit entry point for compatibility.

 These 2 entry point structures can both point to the same SMBIOS
 structure table,
 or two distinct ones.  If distinct, the one referenced by the 32-bit
 entry point must be
 a consistent subset of the 64-bit one.
 There does not seem to be any prohibition from using new SMBIOS v3 structures
 in a table referenced by a 32-bit entry point, so backwards
 compatibility is completely
 up to the implementation.

 What do you mean with new SMBIOS v3 structures? I took a brief look
 at the change log at the end of the SMBIOS 3.0.0 specification, and all
 I can see are new enumerated values for existing fields, as well as 3
 new fields in the type 4 structure. I can't see any new structure type.
 Either way this is all backwards compatible, which is why both entry
 points can point to the same table.
Sorry, I used that imprecisely - I was referring to the new things defined
in the 3.0 specification in addition to the new entry point.  It sounds like
there is not much.

 Since the point of this patchset (and related changes to dmidecode) is
 to provide the
 SMBIOS information without using /dev/mem, I think the interface we
 define should
 support all the cases outlined in the specification.  I would like to
 avoid a case where
 we're back to using /dev/mem to deal with the dual entry/dual table
 case if that becomes
 important down the road.

 Here's a proposal for files in /sys/firmware/dmi/tables:

 smbios_entry_point32   -  32 bit (existing entry point type), if it exists.
 smbios_entry_point64   -  64 bit entry, new in SMBIOS v3.0
 DMI32 -  smbios structure tables referenced by
 32 bit entry point, if it exists
 DMI64 -  smbios structure tables referenced by
 64 bit entry point, if it exists.
  symlink to DMI32 if identical
 smbios_entry_point- symlink to smbios_entry_point64 if it exists,
 otherwise symlink to smbios_entry_point64
 DMI   - symlink to DMI64 if it exists,
 otherwise symlink to DMI32

 These last two would provide names to the 'preferred' tables, and
 names that would always exist on all systems, which
 I think is a nice property to have.

 Thoughts?

 The idea was discussed before, and discarded. The question is, what use
 cases do you envision from a user-space application perspective? As you
 found out, the table pointed to by the _SM3_ entry point must be a
 super-set of the one pointed to by the _SM_ entry point, so for a
 compliant implementation there is no reason to follow the _SM_ entry
 point when both exist. And if only one entry point exists, there is
 nothing to choose from.

 The kernel itself will have to choose one of the entry points when it
 comes to dmi_scan and dmi-id. It can't provide two sets of DMI strings.
 So it seems reasonable to only expose though sysfs that one entry point
 and table that the kernel itself used.

 The only case where it would make some sense to expose everything to
 user-space is for BIOS debugging purpose: if both entry points exist
 and point to different tables, and if the _SM3_ table is broken and
 the _SM_ table is correct, then you may want to be able to temporarily
 read the _SM_ table instead of the _SM3_ table, to check what needs to
 be fixed in the latter. But I would argue that this is beyond the scope
 of our code: neither the kernel nor dmidecode are DMI table or BIOS
 authoring tools.

 If there really ever is a need to ignore the _SM3_ entry point, I'd
 rather have a kernel boot parameter for this. This would guarantee that
 the kernel and user-space applications always operate on the same data.

 So I would keep the sysfs interface simple, as Ivan implemented it.

Apologies for missing that previous discussion - I was intentionally
bringing an old topic up.
I don't feel strongly, and I think the main use case is debugging
something in the future,
as it doesn't address any current problems. My main motivation for
proposing this was to
avoid a future case where the answer is just map /dev/mem.  This is
acceptable if the only
people doing it are developers debugging a BIOS/UEFI problem, but I
don't think this is the
right answer

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Roy Franz]

On Tue, Apr 14, 2015 at 9:19 PM, Roy Franz  wrote:
> On Fri, Apr 3, 2015 at 2:36 AM, Ivan.khoronzhuk
>  wrote:
>>
>>
>> On 02.04.15 15:57, Ivan Khoronzhuk wrote:
>>>
>>> Some utils, like dmidecode and smbios, need to access SMBIOS entry
>>> table area in order to get information like SMBIOS version, size, etc.
>>> Currently it's done via /dev/mem. But for situation when /dev/mem
>>> usage is disabled, the utils have to use dmi sysfs instead, which
>>> doesn't represent SMBIOS entry and adds code/delay redundancy when direct
>>> access for table is needed.
>>>
>>> So this patch creates dmi/tables and adds SMBIOS entry point to allow
>>> utils in question to work correctly without /dev/mem. Also patch adds
>>> raw dmi table to simplify dmi table processing in user space, as
>>> proposed by Jean Delvare.
>>>
>
> I have made modifications to dmidecode to support this interface, and it
> works quite nicely for dmidecode. (changes posted to dmidecode-devel list)
> The only open issue I am aware of is how the SMBIOS v3 entry point
> will be handled,
> especially in cases where there is a v2 and a v3 entry point.
> In principal I think this a good change - are there any other open issues?
>
> Thanks,
> Roy
>

I looked at the SMBIOS spec again, and the platform can provide either or
both of the 32-bit and 64-bit entry points.  The spec says that an
implementation
"should" provide a 32-bit entry point for compatibility.

These 2 entry point structures can both point to the same SMBIOS
structure table,
or two distinct ones.  If distinct, the one referenced by the 32-bit
entry point must be
a consistent subset of the 64-bit one.
There does not seem to be any prohibition from using new SMBIOS v3 structures
in a table referenced by a 32-bit entry point, so backwards
compatibility is completely
up to the implementation.

Since the point of this patchset (and related changes to dmidecode) is
to provide the
SMBIOS information without using /dev/mem, I think the interface we
define should
support all the cases outlined in the specification.  I would like to
avoid a case where
we're back to using /dev/mem to deal with the dual entry/dual table
case if that becomes
important down the road.

Here's a proposal for files in /sys/firmware/dmi/tables:

smbios_entry_point32   -  32 bit (existing entry point type), if it exists.
smbios_entry_point64   -  64 bit entry, new in SMBIOS v3.0
DMI32 -  smbios structure tables referenced by
32 bit entry point, if it exists
DMI64 -  smbios structure tables referenced by
64 bit entry point, if it exists.
 symlink to DMI32 if identical
smbios_entry_point- symlink to smbios_entry_point64 if it exists,
otherwise symlink to smbios_entry_point64
DMI   - symlink to DMI64 if it exists,
otherwise symlink to DMI32

These last two would provide names to the 'preferred' tables, and
names that would always exist on all systems, which
I think is a nice property to have.

Thoughts?

Thanks,
Roy



>
>
>>> Signed-off-by: Ivan Khoronzhuk 
>>> ---
>>>   .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
>>>   drivers/firmware/dmi-sysfs.c   | 11 ++-
>>>   drivers/firmware/dmi_scan.c| 80
>>> ++
>>>   include/linux/dmi.h|  1 +
>>>   4 files changed, 107 insertions(+), 7 deletions(-)
>>>   create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables
>>> b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
>>> new file mode 100644
>>> index 000..f46158c
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
>>> @@ -0,0 +1,22 @@
>>> +What:  /sys/firmware/dmi/tables/
>>> +Date:  April 2015
>>> +Contact:   Ivan Khoronzhuk 
>>> +Description:
>>> +   The firmware provides DMI structures as a packed list of
>>> +   data referenced by a SMBIOS table entry point. The SMBIOS
>>> +   entry point contains general information, like SMBIOS
>>> +   version, DMI table size, etc. The structure, content and
>>> +   size of SMBIOS entry point is dependent on SMBIOS version.
>>> +   The format of SMBIOS entry point, equal as DMI structures
>>> +   can be read in SMBIOS specification.
>>> +
>>> +   The dmi/tables provides raw SMBIOS entry p

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

[Roy Franz]

On Wed, Apr 15, 2015 at 8:45 AM, Andy Lutomirski  wrote:
> On Apr 15, 2015 6:20 AM, "Greg Kroah-Hartman"
>  wrote:
>>
>> On Tue, Apr 14, 2015 at 11:52:48AM -0400, Andy Lutomirski wrote:
>> > On Tue, Apr 14, 2015 at 10:09 AM, Greg Kroah-Hartman
>> >  wrote:
>> > > On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote:
>> > >> From: "Kweh, Hock Leong" 
>> > >>
>> > >> Introducing a kernel module to expose capsule loader interface
>> > >> for user to upload capsule binaries. This module leverage the
>> > >> request_firmware_direct_full_path() to obtain the binary at a
>> > >> specific path input by user.
>> > >>
>> > >> Example method to load the capsule binary:
>> > >> echo -n "/path/to/capsule/binary" > 
>> > >> /sys/devices/platform/efi_capsule_loader/capsule_loader
>> > >
>> > > Ick, why not just have the firmware file location present, and copy it
>> > > to the sysfs file directly from userspace, instead of this two-step
>> > > process?
>> >
>> > Because it's not at all obvious how error handling should work in that 
>> > case.
>>
>> I don't understand how the error handling is any different.  The kernel
>> ends up copying the data in through the firmware interface both ways, we
>> just aren't creating yet-another-firmware-path in the system.
>
> If I run uefi-update-capsule foo.bin, I want it to complain if the
> UEFI call fails.  In contrast, if I boot and my ath10k firmware is
> bad, there's no explicit user interaction that should fail; instead I
> have no network device and I get to read the logs and figure out why.
> IOW bad volatile device firmware is just like a bad device driver,
> whereas bad UEFI capsules are problems that should be reported to
> whatever tried to send them to UEFI.
>
> --Andy
>
There are several types of errors that can be returned by
UpdateCapsule(), allowing
us to distinguish between capsules that are not supported by the
platform, capsules
that must be updated at boot time, and capsule updates that failed due
to a device error.
I think we really do want this type of information returned to capsule loader.

Roy

>>
>> thanks,
>>
>> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86/efi: Store upper bits of command line buffer address in ext_cmd_line_ptr

[Roy Franz]

Until now, the EFI stub was only setting the 32 bit cmd_line_ptr in
the setup_header structure, so on 64 bit platforms this could be truncated.
This patch adds setting the upper bits of the buffer address in
ext_cmd_line_ptr.  This case was likely never hit, as the allocation
for this buffer is done at the lowest available address.  Only
x86_64 kernels have this problem, as the 1-1 mapping mandated
by EFI ensures that all memory is 32 bit addressable on 32 bit
platforms.  The EFI stub does not support mixed mode, so the
32 bit kernel on 64 bit firmware case does not need to be handled.

Signed-off-by: Roy Franz 
---
This is a follow-up to "x86_64/efi: enforce 32 bit address for command line 
buffer",
which had the wrong fix to the truncation of address.

 arch/x86/boot/compressed/eboot.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ef17683..48304b8 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -1109,6 +1109,8 @@ struct boot_params *make_boot_params(struct efi_config *c)
if (!cmdline_ptr)
goto fail;
hdr->cmd_line_ptr = (unsigned long)cmdline_ptr;
+   /* Fill in upper bits of command line address, NOP on 32 bit  */
+   boot_params->ext_cmd_line_ptr = (u64)(unsigned long)cmdline_ptr >> 32;
 
hdr->ramdisk_image = 0;
hdr->ramdisk_size = 0;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86_64/efi: enforce 32 bit address for command line buffer

[Roy Franz]

On Wed, Apr 15, 2015 at 6:18 AM, Matt Fleming  wrote:
> On Tue, 14 Apr, at 05:45:52PM, Roy Franz wrote:
>> The boot_params structure has a 32 bit field for storing the address of
>> the kernel command line.  When the EFI stub allocates memory for the command
>> line, it allocates at as low and address as possible, but does not ensure
>> that the address of memory allocated is below 4G.
>> This patch enforces this limit, and the stub now returns an error if the
>> command line buffer is allocated at too high of an address.
>> For 32 bit systems, the EFI mandated 1-1 memory mapping ensures
>> that all memory is 32 bit addressable, so we don't have a problem.
>> Also, mixed-mode booting on EFI platforms does not use the stub
>> code, so we don't need to handle the case of booting a 32 bit
>> kernel on a 64 bit EFI platform.
>>
>> Signed-off-by: Roy Franz 
>> ---
>>  arch/x86/boot/compressed/eboot.c | 13 +
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/x86/boot/compressed/eboot.c 
>> b/arch/x86/boot/compressed/eboot.c
>> index ef17683..82dbe27 100644
>> --- a/arch/x86/boot/compressed/eboot.c
>> +++ b/arch/x86/boot/compressed/eboot.c
>> @@ -1108,6 +1108,19 @@ struct boot_params *make_boot_params(struct 
>> efi_config *c)
>>   cmdline_ptr = efi_convert_cmdline(sys_table, image, _size);
>>   if (!cmdline_ptr)
>>   goto fail;
>> +
>> +#ifdef CONFIG_X86_64
>> + /*
>> +  * hdr->cmd_line_ptr is a 32 bit field, so on 64 bit systems we need
>> +  * to ensure that the allocated buffer for the commandline is 32 bit
>> +  * addressable.
>> +   */
>> + if ((u64)(cmdline_ptr) + options_size > (u64)U32_MAX) {
>> + efi_printk(sys_table, "Failed to alloc lowmem for command 
>> line\n");
>> + efi_free(sys_table, options_size, (unsigned long)cmdline_ptr);
>> + goto fail;
>> + }
>> +#endif /* CONFIG_X86_64 */
>>   hdr->cmd_line_ptr = (unsigned long)cmdline_ptr;
>>
>>   hdr->ramdisk_image = 0;
>
> Good catch. But actually, we have boot_params->ext_cmd_line_ptr for
> exactly this problem.
>
> So yes, that's a valid bug, but I don't think this is how we should fix
> it.
Yeah, I guess it shouldn't surprise me that there is support for 64
bit addresses  there :)

I'l spin another patch that sets boot_params->ext_cmd_line_ptr with
the upper 32 bits of the address.
Should I conditionalize this with #ifdef CONFIG_X86_64, or just do it
unconditionally, with it being a NOP
on 32 bit?  (I guess I may end up with an extra cast for the 32 bit case)

Roy


>
> --
> Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86_64/efi: enforce 32 bit address for command line buffer

[Roy Franz]

On Wed, Apr 15, 2015 at 6:18 AM, Matt Fleming m...@codeblueprint.co.uk wrote:
 On Tue, 14 Apr, at 05:45:52PM, Roy Franz wrote:
 The boot_params structure has a 32 bit field for storing the address of
 the kernel command line.  When the EFI stub allocates memory for the command
 line, it allocates at as low and address as possible, but does not ensure
 that the address of memory allocated is below 4G.
 This patch enforces this limit, and the stub now returns an error if the
 command line buffer is allocated at too high of an address.
 For 32 bit systems, the EFI mandated 1-1 memory mapping ensures
 that all memory is 32 bit addressable, so we don't have a problem.
 Also, mixed-mode booting on EFI platforms does not use the stub
 code, so we don't need to handle the case of booting a 32 bit
 kernel on a 64 bit EFI platform.

 Signed-off-by: Roy Franz roy.fr...@linaro.org
 ---
  arch/x86/boot/compressed/eboot.c | 13 +
  1 file changed, 13 insertions(+)

 diff --git a/arch/x86/boot/compressed/eboot.c 
 b/arch/x86/boot/compressed/eboot.c
 index ef17683..82dbe27 100644
 --- a/arch/x86/boot/compressed/eboot.c
 +++ b/arch/x86/boot/compressed/eboot.c
 @@ -1108,6 +1108,19 @@ struct boot_params *make_boot_params(struct 
 efi_config *c)
   cmdline_ptr = efi_convert_cmdline(sys_table, image, options_size);
   if (!cmdline_ptr)
   goto fail;
 +
 +#ifdef CONFIG_X86_64
 + /*
 +  * hdr-cmd_line_ptr is a 32 bit field, so on 64 bit systems we need
 +  * to ensure that the allocated buffer for the commandline is 32 bit
 +  * addressable.
 +   */
 + if ((u64)(cmdline_ptr) + options_size  (u64)U32_MAX) {
 + efi_printk(sys_table, Failed to alloc lowmem for command 
 line\n);
 + efi_free(sys_table, options_size, (unsigned long)cmdline_ptr);
 + goto fail;
 + }
 +#endif /* CONFIG_X86_64 */
   hdr-cmd_line_ptr = (unsigned long)cmdline_ptr;

   hdr-ramdisk_image = 0;

 Good catch. But actually, we have boot_params-ext_cmd_line_ptr for
 exactly this problem.

 So yes, that's a valid bug, but I don't think this is how we should fix
 it.
Yeah, I guess it shouldn't surprise me that there is support for 64
bit addresses  there :)

I'l spin another patch that sets boot_params-ext_cmd_line_ptr with
the upper 32 bits of the address.
Should I conditionalize this with #ifdef CONFIG_X86_64, or just do it
unconditionally, with it being a NOP
on 32 bit?  (I guess I may end up with an extra cast for the 32 bit case)

Roy



 --
 Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86/efi: Store upper bits of command line buffer address in ext_cmd_line_ptr

[Roy Franz]

Until now, the EFI stub was only setting the 32 bit cmd_line_ptr in
the setup_header structure, so on 64 bit platforms this could be truncated.
This patch adds setting the upper bits of the buffer address in
ext_cmd_line_ptr.  This case was likely never hit, as the allocation
for this buffer is done at the lowest available address.  Only
x86_64 kernels have this problem, as the 1-1 mapping mandated
by EFI ensures that all memory is 32 bit addressable on 32 bit
platforms.  The EFI stub does not support mixed mode, so the
32 bit kernel on 64 bit firmware case does not need to be handled.

Signed-off-by: Roy Franz roy.fr...@linaro.org
---
This is a follow-up to x86_64/efi: enforce 32 bit address for command line 
buffer,
which had the wrong fix to the truncation of address.

 arch/x86/boot/compressed/eboot.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ef17683..48304b8 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -1109,6 +1109,8 @@ struct boot_params *make_boot_params(struct efi_config *c)
if (!cmdline_ptr)
goto fail;
hdr-cmd_line_ptr = (unsigned long)cmdline_ptr;
+   /* Fill in upper bits of command line address, NOP on 32 bit  */
+   boot_params-ext_cmd_line_ptr = (u64)(unsigned long)cmdline_ptr  32;
 
hdr-ramdisk_image = 0;
hdr-ramdisk_size = 0;
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Roy Franz]

On Tue, Apr 14, 2015 at 9:19 PM, Roy Franz roy.fr...@linaro.org wrote:
 On Fri, Apr 3, 2015 at 2:36 AM, Ivan.khoronzhuk
 ivan.khoronz...@globallogic.com wrote:


 On 02.04.15 15:57, Ivan Khoronzhuk wrote:

 Some utils, like dmidecode and smbios, need to access SMBIOS entry
 table area in order to get information like SMBIOS version, size, etc.
 Currently it's done via /dev/mem. But for situation when /dev/mem
 usage is disabled, the utils have to use dmi sysfs instead, which
 doesn't represent SMBIOS entry and adds code/delay redundancy when direct
 access for table is needed.

 So this patch creates dmi/tables and adds SMBIOS entry point to allow
 utils in question to work correctly without /dev/mem. Also patch adds
 raw dmi table to simplify dmi table processing in user space, as
 proposed by Jean Delvare.


 I have made modifications to dmidecode to support this interface, and it
 works quite nicely for dmidecode. (changes posted to dmidecode-devel list)
 The only open issue I am aware of is how the SMBIOS v3 entry point
 will be handled,
 especially in cases where there is a v2 and a v3 entry point.
 In principal I think this a good change - are there any other open issues?

 Thanks,
 Roy


I looked at the SMBIOS spec again, and the platform can provide either or
both of the 32-bit and 64-bit entry points.  The spec says that an
implementation
should provide a 32-bit entry point for compatibility.

These 2 entry point structures can both point to the same SMBIOS
structure table,
or two distinct ones.  If distinct, the one referenced by the 32-bit
entry point must be
a consistent subset of the 64-bit one.
There does not seem to be any prohibition from using new SMBIOS v3 structures
in a table referenced by a 32-bit entry point, so backwards
compatibility is completely
up to the implementation.

Since the point of this patchset (and related changes to dmidecode) is
to provide the
SMBIOS information without using /dev/mem, I think the interface we
define should
support all the cases outlined in the specification.  I would like to
avoid a case where
we're back to using /dev/mem to deal with the dual entry/dual table
case if that becomes
important down the road.

Here's a proposal for files in /sys/firmware/dmi/tables:

smbios_entry_point32   -  32 bit (existing entry point type), if it exists.
smbios_entry_point64   -  64 bit entry, new in SMBIOS v3.0
DMI32 -  smbios structure tables referenced by
32 bit entry point, if it exists
DMI64 -  smbios structure tables referenced by
64 bit entry point, if it exists.
 symlink to DMI32 if identical
smbios_entry_point- symlink to smbios_entry_point64 if it exists,
otherwise symlink to smbios_entry_point64
DMI   - symlink to DMI64 if it exists,
otherwise symlink to DMI32

These last two would provide names to the 'preferred' tables, and
names that would always exist on all systems, which
I think is a nice property to have.

Thoughts?

Thanks,
Roy





 Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
 ---
   .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
   drivers/firmware/dmi-sysfs.c   | 11 ++-
   drivers/firmware/dmi_scan.c| 80
 ++
   include/linux/dmi.h|  1 +
   4 files changed, 107 insertions(+), 7 deletions(-)
   create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables

 diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables
 b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
 new file mode 100644
 index 000..f46158c
 --- /dev/null
 +++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
 @@ -0,0 +1,22 @@
 +What:  /sys/firmware/dmi/tables/
 +Date:  April 2015
 +Contact:   Ivan Khoronzhuk ivan.khoronz...@globallogic.com
 +Description:
 +   The firmware provides DMI structures as a packed list of
 +   data referenced by a SMBIOS table entry point. The SMBIOS
 +   entry point contains general information, like SMBIOS
 +   version, DMI table size, etc. The structure, content and
 +   size of SMBIOS entry point is dependent on SMBIOS version.
 +   The format of SMBIOS entry point, equal as DMI structures
 +   can be read in SMBIOS specification.
 +
 +   The dmi/tables provides raw SMBIOS entry point and DMI
 tables
 +   through sysfs as an alternative to utilities reading them
 +   from /dev/mem. The raw SMBIOS entry point and DMI table
 are
 +   presented as raw attributes and are accessible via:
 +
 +   /sys/firmware/dmi/tables/smbios_entry_point
 +   /sys/firmware/dmi/tables/DMI
 +
 +   The complete DMI information can be taken using these two
 +   tables.
 diff --git a/drivers/firmware/dmi-sysfs.c b

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

[Roy Franz]

On Wed, Apr 15, 2015 at 8:45 AM, Andy Lutomirski l...@amacapital.net wrote:
 On Apr 15, 2015 6:20 AM, Greg Kroah-Hartman
 gre...@linuxfoundation.org wrote:

 On Tue, Apr 14, 2015 at 11:52:48AM -0400, Andy Lutomirski wrote:
  On Tue, Apr 14, 2015 at 10:09 AM, Greg Kroah-Hartman
  gre...@linuxfoundation.org wrote:
   On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote:
   From: Kweh, Hock Leong hock.leong.k...@intel.com
  
   Introducing a kernel module to expose capsule loader interface
   for user to upload capsule binaries. This module leverage the
   request_firmware_direct_full_path() to obtain the binary at a
   specific path input by user.
  
   Example method to load the capsule binary:
   echo -n /path/to/capsule/binary  
   /sys/devices/platform/efi_capsule_loader/capsule_loader
  
   Ick, why not just have the firmware file location present, and copy it
   to the sysfs file directly from userspace, instead of this two-step
   process?
 
  Because it's not at all obvious how error handling should work in that 
  case.

 I don't understand how the error handling is any different.  The kernel
 ends up copying the data in through the firmware interface both ways, we
 just aren't creating yet-another-firmware-path in the system.

 If I run uefi-update-capsule foo.bin, I want it to complain if the
 UEFI call fails.  In contrast, if I boot and my ath10k firmware is
 bad, there's no explicit user interaction that should fail; instead I
 have no network device and I get to read the logs and figure out why.
 IOW bad volatile device firmware is just like a bad device driver,
 whereas bad UEFI capsules are problems that should be reported to
 whatever tried to send them to UEFI.

 --Andy

There are several types of errors that can be returned by
UpdateCapsule(), allowing
us to distinguish between capsules that are not supported by the
platform, capsules
that must be updated at boot time, and capsule updates that failed due
to a device error.
I think we really do want this type of information returned to capsule loader.

Roy


 thanks,

 greg k-h
 --
 To unsubscribe from this list: send the line unsubscribe linux-efi in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Roy Franz]

On Fri, Apr 3, 2015 at 2:36 AM, Ivan.khoronzhuk
 wrote:
>
>
> On 02.04.15 15:57, Ivan Khoronzhuk wrote:
>>
>> Some utils, like dmidecode and smbios, need to access SMBIOS entry
>> table area in order to get information like SMBIOS version, size, etc.
>> Currently it's done via /dev/mem. But for situation when /dev/mem
>> usage is disabled, the utils have to use dmi sysfs instead, which
>> doesn't represent SMBIOS entry and adds code/delay redundancy when direct
>> access for table is needed.
>>
>> So this patch creates dmi/tables and adds SMBIOS entry point to allow
>> utils in question to work correctly without /dev/mem. Also patch adds
>> raw dmi table to simplify dmi table processing in user space, as
>> proposed by Jean Delvare.
>>

I have made modifications to dmidecode to support this interface, and it
works quite nicely for dmidecode. (changes posted to dmidecode-devel list)
The only open issue I am aware of is how the SMBIOS v3 entry point
will be handled,
especially in cases where there is a v2 and a v3 entry point.
In principal I think this a good change - are there any other open issues?

Thanks,
Roy



>> Signed-off-by: Ivan Khoronzhuk 
>> ---
>>   .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
>>   drivers/firmware/dmi-sysfs.c   | 11 ++-
>>   drivers/firmware/dmi_scan.c| 80
>> ++
>>   include/linux/dmi.h|  1 +
>>   4 files changed, 107 insertions(+), 7 deletions(-)
>>   create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables
>>
>> diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables
>> b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
>> new file mode 100644
>> index 000..f46158c
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
>> @@ -0,0 +1,22 @@
>> +What:  /sys/firmware/dmi/tables/
>> +Date:  April 2015
>> +Contact:   Ivan Khoronzhuk 
>> +Description:
>> +   The firmware provides DMI structures as a packed list of
>> +   data referenced by a SMBIOS table entry point. The SMBIOS
>> +   entry point contains general information, like SMBIOS
>> +   version, DMI table size, etc. The structure, content and
>> +   size of SMBIOS entry point is dependent on SMBIOS version.
>> +   The format of SMBIOS entry point, equal as DMI structures
>> +   can be read in SMBIOS specification.
>> +
>> +   The dmi/tables provides raw SMBIOS entry point and DMI
>> tables
>> +   through sysfs as an alternative to utilities reading them
>> +   from /dev/mem. The raw SMBIOS entry point and DMI table
>> are
>> +   presented as raw attributes and are accessible via:
>> +
>> +   /sys/firmware/dmi/tables/smbios_entry_point
>> +   /sys/firmware/dmi/tables/DMI
>> +
>> +   The complete DMI information can be taken using these two
>> +   tables.
>> diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
>> index e0f1cb3..8e1a411 100644
>> --- a/drivers/firmware/dmi-sysfs.c
>> +++ b/drivers/firmware/dmi-sysfs.c
>> @@ -566,7 +566,6 @@ static struct kobj_type dmi_sysfs_entry_ktype = {
>> .default_attrs = dmi_sysfs_entry_attrs,
>>   };
>>   -static struct kobject *dmi_kobj;
>>   static struct kset *dmi_kset;
>> /* Global count of all instances seen.  Only for setup */
>> @@ -651,10 +650,11 @@ static int __init dmi_sysfs_init(void)
>> int error = -ENOMEM;
>> int val;
>>   - /* Set up our directory */
>> -   dmi_kobj = kobject_create_and_add("dmi", firmware_kobj);
>> -   if (!dmi_kobj)
>> +   if (!dmi_kobj) {
>> +   pr_err("dmi-sysfs: dmi entry is absent.\n");
>> +   error = -ENOSYS;
>> goto err;
>> +   }
>> dmi_kset = kset_create_and_add("entries", NULL, dmi_kobj);
>> if (!dmi_kset)
>> @@ -675,7 +675,6 @@ static int __init dmi_sysfs_init(void)
>>   err:
>> cleanup_entry_list();
>> kset_unregister(dmi_kset);
>> -   kobject_put(dmi_kobj);
>> return error;
>>   }
>>   @@ -685,8 +684,6 @@ static void __exit dmi_sysfs_exit(void)
>> pr_debug("dmi-sysfs: unloading.\n");
>> cleanup_entry_list();
>> kset_unregister(dmi_kset);
>> -   kobject_del(dmi_kobj);
>> -   kobject_put(dmi_kobj);
>>   }
>> module_init(dmi_sysfs_init);
>> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
>> index d3aae09..bb19f8b 100644
>> --- a/drivers/firmware/dmi_scan.c
>> +++ b/drivers/firmware/dmi_scan.c
>> @@ -10,6 +10,9 @@
>>   #include 
>>   #include 
>>   +struct kobject *dmi_kobj;
>> +EXPORT_SYMBOL_GPL(dmi_kobj);
>> +
>>   /*
>>* DMI stands for "Desktop Management Interface".  It is part
>>* of and an antecedent to, SMBIOS, which stands for System
>> @@ -20,6 +23,9 @@ static 

[PATCH] x86_64/efi: enforce 32 bit address for command line buffer

[Roy Franz]

The boot_params structure has a 32 bit field for storing the address of
the kernel command line.  When the EFI stub allocates memory for the command
line, it allocates at as low and address as possible, but does not ensure
that the address of memory allocated is below 4G.
This patch enforces this limit, and the stub now returns an error if the
command line buffer is allocated at too high of an address.
For 32 bit systems, the EFI mandated 1-1 memory mapping ensures
that all memory is 32 bit addressable, so we don't have a problem.
Also, mixed-mode booting on EFI platforms does not use the stub
code, so we don't need to handle the case of booting a 32 bit
kernel on a 64 bit EFI platform.

Signed-off-by: Roy Franz 
---
 arch/x86/boot/compressed/eboot.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ef17683..82dbe27 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -1108,6 +1108,19 @@ struct boot_params *make_boot_params(struct efi_config 
*c)
cmdline_ptr = efi_convert_cmdline(sys_table, image, _size);
if (!cmdline_ptr)
goto fail;
+
+#ifdef CONFIG_X86_64
+   /*
+* hdr->cmd_line_ptr is a 32 bit field, so on 64 bit systems we need
+* to ensure that the allocated buffer for the commandline is 32 bit
+* addressable.
+ */
+   if ((u64)(cmdline_ptr) + options_size > (u64)U32_MAX) {
+   efi_printk(sys_table, "Failed to alloc lowmem for command 
line\n");
+   efi_free(sys_table, options_size, (unsigned long)cmdline_ptr);
+   goto fail;
+   }
+#endif /* CONFIG_X86_64 */
hdr->cmd_line_ptr = (unsigned long)cmdline_ptr;
 
hdr->ramdisk_image = 0;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86_64/efi: enforce 32 bit address for command line buffer

[Roy Franz]

The boot_params structure has a 32 bit field for storing the address of
the kernel command line.  When the EFI stub allocates memory for the command
line, it allocates at as low and address as possible, but does not ensure
that the address of memory allocated is below 4G.
This patch enforces this limit, and the stub now returns an error if the
command line buffer is allocated at too high of an address.
For 32 bit systems, the EFI mandated 1-1 memory mapping ensures
that all memory is 32 bit addressable, so we don't have a problem.
Also, mixed-mode booting on EFI platforms does not use the stub
code, so we don't need to handle the case of booting a 32 bit
kernel on a 64 bit EFI platform.

Signed-off-by: Roy Franz roy.fr...@linaro.org
---
 arch/x86/boot/compressed/eboot.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ef17683..82dbe27 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -1108,6 +1108,19 @@ struct boot_params *make_boot_params(struct efi_config 
*c)
cmdline_ptr = efi_convert_cmdline(sys_table, image, options_size);
if (!cmdline_ptr)
goto fail;
+
+#ifdef CONFIG_X86_64
+   /*
+* hdr-cmd_line_ptr is a 32 bit field, so on 64 bit systems we need
+* to ensure that the allocated buffer for the commandline is 32 bit
+* addressable.
+ */
+   if ((u64)(cmdline_ptr) + options_size  (u64)U32_MAX) {
+   efi_printk(sys_table, Failed to alloc lowmem for command 
line\n);
+   efi_free(sys_table, options_size, (unsigned long)cmdline_ptr);
+   goto fail;
+   }
+#endif /* CONFIG_X86_64 */
hdr-cmd_line_ptr = (unsigned long)cmdline_ptr;
 
hdr-ramdisk_image = 0;
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Roy Franz]

On Fri, Apr 3, 2015 at 2:36 AM, Ivan.khoronzhuk
ivan.khoronz...@globallogic.com wrote:


 On 02.04.15 15:57, Ivan Khoronzhuk wrote:

 Some utils, like dmidecode and smbios, need to access SMBIOS entry
 table area in order to get information like SMBIOS version, size, etc.
 Currently it's done via /dev/mem. But for situation when /dev/mem
 usage is disabled, the utils have to use dmi sysfs instead, which
 doesn't represent SMBIOS entry and adds code/delay redundancy when direct
 access for table is needed.

 So this patch creates dmi/tables and adds SMBIOS entry point to allow
 utils in question to work correctly without /dev/mem. Also patch adds
 raw dmi table to simplify dmi table processing in user space, as
 proposed by Jean Delvare.


I have made modifications to dmidecode to support this interface, and it
works quite nicely for dmidecode. (changes posted to dmidecode-devel list)
The only open issue I am aware of is how the SMBIOS v3 entry point
will be handled,
especially in cases where there is a v2 and a v3 entry point.
In principal I think this a good change - are there any other open issues?

Thanks,
Roy



 Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
 ---
   .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
   drivers/firmware/dmi-sysfs.c   | 11 ++-
   drivers/firmware/dmi_scan.c| 80
 ++
   include/linux/dmi.h|  1 +
   4 files changed, 107 insertions(+), 7 deletions(-)
   create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables

 diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables
 b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
 new file mode 100644
 index 000..f46158c
 --- /dev/null
 +++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
 @@ -0,0 +1,22 @@
 +What:  /sys/firmware/dmi/tables/
 +Date:  April 2015
 +Contact:   Ivan Khoronzhuk ivan.khoronz...@globallogic.com
 +Description:
 +   The firmware provides DMI structures as a packed list of
 +   data referenced by a SMBIOS table entry point. The SMBIOS
 +   entry point contains general information, like SMBIOS
 +   version, DMI table size, etc. The structure, content and
 +   size of SMBIOS entry point is dependent on SMBIOS version.
 +   The format of SMBIOS entry point, equal as DMI structures
 +   can be read in SMBIOS specification.
 +
 +   The dmi/tables provides raw SMBIOS entry point and DMI
 tables
 +   through sysfs as an alternative to utilities reading them
 +   from /dev/mem. The raw SMBIOS entry point and DMI table
 are
 +   presented as raw attributes and are accessible via:
 +
 +   /sys/firmware/dmi/tables/smbios_entry_point
 +   /sys/firmware/dmi/tables/DMI
 +
 +   The complete DMI information can be taken using these two
 +   tables.
 diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
 index e0f1cb3..8e1a411 100644
 --- a/drivers/firmware/dmi-sysfs.c
 +++ b/drivers/firmware/dmi-sysfs.c
 @@ -566,7 +566,6 @@ static struct kobj_type dmi_sysfs_entry_ktype = {
 .default_attrs = dmi_sysfs_entry_attrs,
   };
   -static struct kobject *dmi_kobj;
   static struct kset *dmi_kset;
 /* Global count of all instances seen.  Only for setup */
 @@ -651,10 +650,11 @@ static int __init dmi_sysfs_init(void)
 int error = -ENOMEM;
 int val;
   - /* Set up our directory */
 -   dmi_kobj = kobject_create_and_add(dmi, firmware_kobj);
 -   if (!dmi_kobj)
 +   if (!dmi_kobj) {
 +   pr_err(dmi-sysfs: dmi entry is absent.\n);
 +   error = -ENOSYS;
 goto err;
 +   }
 dmi_kset = kset_create_and_add(entries, NULL, dmi_kobj);
 if (!dmi_kset)
 @@ -675,7 +675,6 @@ static int __init dmi_sysfs_init(void)
   err:
 cleanup_entry_list();
 kset_unregister(dmi_kset);
 -   kobject_put(dmi_kobj);
 return error;
   }
   @@ -685,8 +684,6 @@ static void __exit dmi_sysfs_exit(void)
 pr_debug(dmi-sysfs: unloading.\n);
 cleanup_entry_list();
 kset_unregister(dmi_kset);
 -   kobject_del(dmi_kobj);
 -   kobject_put(dmi_kobj);
   }
 module_init(dmi_sysfs_init);
 diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
 index d3aae09..bb19f8b 100644
 --- a/drivers/firmware/dmi_scan.c
 +++ b/drivers/firmware/dmi_scan.c
 @@ -10,6 +10,9 @@
   #include asm/dmi.h
   #include asm/unaligned.h
   +struct kobject *dmi_kobj;
 +EXPORT_SYMBOL_GPL(dmi_kobj);
 +
   /*
* DMI stands for Desktop Management Interface.  It is part
* of and an antecedent to, SMBIOS, which stands for System
 @@ -20,6 +23,9 @@ static const char dmi_empty_string[] = ;
   static u32 dmi_ver __initdata;
   static u32 dmi_len;
   static u16 

Re: fwupdate

[Roy Franz]

On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov  wrote:
> + pjones.
>
> So reportedly, there is already a capsule-loading thing which doesn't
> need the kernel at all:
>
> https://github.com/rhinstaller/fwupdate
>
> So why are we even wasting energy with this discussion here?
>
> --
> Regards/Gruss,
> Boris.

The network boot case can be taken care of as Peter described (ie
taking network device paths, instead of just file paths), so
this should work for those cases as well.  There would be some extra
setup, as for this to work the EFI firmware update program
would need to be run at boot (via the BootNext variable), but I don't
think this is unreasonable.
It looks like GnuEFI now supports Aarch64, so building the firmware
update utility shouldn't be a problem.  Peter - have you you tried
building
this on Aarch64 yet?  If not I'll give it a try.

I think there is some value in using runtime update capsule calls, as
that will help make sure the feature works in the firmware.  I think
with arm64 servers
in an early stage of development, we can influence the firmware
support of various features by using them.  I don't know that this is
a sufficient reason, but if
runtime capsules are never used then there is a good chance that there
will be many broken implementations.

Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fwupdate

[Roy Franz]

On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov b...@alien8.de wrote:
 + pjones.

 So reportedly, there is already a capsule-loading thing which doesn't
 need the kernel at all:

 https://github.com/rhinstaller/fwupdate

 So why are we even wasting energy with this discussion here?

 --
 Regards/Gruss,
 Boris.

The network boot case can be taken care of as Peter described (ie
taking network device paths, instead of just file paths), so
this should work for those cases as well.  There would be some extra
setup, as for this to work the EFI firmware update program
would need to be run at boot (via the BootNext variable), but I don't
think this is unreasonable.
It looks like GnuEFI now supports Aarch64, so building the firmware
update utility shouldn't be a problem.  Peter - have you you tried
building
this on Aarch64 yet?  If not I'll give it a try.

I think there is some value in using runtime update capsule calls, as
that will help make sure the feature works in the firmware.  I think
with arm64 servers
in an early stage of development, we can influence the firmware
support of various features by using them.  I don't know that this is
a sufficient reason, but if
runtime capsules are never used then there is a good chance that there
will be many broken implementations.

Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Roy Franz]

On Fri, Mar 6, 2015 at 1:39 PM, Peter Jones  wrote:
> On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote:
>> Hi All,
>>
>> After some internal discussion and re-design prototyping & testing on
>> this efi capsule interface kernel module, I would like to start a discussion
>> here on the new idea and wish to get input for the implementation and
>> eventually upstream.
>
> So do we actually *need* a kernel interface to UpdateCapsule?  We've
> already got an implementation in progress where we use my ESRT patch to
> figure out what firmwares we can update, and we schedule them and do the
> update during boot up before the normal bootloader is run.  That means
> never having to call UpdateCapsule() after ExitBootServices() or
> SetVirtualAddressMap() have been called, and only doing it across
> reboots that UEFI is performing itself.  It also means never having to
> do it with multiple CPUs running.

So this does it by writing the capsules to the EFI system partition, and having
them processed from there during the next boot?
How would this work on diskless systems? (or boot-disk-less systems)

What are the use cases for capsules that don't require a reboot?  I'm not
really clear uses for those, but the kernel interface could be better for those,
as it would allow processing without a reboot.

Roy

>
> I've posted several revisions of the ESRT patch to linux-efi , and right
> now we're just waiting on the UEFI 2.5 spec to be finalized before I
> send a final copy to Matt.  The command line tool and the code to apply
> the firmwares during boot are at https://github.com/rhinstaller/fwupdate
> and there's a GNOME-based UI in progress at
> https://github.com/hughsie/fwupd (yes we apparently stink at naming
> things.)
>
> I'm not sure how making this go through the kernel will make things
> better - it introduces a lot more things that can go wrong, and the only
> benefit is one reboot where BootNext is set - which actually is
> relatively fast even slow-POSTing machines.  After that the
> UpdateCapsule+reboot to apply is *extremely* fast, because
> applying capsule updates have to happen very very early in the boot-up
> sequence.  (That early processing is /effectively/ a requirement,
> since it has to happen before the block write locking on the SPI part is
> done.)  So even on the machine that takes quite some time to POST, the
> time that would be saved saved is less than 1% or so of the total update
> time.
>
> An early version of my code worked to update a machine I got from your
> employer, FWIW - right now we're adding API and fixing up implementation
> bits I made specifically to that one proof-of-concept scenario, and
> there's some API parts that are in UEFI 2.5 draft releases that we're
> not quite handling yet.  However, there's code there that's already been
> checked in which has successfully applied system firmware updates
> without having a kernel interface to UpdateCapsule().
>
> So again: do we really need or want to do this?
>
> --
> Peter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Roy Franz]

On Fri, Mar 6, 2015 at 1:39 PM, Peter Jones pjo...@redhat.com wrote:
 On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote:
 Hi All,

 After some internal discussion and re-design prototyping  testing on
 this efi capsule interface kernel module, I would like to start a discussion
 here on the new idea and wish to get input for the implementation and
 eventually upstream.

 So do we actually *need* a kernel interface to UpdateCapsule?  We've
 already got an implementation in progress where we use my ESRT patch to
 figure out what firmwares we can update, and we schedule them and do the
 update during boot up before the normal bootloader is run.  That means
 never having to call UpdateCapsule() after ExitBootServices() or
 SetVirtualAddressMap() have been called, and only doing it across
 reboots that UEFI is performing itself.  It also means never having to
 do it with multiple CPUs running.

So this does it by writing the capsules to the EFI system partition, and having
them processed from there during the next boot?
How would this work on diskless systems? (or boot-disk-less systems)

What are the use cases for capsules that don't require a reboot?  I'm not
really clear uses for those, but the kernel interface could be better for those,
as it would allow processing without a reboot.

Roy


 I've posted several revisions of the ESRT patch to linux-efi , and right
 now we're just waiting on the UEFI 2.5 spec to be finalized before I
 send a final copy to Matt.  The command line tool and the code to apply
 the firmwares during boot are at https://github.com/rhinstaller/fwupdate
 and there's a GNOME-based UI in progress at
 https://github.com/hughsie/fwupd (yes we apparently stink at naming
 things.)

 I'm not sure how making this go through the kernel will make things
 better - it introduces a lot more things that can go wrong, and the only
 benefit is one reboot where BootNext is set - which actually is
 relatively fast even slow-POSTing machines.  After that the
 UpdateCapsule+reboot to apply is *extremely* fast, because
 applying capsule updates have to happen very very early in the boot-up
 sequence.  (That early processing is /effectively/ a requirement,
 since it has to happen before the block write locking on the SPI part is
 done.)  So even on the machine that takes quite some time to POST, the
 time that would be saved saved is less than 1% or so of the total update
 time.

 An early version of my code worked to update a machine I got from your
 employer, FWIW - right now we're adding API and fixing up implementation
 bits I made specifically to that one proof-of-concept scenario, and
 there's some API parts that are in UEFI 2.5 draft releases that we're
 not quite handling yet.  However, there's code there that's already been
 checked in which has successfully applied system firmware updates
 without having a kernel interface to UpdateCapsule().

 So again: do we really need or want to do this?

 --
 Peter
 --
 To unsubscribe from this list: send the line unsubscribe linux-efi in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Roy Franz]

On Sun, Nov 2, 2014 at 7:07 PM, Kweh Hock Leong
 wrote:
> From: "Kweh, Hock Leong" 
>
> Introducing a kernel module to expose user helper interface for
> user to upload capsule binaries. This module leverage the
> request_firmware_nowait() to expose an interface to user.
>
> Example steps to load the capsule binary:
> 1.) echo 1 > /sys/class/firmware/efi-capsule-file/loading
> 2.) cat capsule.bin > /sys/class/firmware/efi-capsule-file/data
> 3.) echo 0 > /sys/class/firmware/efi-capsule-file/loading
>
> Whereas, this module does not allow the capsule binaries to be
> obtained from the request_firmware library search path. If any
> capsule binary loaded from firmware seach path, the module will
> stop functioning.
>
> Besides the request_firmware user helper interface, this module
> also expose a 'capsule_loaded' file note for user to verify
> the number of successfully uploaded capsule binaries. This
> file note has the read only attribute.
>
> Cc: Matt Fleming 
> Signed-off-by: Kweh, Hock Leong 
> ---
>  drivers/firmware/efi/Kconfig   |   13 ++
>  drivers/firmware/efi/Makefile  |1 +
>  drivers/firmware/efi/efi-capsule-user-helper.c |  246 
> 
>  3 files changed, 260 insertions(+)
>  create mode 100644 drivers/firmware/efi/efi-capsule-user-helper.c
>
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index f712d47..7dc814e 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -60,6 +60,19 @@ config EFI_RUNTIME_WRAPPERS
>  config EFI_ARMSTUB
> bool
>
> +config EFI_CAPSULE_USER_HELPER
> +   tristate "EFI capsule user mode helper"
> +   depends on EFI
> +   select FW_LOADER
> +   select FW_LOADER_USER_HELPER
> +   help
> + This option exposes the user mode helper interface for user to load
> + EFI capsule binary and update the EFI firmware after system reboot.
> + This feature does not support auto locating capsule binaries at the
> + firmware lib search path.
> +
> + If unsure, say N.
> +
>  endmenu
>
>  config UEFI_CPER
> diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
> index 698846e..63f6910 100644
> --- a/drivers/firmware/efi/Makefile
> +++ b/drivers/firmware/efi/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_UEFI_CPER) += cper.o
>  obj-$(CONFIG_EFI_RUNTIME_MAP)  += runtime-map.o
>  obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
>  obj-$(CONFIG_EFI_STUB) += libstub/
> +obj-$(CONFIG_EFI_CAPSULE_USER_HELPER)  += efi-capsule-user-helper.o
> diff --git a/drivers/firmware/efi/efi-capsule-user-helper.c 
> b/drivers/firmware/efi/efi-capsule-user-helper.c
> new file mode 100644
> index 000..84a1628
> --- /dev/null
> +++ b/drivers/firmware/efi/efi-capsule-user-helper.c
> @@ -0,0 +1,246 @@
> +/*
> + * EFI capsule user mode helper interface driver.
> + *
> + * Copyright 2014 Intel Corporation
> + *
> + * This file is part of the Linux kernel, and is made available under
> + * the terms of the GNU General Public License version 2.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CAPSULE_NAME "efi-capsule-file"
> +#define DEV_NAME "efi_capsule_user_helper"
> +#define STRING_INTEGER_MAX_LENGTH 13
> +
> +static DEFINE_MUTEX(user_helper_lock);
> +static int capsule_count;
> +static int stop_request;
> +static struct platform_device *efi_capsule_pdev;
> +
> +/*
> + * This function will store the capsule binary and pass it to
> + * efi_capsule_update() API in capsule.c
> + */
> +static int efi_capsule_store(const struct firmware *fw)
> +{
> +   int i;
> +   int ret;
> +   int count = fw->size;
> +   int copy_size = (fw->size > PAGE_SIZE) ? PAGE_SIZE : fw->size;
> +   int pages_needed = ALIGN(fw->size, PAGE_SIZE) >> PAGE_SHIFT;
> +   struct page **pages;
> +   void *page_data;
> +   efi_capsule_header_t *capsule = NULL;
> +
> +   pages = kmalloc_array(pages_needed, sizeof(void *), GFP_KERNEL);
> +   if (!pages) {
> +   pr_err("%s: kmalloc_array() failed\n", __func__);
> +   return -ENOMEM;
> +   }
> +
> +   for (i = 0; i < pages_needed; i++) {
> +   pages[i] = alloc_page(GFP_KERNEL);
> +   if (!pages[i]) {
> +   pr_err("%s: alloc_page() failed\n", __func__);
> +   --i;
> +   ret = -ENOMEM;
> +   goto failed;
> +   }
> +   }
> +
> +   for (i = 0; i < pages_needed; i++) {
> +   page_data = kmap(pages[i]);
> +   memcpy(page_data, fw->data + (i * PAGE_SIZE), copy_size);
> +
> +   if (i == 0)
> +   capsule = (efi_capsule_header_t *)page_data;
> +   else
> 

Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Roy Franz]

On Sun, Nov 2, 2014 at 7:07 PM, Kweh Hock Leong
hock.leong.k...@intel.com wrote:
 From: Kweh, Hock Leong hock.leong.k...@intel.com

 Introducing a kernel module to expose user helper interface for
 user to upload capsule binaries. This module leverage the
 request_firmware_nowait() to expose an interface to user.

 Example steps to load the capsule binary:
 1.) echo 1  /sys/class/firmware/efi-capsule-file/loading
 2.) cat capsule.bin  /sys/class/firmware/efi-capsule-file/data
 3.) echo 0  /sys/class/firmware/efi-capsule-file/loading

 Whereas, this module does not allow the capsule binaries to be
 obtained from the request_firmware library search path. If any
 capsule binary loaded from firmware seach path, the module will
 stop functioning.

 Besides the request_firmware user helper interface, this module
 also expose a 'capsule_loaded' file note for user to verify
 the number of successfully uploaded capsule binaries. This
 file note has the read only attribute.

 Cc: Matt Fleming matt.flem...@intel.com
 Signed-off-by: Kweh, Hock Leong hock.leong.k...@intel.com
 ---
  drivers/firmware/efi/Kconfig   |   13 ++
  drivers/firmware/efi/Makefile  |1 +
  drivers/firmware/efi/efi-capsule-user-helper.c |  246 
 
  3 files changed, 260 insertions(+)
  create mode 100644 drivers/firmware/efi/efi-capsule-user-helper.c

 diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
 index f712d47..7dc814e 100644
 --- a/drivers/firmware/efi/Kconfig
 +++ b/drivers/firmware/efi/Kconfig
 @@ -60,6 +60,19 @@ config EFI_RUNTIME_WRAPPERS
  config EFI_ARMSTUB
 bool

 +config EFI_CAPSULE_USER_HELPER
 +   tristate EFI capsule user mode helper
 +   depends on EFI
 +   select FW_LOADER
 +   select FW_LOADER_USER_HELPER
 +   help
 + This option exposes the user mode helper interface for user to load
 + EFI capsule binary and update the EFI firmware after system reboot.
 + This feature does not support auto locating capsule binaries at the
 + firmware lib search path.
 +
 + If unsure, say N.
 +
  endmenu

  config UEFI_CPER
 diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
 index 698846e..63f6910 100644
 --- a/drivers/firmware/efi/Makefile
 +++ b/drivers/firmware/efi/Makefile
 @@ -8,3 +8,4 @@ obj-$(CONFIG_UEFI_CPER) += cper.o
  obj-$(CONFIG_EFI_RUNTIME_MAP)  += runtime-map.o
  obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
  obj-$(CONFIG_EFI_STUB) += libstub/
 +obj-$(CONFIG_EFI_CAPSULE_USER_HELPER)  += efi-capsule-user-helper.o
 diff --git a/drivers/firmware/efi/efi-capsule-user-helper.c 
 b/drivers/firmware/efi/efi-capsule-user-helper.c
 new file mode 100644
 index 000..84a1628
 --- /dev/null
 +++ b/drivers/firmware/efi/efi-capsule-user-helper.c
 @@ -0,0 +1,246 @@
 +/*
 + * EFI capsule user mode helper interface driver.
 + *
 + * Copyright 2014 Intel Corporation
 + *
 + * This file is part of the Linux kernel, and is made available under
 + * the terms of the GNU General Public License version 2.
 + */
 +
 +#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
 +
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/delay.h
 +#include linux/highmem.h
 +#include linux/slab.h
 +#include linux/mutex.h
 +#include linux/reboot.h
 +#include linux/efi.h
 +#include linux/firmware.h
 +
 +#define CAPSULE_NAME efi-capsule-file
 +#define DEV_NAME efi_capsule_user_helper
 +#define STRING_INTEGER_MAX_LENGTH 13
 +
 +static DEFINE_MUTEX(user_helper_lock);
 +static int capsule_count;
 +static int stop_request;
 +static struct platform_device *efi_capsule_pdev;
 +
 +/*
 + * This function will store the capsule binary and pass it to
 + * efi_capsule_update() API in capsule.c
 + */
 +static int efi_capsule_store(const struct firmware *fw)
 +{
 +   int i;
 +   int ret;
 +   int count = fw-size;
 +   int copy_size = (fw-size  PAGE_SIZE) ? PAGE_SIZE : fw-size;
 +   int pages_needed = ALIGN(fw-size, PAGE_SIZE)  PAGE_SHIFT;
 +   struct page **pages;
 +   void *page_data;
 +   efi_capsule_header_t *capsule = NULL;
 +
 +   pages = kmalloc_array(pages_needed, sizeof(void *), GFP_KERNEL);
 +   if (!pages) {
 +   pr_err(%s: kmalloc_array() failed\n, __func__);
 +   return -ENOMEM;
 +   }
 +
 +   for (i = 0; i  pages_needed; i++) {
 +   pages[i] = alloc_page(GFP_KERNEL);
 +   if (!pages[i]) {
 +   pr_err(%s: alloc_page() failed\n, __func__);
 +   --i;
 +   ret = -ENOMEM;
 +   goto failed;
 +   }
 +   }
 +
 +   for (i = 0; i  pages_needed; i++) {
 +   page_data = kmap(pages[i]);
 +   memcpy(page_data, fw-data + (i * PAGE_SIZE), copy_size);
 +
 +   if (i == 0)
 + 

Re: [PATCHv2] efi: efi-stub: notify on DTB absence

[Roy Franz]

On Thu, Oct 23, 2014 at 8:33 AM, Mark Rutland  wrote:
> Since v1 [1]:
> * Add a positive acknowledgement for a configuration table DTB
> * Fixed a couple of typos in the commit message
>
> Ard, Leif, Roy, I've assumed your acks from v1 are still valid with the
> additional print. Please shout if that's not the case.
>
> Thanks,
> Mark.
>
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295521.html
>
> >8
> In the absence of a DTB configuration table, the EFI stub will happily
> continue attempting to boot a kernel, despite the fact that this kernel
> may not function without a description of the hardware. In this case, as
> with a typo'd "dtb=" option (e.g. "dbt=") or many other possible
> failures, the only output seen by the user will be the rather terse
> output from the EFI stub:
>
> EFI stub: Booting Linux Kernel...
>
> To aid those attempting to debug such failures, this patch adds a notice
> when no DTB is found, making the output more helpful:
>
> EFI stub: Booting Linux Kernel...
> EFI stub: Generating empty DTB
>
> Additionally, a positive acknowledgement is added when a user-specified
> DTB is in use:
>
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from command line
>
> Similarly, a positive acknowledgement is added when a DTB from a
> configuration table is in use:
>
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
>
> Signed-off-by: Mark Rutland 
> Acked-by: Leif Lindholm 
> Acked-by: Ard Biesheuvel 
> Cc: Mark Salter 
> Cc: Matt Fleming 
> Acked-by: Roy Franz 
> ---
>  drivers/firmware/efi/libstub/arm-stub.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
> b/drivers/firmware/efi/libstub/arm-stub.c
> index 480339b..21fa50e 100644
> --- a/drivers/firmware/efi/libstub/arm-stub.c
> +++ b/drivers/firmware/efi/libstub/arm-stub.c
> @@ -243,9 +243,18 @@ unsigned long __init efi_entry(void *handle, 
> efi_system_table_t *sys_table,
> goto fail_free_cmdline;
> }
> }
> -   if (!fdt_addr)
> +
> +   if (fdt_addr) {
> +   pr_efi(sys_table, "Using DTB from command line\n");
> +   } else {
> /* Look for a device tree configuration table entry. */
> fdt_addr = (uintptr_t)get_fdt(sys_table);
> +   if (fdt_addr)
> +   pr_efi(sys_table, "Using DTB from configuration 
> table\n");
> +   }
> +
> +   if (!fdt_addr)
> +   pr_efi(sys_table, "Generating empty DTB\n");
>
> status = handle_cmdline_files(sys_table, image, cmdline_ptr,
>   "initrd=", dram_base + SZ_512M,
> --
> 1.9.1
>
Acked-by: Roy Franz 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2] efi: efi-stub: notify on DTB absence

[Roy Franz]

On Thu, Oct 23, 2014 at 8:33 AM, Mark Rutland mark.rutl...@arm.com wrote:
 Since v1 [1]:
 * Add a positive acknowledgement for a configuration table DTB
 * Fixed a couple of typos in the commit message

 Ard, Leif, Roy, I've assumed your acks from v1 are still valid with the
 additional print. Please shout if that's not the case.

 Thanks,
 Mark.

 [1] 
 http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295521.html

 8
 In the absence of a DTB configuration table, the EFI stub will happily
 continue attempting to boot a kernel, despite the fact that this kernel
 may not function without a description of the hardware. In this case, as
 with a typo'd dtb= option (e.g. dbt=) or many other possible
 failures, the only output seen by the user will be the rather terse
 output from the EFI stub:

 EFI stub: Booting Linux Kernel...

 To aid those attempting to debug such failures, this patch adds a notice
 when no DTB is found, making the output more helpful:

 EFI stub: Booting Linux Kernel...
 EFI stub: Generating empty DTB

 Additionally, a positive acknowledgement is added when a user-specified
 DTB is in use:

 EFI stub: Booting Linux Kernel...
 EFI stub: Using DTB from command line

 Similarly, a positive acknowledgement is added when a DTB from a
 configuration table is in use:

 EFI stub: Booting Linux Kernel...
 EFI stub: Using DTB from configuration table

 Signed-off-by: Mark Rutland mark.rutl...@arm.com
 Acked-by: Leif Lindholm leif.lindh...@linaro.org
 Acked-by: Ard Biesheuvel ard.biesheu...@linaro.org
 Cc: Mark Salter msal...@redhat.com
 Cc: Matt Fleming matt.flem...@intel.com
 Acked-by: Roy Franz roy.fr...@linaro.org
 ---
  drivers/firmware/efi/libstub/arm-stub.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

 diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
 b/drivers/firmware/efi/libstub/arm-stub.c
 index 480339b..21fa50e 100644
 --- a/drivers/firmware/efi/libstub/arm-stub.c
 +++ b/drivers/firmware/efi/libstub/arm-stub.c
 @@ -243,9 +243,18 @@ unsigned long __init efi_entry(void *handle, 
 efi_system_table_t *sys_table,
 goto fail_free_cmdline;
 }
 }
 -   if (!fdt_addr)
 +
 +   if (fdt_addr) {
 +   pr_efi(sys_table, Using DTB from command line\n);
 +   } else {
 /* Look for a device tree configuration table entry. */
 fdt_addr = (uintptr_t)get_fdt(sys_table);
 +   if (fdt_addr)
 +   pr_efi(sys_table, Using DTB from configuration 
 table\n);
 +   }
 +
 +   if (!fdt_addr)
 +   pr_efi(sys_table, Generating empty DTB\n);

 status = handle_cmdline_files(sys_table, image, cmdline_ptr,
   initrd=, dram_base + SZ_512M,
 --
 1.9.1

Acked-by: Roy Franz roy.fr...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] efi: efi-stub: notify on DTB absence

[Roy Franz]

On Mon, Oct 20, 2014 at 11:49 AM, Mark Salter  wrote:
> On Mon, 2014-10-20 at 19:29 +0100, Mark Rutland wrote:
>> In the absence of an DTB configuration table, the EFI stub will happily
>> continue attempting to boot a kernel, despite the fact that this kernel
>> may not function without a description of the hardware. In this case, as
>> with a typo'd "dtb=" option (e.g. "dbt=") or many other possible
>> failures, the only output seen by the user will be the rather terse
>> output from the EFI stub:
>>
>> EFI stub: Booting Linux Kernel...
>>
>> To aid those attempting to debug such failures, this patch adds a notice
>> when no DTB is found, making the output more helpful:
>>
>> EFI stub: Booting Linux Kernel...
>> EFI stub: Generating empty DTB
>>
>> Similarly, a positive acknowledgement is added when a user-specified DTB
>> is in use:
>>
>> EFI stub: Booting Linux Kernel...
>> EFI stub: Using DTB from command line
>

Acked-by: Roy Franz 


> Should we also include a positive acknowledgement of loader-provided
> DTB? This could be UEFI itself or grub devicetree command or grub
> generated minimal tree.

I could go either way on this.  We now identify the source of the DTB for 2 of
the 3 sources, so there is some nice symmetry in always identifying where
it is coming from.  I think that firmware or GRUB (ie from an EFI
configuration table)
will be the common/normal case, so I think it's also reasonable to
just notify the user
when something unusual is being done.

>
>>
>> Signed-off-by: Mark Rutland 
>> Acked-by: Leif Lindholm 
>> Cc: Ard Biesheuvel 
>> Cc: Mark Salter 
>> Cc: Matt Fleming 
>> Cc: Roy Franz 
>> ---
>>  drivers/firmware/efi/libstub/arm-stub.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
>> b/drivers/firmware/efi/libstub/arm-stub.c
>> index 480339b..10abf24 100644
>> --- a/drivers/firmware/efi/libstub/arm-stub.c
>> +++ b/drivers/firmware/efi/libstub/arm-stub.c
>> @@ -243,9 +243,16 @@ unsigned long __init efi_entry(void *handle, 
>> efi_system_table_t *sys_table,
>>   goto fail_free_cmdline;
>>   }
>>   }
>> - if (!fdt_addr)
>> +
>> + if (fdt_addr) {
>> + pr_efi(sys_table, "Using DTB from command line\n");
>> + } else {
>>   /* Look for a device tree configuration table entry. */
>>   fdt_addr = (uintptr_t)get_fdt(sys_table);
>> + }
>> +
>> + if (!fdt_addr)
>> + pr_efi(sys_table, "Generating empty DTB\n");
>>
>>   status = handle_cmdline_files(sys_table, image, cmdline_ptr,
>> "initrd=", dram_base + SZ_512M,
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] efi: efi-stub: notify on DTB absence

[Roy Franz]

On Mon, Oct 20, 2014 at 11:49 AM, Mark Salter msal...@redhat.com wrote:
 On Mon, 2014-10-20 at 19:29 +0100, Mark Rutland wrote:
 In the absence of an DTB configuration table, the EFI stub will happily
 continue attempting to boot a kernel, despite the fact that this kernel
 may not function without a description of the hardware. In this case, as
 with a typo'd dtb= option (e.g. dbt=) or many other possible
 failures, the only output seen by the user will be the rather terse
 output from the EFI stub:

 EFI stub: Booting Linux Kernel...

 To aid those attempting to debug such failures, this patch adds a notice
 when no DTB is found, making the output more helpful:

 EFI stub: Booting Linux Kernel...
 EFI stub: Generating empty DTB

 Similarly, a positive acknowledgement is added when a user-specified DTB
 is in use:

 EFI stub: Booting Linux Kernel...
 EFI stub: Using DTB from command line


Acked-by: Roy Franz roy.fr...@linaro.org


 Should we also include a positive acknowledgement of loader-provided
 DTB? This could be UEFI itself or grub devicetree command or grub
 generated minimal tree.

I could go either way on this.  We now identify the source of the DTB for 2 of
the 3 sources, so there is some nice symmetry in always identifying where
it is coming from.  I think that firmware or GRUB (ie from an EFI
configuration table)
will be the common/normal case, so I think it's also reasonable to
just notify the user
when something unusual is being done.



 Signed-off-by: Mark Rutland mark.rutl...@arm.com
 Acked-by: Leif Lindholm leif.lindh...@linaro.org
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Cc: Mark Salter msal...@redhat.com
 Cc: Matt Fleming matt.flem...@intel.com
 Cc: Roy Franz roy.fr...@linaro.org
 ---
  drivers/firmware/efi/libstub/arm-stub.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
 b/drivers/firmware/efi/libstub/arm-stub.c
 index 480339b..10abf24 100644
 --- a/drivers/firmware/efi/libstub/arm-stub.c
 +++ b/drivers/firmware/efi/libstub/arm-stub.c
 @@ -243,9 +243,16 @@ unsigned long __init efi_entry(void *handle, 
 efi_system_table_t *sys_table,
   goto fail_free_cmdline;
   }
   }
 - if (!fdt_addr)
 +
 + if (fdt_addr) {
 + pr_efi(sys_table, Using DTB from command line\n);
 + } else {
   /* Look for a device tree configuration table entry. */
   fdt_addr = (uintptr_t)get_fdt(sys_table);
 + }
 +
 + if (!fdt_addr)
 + pr_efi(sys_table, Generating empty DTB\n);

   status = handle_cmdline_files(sys_table, image, cmdline_ptr,
 initrd=, dram_base + SZ_512M,


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/16] MAINTAINERS: Use the correct efi-stub location

[Roy Franz]

On Thu, Jul 3, 2014 at 3:07 PM, Joe Perches  wrote:
> commit 4171fe2f8a47 ("EFI stub documentation updates") moved
> the file, update the pattern.
>
> Signed-off-by: Joe Perches 
> cc: Roy Franz 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a047941..e3531a5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3362,7 +3362,7 @@ M:Matt Fleming 
>  L: linux-...@vger.kernel.org
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
>  S: Maintained
> -F: Documentation/x86/efi-stub.txt
> +F: Documentation/efi-stub.txt
>  F: arch/ia64/kernel/efi.c
>  F: arch/x86/boot/compressed/eboot.[ch]
>  F:     arch/x86/include/asm/efi.h
> --
> 1.8.1.2.459.gbcd45b4.dirty
>
Acked-by: Roy Franz 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/16] MAINTAINERS: Use the correct efi-stub location

[Roy Franz]

On Thu, Jul 3, 2014 at 3:07 PM, Joe Perches j...@perches.com wrote:
 commit 4171fe2f8a47 (EFI stub documentation updates) moved
 the file, update the pattern.

 Signed-off-by: Joe Perches j...@perches.com
 cc: Roy Franz roy.fr...@linaro.org
 ---
  MAINTAINERS | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/MAINTAINERS b/MAINTAINERS
 index a047941..e3531a5 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -3362,7 +3362,7 @@ M:Matt Fleming matt.flem...@intel.com
  L: linux-...@vger.kernel.org
  T: git git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
  S: Maintained
 -F: Documentation/x86/efi-stub.txt
 +F: Documentation/efi-stub.txt
  F: arch/ia64/kernel/efi.c
  F: arch/x86/boot/compressed/eboot.[ch]
  F: arch/x86/include/asm/efi.h
 --
 1.8.1.2.459.gbcd45b4.dirty

Acked-by: Roy Franz roy.fr...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add efi_early_call() macro

[Roy Franz]

On Wed, Mar 26, 2014 at 1:59 AM, Matt Fleming  wrote:
> On Tue, 25 Mar, at 03:40:30PM, Roy Franz wrote:
>> Add the efi_early_call() macro to invoke functions in the efi_early
>> structure. Using a macro for these invocations allows the arm32/arm64
>> architectures to define the macro differently so that they can directly
>> invoke the boot services functions that are exposed in the efi_early
>> structure on x86. Prior to the introduction of the efi_early structure
>> the efi_call_physN macros were used on all architectures and allowed
>> for this differentiation.
>>
>> Signed-off-by: Roy Franz 
>> ---
>>  arch/x86/boot/compressed/eboot.c   |5 +
>>  drivers/firmware/efi/efi-stub-helper.c |   26 +-
>>  2 files changed, 18 insertions(+), 13 deletions(-)
>
> Confused.
>
> Why have you rewritten the patch that I sent Satuday morning?
>
>   https://lkml.org/lkml/2014/3/22/61
>
> I don't think your version goes far enough because you've left all the
> efi_early->call() stuff in eboot.c. So now there's two ways to invoke
> EFI functions in the x86 boot stub.
>
> What's wrong with the patch that I sent?
>
> --
> Matt Fleming, Intel Open Source Technology Center

Hi Matt,

   Sorry for the confusion - your patch is fine.  I had somehow not noticed
it on your reply.

Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add efi_early_call() macro

[Roy Franz]

On Wed, Mar 26, 2014 at 1:59 AM, Matt Fleming m...@console-pimps.org wrote:
 On Tue, 25 Mar, at 03:40:30PM, Roy Franz wrote:
 Add the efi_early_call() macro to invoke functions in the efi_early
 structure. Using a macro for these invocations allows the arm32/arm64
 architectures to define the macro differently so that they can directly
 invoke the boot services functions that are exposed in the efi_early
 structure on x86. Prior to the introduction of the efi_early structure
 the efi_call_physN macros were used on all architectures and allowed
 for this differentiation.

 Signed-off-by: Roy Franz roy.fr...@linaro.org
 ---
  arch/x86/boot/compressed/eboot.c   |5 +
  drivers/firmware/efi/efi-stub-helper.c |   26 +-
  2 files changed, 18 insertions(+), 13 deletions(-)

 Confused.

 Why have you rewritten the patch that I sent Satuday morning?

   https://lkml.org/lkml/2014/3/22/61

 I don't think your version goes far enough because you've left all the
 efi_early-call() stuff in eboot.c. So now there's two ways to invoke
 EFI functions in the x86 boot stub.

 What's wrong with the patch that I sent?

 --
 Matt Fleming, Intel Open Source Technology Center

Hi Matt,

   Sorry for the confusion - your patch is fine.  I had somehow not noticed
it on your reply.

Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 06/13] x86/efi: Build our own EFI services pointer table

[Roy Franz]

On Sat, Mar 22, 2014 at 1:16 PM, Roy Franz  wrote:
> On Sat, Mar 22, 2014 at 4:05 AM, Matt Fleming  wrote:
>> On Fri, 21 Mar, at 05:52:29PM, Roy Franz wrote:
>>>
>>> For both arm32 and arm64 the Linux and EFI calling conventions are the
>>> same, so we are directly invoking the function pointers in the
>>> boot_services table.  This gives us type checking of those calls,
>>> which is nice.The efi_call_physN macros for ARM are currently simply:
>>> #define efi_call_phys2(f, a1, a2)f(a1, a2)
>>>
>>> With the changes in this patch, we can't do this anymore, as we were
>>> relying on some macro processing to handle this differently on ARM.
>>
>> But on the plus side, you no longer have to implement all those
>> efi_call_physX() macros ;-)
>>
>>> I'd like to propose something like for following (my variadic macros
>>> may not be quite right)
>>>
>>> for x86:
>>> #define efi_call_early(...) efi_early->call(__VA_ARGS__)
>>>
>>> for arm it would be:
>>> #define efi_call_early(function, ...) efi_early->function(__VA_ARGS__)
>>
>> Close enough.
>>
>>> This would allow us to define the efi_config struct with typed
>>> function pointers for ARM, and retain the direct invocation along with
>>> type checking.  This returns to using a macro, but I think we should
>>> be able to use a variadic macro instead of the 6 separate macros we
>>> had before.
>>>
>>> I plan to use the above technique to incorporate these changes into
>>> arm64/arm32, barring any better ideas or objections.
>>
>> Actually, this should be enough to fix this up on ARM,
>>
>> #define efi_call_early(f, ...)  \
>> sys_table_arg->boottime->f(__VA_ARGS__);
>>
>> Then you don't need any of the efi_config stuff.
>
> Even better.  I had overlooked that the efi_config variables had identical 
> names
> as the boot services.

I have sent a patch (attempted to reply using git-send-email) that
adds the macro
for x86 and updates efi-stub-helper.c.  If you could add this to your series for
3.15 that would be great, as then we would not have any x86 changes in
the ARM EFI stub series.

Thanks,
Roy


>>
>> Yes, the fact that we're making use of the sys_table_arg is invisible at
>> the call-site, but meh. Not sure that's a big deal. It allows us to use
>> efi_call_early() in the x86 code without needlessly passing 'sys_table'
>> around, since we've got a global pointer to it anyhow.
>>
>> -- >8 --
>>
>> From 5fcc1036d143802e321a745b2c3d793ddb8369ac Mon Sep 17 00:00:00 2001
>> From: Matt Fleming 
>> Date: Sat, 22 Mar 2014 10:09:01 +
>> Subject: [PATCH] efi: Abstract x86 efi_early calls
>>
>> The ARM EFI boot stub doesn't need to care about the efi_early
>> infrastructure that x86 requires in order to do mixed mode thunking. So
>> wrap everything up in an efi_call_early() macro, which saves ARM having
>> to implement efi_config.
>>
>> This allows x86 to do the necessary indirect jumps to call whatever
>> firmware interface is available (native or mixed mode), and at the same
>> time allows ARM to use the C type system for parameter checking by
>> implementing efi_early_call() like so,
>>
>> #define efi_call_early(f, ...)  \
>> system_table_arg->boottime->f(__VA_ARGS__);
>>
>> Signed-off-by: Matt Fleming 
>> ---
>>  arch/x86/boot/compressed/eboot.c   | 155 
>> -
>>  drivers/firmware/efi/efi-stub-helper.c |  44 +-
>>  2 files changed, 98 insertions(+), 101 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/eboot.c 
>> b/arch/x86/boot/compressed/eboot.c
>> index 5e1ba4fa3f79..1e6146137f8e 100644
>> --- a/arch/x86/boot/compressed/eboot.c
>> +++ b/arch/x86/boot/compressed/eboot.c
>> @@ -21,6 +21,9 @@ static efi_system_table_t *sys_table;
>>
>>  static struct efi_config *efi_early;
>>
>> +#define efi_call_early(f, ...) \
>> +   efi_early->call(efi_early->f, __VA_ARGS__);
>> +
>>  #define BOOT_SERVICES(bits)\
>>  static void setup_boot_services##bits(struct efi_config *c)\
>>  {  \
>> @@ -78,8 +81,8 @@ __file_size32(void *__fh, efi_char16_t *filename_16,
>> }
>>
>>  grow:

[PATCH] Add efi_early_call() macro

[Roy Franz]

Add the efi_early_call() macro to invoke functions in the efi_early
structure. Using a macro for these invocations allows the arm32/arm64
architectures to define the macro differently so that they can directly
invoke the boot services functions that are exposed in the efi_early
structure on x86. Prior to the introduction of the efi_early structure
the efi_call_physN macros were used on all architectures and allowed
for this differentiation.

Signed-off-by: Roy Franz 
---
 arch/x86/boot/compressed/eboot.c   |5 +
 drivers/firmware/efi/efi-stub-helper.c |   26 +-
 2 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 5e1ba4f..374de94 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -44,6 +44,11 @@ static void setup_boot_services##bits(struct efi_config *c)  
\
 }
 BOOT_SERVICES(32);
 BOOT_SERVICES(64);
+/*
+ * Use macro to invoke efi_early->call so that on ARM this macro can
+ * implement a direct call.*
+ */
+#define efi_early_call(...) efi_early->call(efi_early->__VA_ARGS__)
 
 static void efi_printk(efi_system_table_t *, char *);
 static void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index a028287..be58a18 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -53,22 +53,22 @@ again:
 * allocation which may be in a new descriptor region.
 */
*map_size += sizeof(*m);
-   status = efi_early->call(efi_early->allocate_pool, EFI_LOADER_DATA,
+   status = efi_early_call(allocate_pool, EFI_LOADER_DATA,
 *map_size, (void **));
if (status != EFI_SUCCESS)
goto fail;
 
*desc_size = 0;
key = 0;
-   status = efi_early->call(efi_early->get_memory_map, map_size, m,
+   status = efi_early_call(get_memory_map, map_size, m,
 , desc_size, _version);
if (status == EFI_BUFFER_TOO_SMALL) {
-   efi_early->call(efi_early->free_pool, m);
+   efi_early_call(free_pool, m);
goto again;
}
 
if (status != EFI_SUCCESS)
-   efi_early->call(efi_early->free_pool, m);
+   efi_early_call(free_pool, m);
 
if (key_ptr && status == EFI_SUCCESS)
*key_ptr = key;
@@ -149,7 +149,7 @@ again:
if (!max_addr)
status = EFI_NOT_FOUND;
else {
-   status = efi_early->call(efi_early->allocate_pages,
+   status = efi_early_call(allocate_pages,
 EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
 nr_pages, _addr);
if (status != EFI_SUCCESS) {
@@ -161,7 +161,7 @@ again:
*addr = max_addr;
}
 
-   efi_early->call(efi_early->free_pool, map);
+   efi_early_call(free_pool, map);
 fail:
return status;
 }
@@ -221,7 +221,7 @@ static efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
if ((start + size) > end)
continue;
 
-   status = efi_early->call(efi_early->allocate_pages,
+   status = efi_early_call(allocate_pages,
 EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
 nr_pages, );
if (status == EFI_SUCCESS) {
@@ -233,7 +233,7 @@ static efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
if (i == map_size / desc_size)
status = EFI_NOT_FOUND;
 
-   efi_early->call(efi_early->free_pool, map);
+   efi_early_call(free_pool, map);
 fail:
return status;
 }
@@ -247,7 +247,7 @@ static void efi_free(efi_system_table_t *sys_table_arg, 
unsigned long size,
return;
 
nr_pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
-   efi_early->call(efi_early->free_pages, addr, nr_pages);
+   efi_early_call(free_pages, addr, nr_pages);
 }
 
 
@@ -307,7 +307,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
if (!nr_files)
return EFI_SUCCESS;
 
-   status = efi_early->call(efi_early->allocate_pool, EFI_LOADER_DATA,
+   status = efi_early_call(allocate_pool, EFI_LOADER_DATA,
 nr_files * sizeof(*files), (void **));
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to alloc mem for file handle 
list\n");
@@ -413,7 +413,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
 
}
 
-   efi_early->call(efi_early->free_pool, files);
+   efi_earl

[PATCH] Add efi_early_call() macro

[Roy Franz]

Add the efi_early_call() macro to invoke functions in the efi_early
structure. Using a macro for these invocations allows the arm32/arm64
architectures to define the macro differently so that they can directly
invoke the boot services functions that are exposed in the efi_early
structure on x86. Prior to the introduction of the efi_early structure
the efi_call_physN macros were used on all architectures and allowed
for this differentiation.

Signed-off-by: Roy Franz roy.fr...@linaro.org
---
 arch/x86/boot/compressed/eboot.c   |5 +
 drivers/firmware/efi/efi-stub-helper.c |   26 +-
 2 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 5e1ba4f..374de94 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -44,6 +44,11 @@ static void setup_boot_services##bits(struct efi_config *c)  
\
 }
 BOOT_SERVICES(32);
 BOOT_SERVICES(64);
+/*
+ * Use macro to invoke efi_early-call so that on ARM this macro can
+ * implement a direct call.*
+ */
+#define efi_early_call(...) efi_early-call(efi_early-__VA_ARGS__)
 
 static void efi_printk(efi_system_table_t *, char *);
 static void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index a028287..be58a18 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -53,22 +53,22 @@ again:
 * allocation which may be in a new descriptor region.
 */
*map_size += sizeof(*m);
-   status = efi_early-call(efi_early-allocate_pool, EFI_LOADER_DATA,
+   status = efi_early_call(allocate_pool, EFI_LOADER_DATA,
 *map_size, (void **)m);
if (status != EFI_SUCCESS)
goto fail;
 
*desc_size = 0;
key = 0;
-   status = efi_early-call(efi_early-get_memory_map, map_size, m,
+   status = efi_early_call(get_memory_map, map_size, m,
 key, desc_size, desc_version);
if (status == EFI_BUFFER_TOO_SMALL) {
-   efi_early-call(efi_early-free_pool, m);
+   efi_early_call(free_pool, m);
goto again;
}
 
if (status != EFI_SUCCESS)
-   efi_early-call(efi_early-free_pool, m);
+   efi_early_call(free_pool, m);
 
if (key_ptr  status == EFI_SUCCESS)
*key_ptr = key;
@@ -149,7 +149,7 @@ again:
if (!max_addr)
status = EFI_NOT_FOUND;
else {
-   status = efi_early-call(efi_early-allocate_pages,
+   status = efi_early_call(allocate_pages,
 EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
 nr_pages, max_addr);
if (status != EFI_SUCCESS) {
@@ -161,7 +161,7 @@ again:
*addr = max_addr;
}
 
-   efi_early-call(efi_early-free_pool, map);
+   efi_early_call(free_pool, map);
 fail:
return status;
 }
@@ -221,7 +221,7 @@ static efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
if ((start + size)  end)
continue;
 
-   status = efi_early-call(efi_early-allocate_pages,
+   status = efi_early_call(allocate_pages,
 EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
 nr_pages, start);
if (status == EFI_SUCCESS) {
@@ -233,7 +233,7 @@ static efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
if (i == map_size / desc_size)
status = EFI_NOT_FOUND;
 
-   efi_early-call(efi_early-free_pool, map);
+   efi_early_call(free_pool, map);
 fail:
return status;
 }
@@ -247,7 +247,7 @@ static void efi_free(efi_system_table_t *sys_table_arg, 
unsigned long size,
return;
 
nr_pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
-   efi_early-call(efi_early-free_pages, addr, nr_pages);
+   efi_early_call(free_pages, addr, nr_pages);
 }
 
 
@@ -307,7 +307,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
if (!nr_files)
return EFI_SUCCESS;
 
-   status = efi_early-call(efi_early-allocate_pool, EFI_LOADER_DATA,
+   status = efi_early_call(allocate_pool, EFI_LOADER_DATA,
 nr_files * sizeof(*files), (void **)files);
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, Failed to alloc mem for file handle 
list\n);
@@ -413,7 +413,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
 
}
 
-   efi_early-call(efi_early-free_pool, files);
+   efi_early_call(free_pool, files);
 
*load_addr = file_addr;
*load_size

Re: [PATCH v2 06/13] x86/efi: Build our own EFI services pointer table

[Roy Franz]

On Sat, Mar 22, 2014 at 1:16 PM, Roy Franz roy.fr...@linaro.org wrote:
 On Sat, Mar 22, 2014 at 4:05 AM, Matt Fleming m...@console-pimps.org wrote:
 On Fri, 21 Mar, at 05:52:29PM, Roy Franz wrote:

 For both arm32 and arm64 the Linux and EFI calling conventions are the
 same, so we are directly invoking the function pointers in the
 boot_services table.  This gives us type checking of those calls,
 which is nice.The efi_call_physN macros for ARM are currently simply:
 #define efi_call_phys2(f, a1, a2)f(a1, a2)

 With the changes in this patch, we can't do this anymore, as we were
 relying on some macro processing to handle this differently on ARM.

 But on the plus side, you no longer have to implement all those
 efi_call_physX() macros ;-)

 I'd like to propose something like for following (my variadic macros
 may not be quite right)

 for x86:
 #define efi_call_early(...) efi_early-call(__VA_ARGS__)

 for arm it would be:
 #define efi_call_early(function, ...) efi_early-function(__VA_ARGS__)

 Close enough.

 This would allow us to define the efi_config struct with typed
 function pointers for ARM, and retain the direct invocation along with
 type checking.  This returns to using a macro, but I think we should
 be able to use a variadic macro instead of the 6 separate macros we
 had before.

 I plan to use the above technique to incorporate these changes into
 arm64/arm32, barring any better ideas or objections.

 Actually, this should be enough to fix this up on ARM,

 #define efi_call_early(f, ...)  \
 sys_table_arg-boottime-f(__VA_ARGS__);

 Then you don't need any of the efi_config stuff.

 Even better.  I had overlooked that the efi_config variables had identical 
 names
 as the boot services.

I have sent a patch (attempted to reply using git-send-email) that
adds the macro
for x86 and updates efi-stub-helper.c.  If you could add this to your series for
3.15 that would be great, as then we would not have any x86 changes in
the ARM EFI stub series.

Thanks,
Roy



 Yes, the fact that we're making use of the sys_table_arg is invisible at
 the call-site, but meh. Not sure that's a big deal. It allows us to use
 efi_call_early() in the x86 code without needlessly passing 'sys_table'
 around, since we've got a global pointer to it anyhow.

 -- 8 --

 From 5fcc1036d143802e321a745b2c3d793ddb8369ac Mon Sep 17 00:00:00 2001
 From: Matt Fleming matt.flem...@intel.com
 Date: Sat, 22 Mar 2014 10:09:01 +
 Subject: [PATCH] efi: Abstract x86 efi_early calls

 The ARM EFI boot stub doesn't need to care about the efi_early
 infrastructure that x86 requires in order to do mixed mode thunking. So
 wrap everything up in an efi_call_early() macro, which saves ARM having
 to implement efi_config.

 This allows x86 to do the necessary indirect jumps to call whatever
 firmware interface is available (native or mixed mode), and at the same
 time allows ARM to use the C type system for parameter checking by
 implementing efi_early_call() like so,

 #define efi_call_early(f, ...)  \
 system_table_arg-boottime-f(__VA_ARGS__);

 Signed-off-by: Matt Fleming matt.flem...@intel.com
 ---
  arch/x86/boot/compressed/eboot.c   | 155 
 -
  drivers/firmware/efi/efi-stub-helper.c |  44 +-
  2 files changed, 98 insertions(+), 101 deletions(-)

 diff --git a/arch/x86/boot/compressed/eboot.c 
 b/arch/x86/boot/compressed/eboot.c
 index 5e1ba4fa3f79..1e6146137f8e 100644
 --- a/arch/x86/boot/compressed/eboot.c
 +++ b/arch/x86/boot/compressed/eboot.c
 @@ -21,6 +21,9 @@ static efi_system_table_t *sys_table;

  static struct efi_config *efi_early;

 +#define efi_call_early(f, ...) \
 +   efi_early-call(efi_early-f, __VA_ARGS__);
 +
  #define BOOT_SERVICES(bits)\
  static void setup_boot_services##bits(struct efi_config *c)\
  {  \
 @@ -78,8 +81,8 @@ __file_size32(void *__fh, efi_char16_t *filename_16,
 }

  grow:
 -   status = efi_early-call(efi_early-allocate_pool, EFI_LOADER_DATA,
 -info_sz, (void **)info);
 +   status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
 +   info_sz, (void **)info);
 if (status != EFI_SUCCESS) {
 efi_printk(sys_table, Failed to alloc mem for file info\n);
 return status;
 @@ -88,12 +91,12 @@ grow:
 status = efi_early-call((unsigned long)h-get_info, h, info_guid,
  info_sz, info);
 if (status == EFI_BUFFER_TOO_SMALL) {
 -   efi_early-call(efi_early-free_pool, info);
 +   efi_call_early(free_pool, info);
 goto grow;
 }

 *file_sz = info-file_size;
 -   efi_early

Re: [PATCH v2 06/13] x86/efi: Build our own EFI services pointer table

[Roy Franz]

On Sat, Mar 22, 2014 at 4:05 AM, Matt Fleming  wrote:
> On Fri, 21 Mar, at 05:52:29PM, Roy Franz wrote:
>>
>> For both arm32 and arm64 the Linux and EFI calling conventions are the
>> same, so we are directly invoking the function pointers in the
>> boot_services table.  This gives us type checking of those calls,
>> which is nice.The efi_call_physN macros for ARM are currently simply:
>> #define efi_call_phys2(f, a1, a2)f(a1, a2)
>>
>> With the changes in this patch, we can't do this anymore, as we were
>> relying on some macro processing to handle this differently on ARM.
>
> But on the plus side, you no longer have to implement all those
> efi_call_physX() macros ;-)
>
>> I'd like to propose something like for following (my variadic macros
>> may not be quite right)
>>
>> for x86:
>> #define efi_call_early(...) efi_early->call(__VA_ARGS__)
>>
>> for arm it would be:
>> #define efi_call_early(function, ...) efi_early->function(__VA_ARGS__)
>
> Close enough.
>
>> This would allow us to define the efi_config struct with typed
>> function pointers for ARM, and retain the direct invocation along with
>> type checking.  This returns to using a macro, but I think we should
>> be able to use a variadic macro instead of the 6 separate macros we
>> had before.
>>
>> I plan to use the above technique to incorporate these changes into
>> arm64/arm32, barring any better ideas or objections.
>
> Actually, this should be enough to fix this up on ARM,
>
> #define efi_call_early(f, ...)  \
> sys_table_arg->boottime->f(__VA_ARGS__);
>
> Then you don't need any of the efi_config stuff.

Even better.  I had overlooked that the efi_config variables had identical names
as the boot services.
>
> Yes, the fact that we're making use of the sys_table_arg is invisible at
> the call-site, but meh. Not sure that's a big deal. It allows us to use
> efi_call_early() in the x86 code without needlessly passing 'sys_table'
> around, since we've got a global pointer to it anyhow.
>
> -- >8 --
>
> From 5fcc1036d143802e321a745b2c3d793ddb8369ac Mon Sep 17 00:00:00 2001
> From: Matt Fleming 
> Date: Sat, 22 Mar 2014 10:09:01 +
> Subject: [PATCH] efi: Abstract x86 efi_early calls
>
> The ARM EFI boot stub doesn't need to care about the efi_early
> infrastructure that x86 requires in order to do mixed mode thunking. So
> wrap everything up in an efi_call_early() macro, which saves ARM having
> to implement efi_config.
>
> This allows x86 to do the necessary indirect jumps to call whatever
> firmware interface is available (native or mixed mode), and at the same
> time allows ARM to use the C type system for parameter checking by
> implementing efi_early_call() like so,
>
> #define efi_call_early(f, ...)  \
> system_table_arg->boottime->f(__VA_ARGS__);
>
> Signed-off-by: Matt Fleming 
> ---
>  arch/x86/boot/compressed/eboot.c   | 155 
> -
>  drivers/firmware/efi/efi-stub-helper.c |  44 +-
>  2 files changed, 98 insertions(+), 101 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/eboot.c 
> b/arch/x86/boot/compressed/eboot.c
> index 5e1ba4fa3f79..1e6146137f8e 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -21,6 +21,9 @@ static efi_system_table_t *sys_table;
>
>  static struct efi_config *efi_early;
>
> +#define efi_call_early(f, ...) \
> +   efi_early->call(efi_early->f, __VA_ARGS__);
> +
>  #define BOOT_SERVICES(bits)\
>  static void setup_boot_services##bits(struct efi_config *c)\
>  {  \
> @@ -78,8 +81,8 @@ __file_size32(void *__fh, efi_char16_t *filename_16,
> }
>
>  grow:
> -   status = efi_early->call(efi_early->allocate_pool, EFI_LOADER_DATA,
> -info_sz, (void **));
> +   status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
> +   info_sz, (void **));
> if (status != EFI_SUCCESS) {
> efi_printk(sys_table, "Failed to alloc mem for file info\n");
> return status;
> @@ -88,12 +91,12 @@ grow:
> status = efi_early->call((unsigned long)h->get_info, h, _guid,
>  _sz, info);
> if (status == EFI_BUFFER_TOO_SMALL) {
> -   efi_early->call(efi_

Re: [PATCH v2 06/13] x86/efi: Build our own EFI services pointer table

[Roy Franz]

On Sat, Mar 22, 2014 at 4:05 AM, Matt Fleming m...@console-pimps.org wrote:
 On Fri, 21 Mar, at 05:52:29PM, Roy Franz wrote:

 For both arm32 and arm64 the Linux and EFI calling conventions are the
 same, so we are directly invoking the function pointers in the
 boot_services table.  This gives us type checking of those calls,
 which is nice.The efi_call_physN macros for ARM are currently simply:
 #define efi_call_phys2(f, a1, a2)f(a1, a2)

 With the changes in this patch, we can't do this anymore, as we were
 relying on some macro processing to handle this differently on ARM.

 But on the plus side, you no longer have to implement all those
 efi_call_physX() macros ;-)

 I'd like to propose something like for following (my variadic macros
 may not be quite right)

 for x86:
 #define efi_call_early(...) efi_early-call(__VA_ARGS__)

 for arm it would be:
 #define efi_call_early(function, ...) efi_early-function(__VA_ARGS__)

 Close enough.

 This would allow us to define the efi_config struct with typed
 function pointers for ARM, and retain the direct invocation along with
 type checking.  This returns to using a macro, but I think we should
 be able to use a variadic macro instead of the 6 separate macros we
 had before.

 I plan to use the above technique to incorporate these changes into
 arm64/arm32, barring any better ideas or objections.

 Actually, this should be enough to fix this up on ARM,

 #define efi_call_early(f, ...)  \
 sys_table_arg-boottime-f(__VA_ARGS__);

 Then you don't need any of the efi_config stuff.

Even better.  I had overlooked that the efi_config variables had identical names
as the boot services.

 Yes, the fact that we're making use of the sys_table_arg is invisible at
 the call-site, but meh. Not sure that's a big deal. It allows us to use
 efi_call_early() in the x86 code without needlessly passing 'sys_table'
 around, since we've got a global pointer to it anyhow.

 -- 8 --

 From 5fcc1036d143802e321a745b2c3d793ddb8369ac Mon Sep 17 00:00:00 2001
 From: Matt Fleming matt.flem...@intel.com
 Date: Sat, 22 Mar 2014 10:09:01 +
 Subject: [PATCH] efi: Abstract x86 efi_early calls

 The ARM EFI boot stub doesn't need to care about the efi_early
 infrastructure that x86 requires in order to do mixed mode thunking. So
 wrap everything up in an efi_call_early() macro, which saves ARM having
 to implement efi_config.

 This allows x86 to do the necessary indirect jumps to call whatever
 firmware interface is available (native or mixed mode), and at the same
 time allows ARM to use the C type system for parameter checking by
 implementing efi_early_call() like so,

 #define efi_call_early(f, ...)  \
 system_table_arg-boottime-f(__VA_ARGS__);

 Signed-off-by: Matt Fleming matt.flem...@intel.com
 ---
  arch/x86/boot/compressed/eboot.c   | 155 
 -
  drivers/firmware/efi/efi-stub-helper.c |  44 +-
  2 files changed, 98 insertions(+), 101 deletions(-)

 diff --git a/arch/x86/boot/compressed/eboot.c 
 b/arch/x86/boot/compressed/eboot.c
 index 5e1ba4fa3f79..1e6146137f8e 100644
 --- a/arch/x86/boot/compressed/eboot.c
 +++ b/arch/x86/boot/compressed/eboot.c
 @@ -21,6 +21,9 @@ static efi_system_table_t *sys_table;

  static struct efi_config *efi_early;

 +#define efi_call_early(f, ...) \
 +   efi_early-call(efi_early-f, __VA_ARGS__);
 +
  #define BOOT_SERVICES(bits)\
  static void setup_boot_services##bits(struct efi_config *c)\
  {  \
 @@ -78,8 +81,8 @@ __file_size32(void *__fh, efi_char16_t *filename_16,
 }

  grow:
 -   status = efi_early-call(efi_early-allocate_pool, EFI_LOADER_DATA,
 -info_sz, (void **)info);
 +   status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
 +   info_sz, (void **)info);
 if (status != EFI_SUCCESS) {
 efi_printk(sys_table, Failed to alloc mem for file info\n);
 return status;
 @@ -88,12 +91,12 @@ grow:
 status = efi_early-call((unsigned long)h-get_info, h, info_guid,
  info_sz, info);
 if (status == EFI_BUFFER_TOO_SMALL) {
 -   efi_early-call(efi_early-free_pool, info);
 +   efi_call_early(free_pool, info);
 goto grow;
 }

 *file_sz = info-file_size;
 -   efi_early-call(efi_early-free_pool, info);
 +   efi_call_early(free_pool, info);

 if (status != EFI_SUCCESS)
 efi_printk(sys_table, Failed to get initrd info\n);
 @@ -131,8 +134,8 @@ __file_size64(void *__fh, efi_char16_t *filename_16,
 }

  grow:
 -   status = efi_early-call(efi_early-allocate_pool, EFI_LOADER_DATA

Re: [PATCH v2 06/13] x86/efi: Build our own EFI services pointer table

[Roy Franz]

On Tue, Mar 4, 2014 at 5:14 AM, Matt Fleming  wrote:
> From: Matt Fleming 
>
> It's not possible to dereference the EFI System table directly when
> booting a 64-bit kernel on a 32-bit EFI firmware because the size of
> pointers don't match.
>
> In preparation for supporting the above use case, build a list of
> function pointers on boot so that callers don't have to worry about
> converting pointer sizes through multiple levels of indirection.
>
> Signed-off-by: Matt Fleming 
> ---
>  arch/x86/boot/compressed/eboot.c   | 319 
> -
>  arch/x86/boot/compressed/eboot.h   |  16 ++
>  arch/x86/boot/compressed/head_32.S |  48 -
>  arch/x86/boot/compressed/head_64.S |  57 --
>  drivers/firmware/efi/efi-stub-helper.c | 148 ---
>  5 files changed, 377 insertions(+), 211 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/eboot.c 
> b/arch/x86/boot/compressed/eboot.c
> index a7677babf946..42548168bdc3 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -19,10 +19,145 @@
>
>  static efi_system_table_t *sys_table;
>
> +static struct efi_config *efi_early;
> +
> +#define BOOT_SERVICES(bits)\
> +static void setup_boot_services##bits(struct efi_config *c)\
> +{  \
> +   efi_system_table_##bits##_t *table; \
> +   efi_boot_services_##bits##_t *bt;   \
> +   \
> +   table = (typeof(table))sys_table;   \
> +   \
> +   c->text_output = table->con_out;\
> +   \
> +   bt = (typeof(bt))(unsigned long)(table->boottime);  \
> +   \
> +   c->allocate_pool = bt->allocate_pool;   \
> +   c->allocate_pages = bt->allocate_pages; \
> +   c->get_memory_map = bt->get_memory_map; \
> +   c->free_pool = bt->free_pool;   \
> +   c->free_pages = bt->free_pages; \
> +   c->locate_handle = bt->locate_handle;   \
> +   c->handle_protocol = bt->handle_protocol;   \
> +   c->exit_boot_services = bt->exit_boot_services; \
> +}
> +BOOT_SERVICES(32);
> +BOOT_SERVICES(64);
>
> -#include "../../../../drivers/firmware/efi/efi-stub-helper.c"
> +static void efi_printk(efi_system_table_t *, char *);
> +static void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
> +
> +static efi_status_t
> +efi_file_size(efi_system_table_t *sys_table, void *__fh,
> + efi_char16_t *filename_16, void **handle, u64 *file_sz)
> +{
> +   efi_file_handle_t *h, *fh = __fh;
> +   efi_file_info_t *info;
> +   efi_status_t status;
> +   efi_guid_t info_guid = EFI_FILE_INFO_ID;
> +   u32 info_sz;
> +
> +   status = efi_early->call((unsigned long)fh->open, fh, , filename_16,
> +EFI_FILE_MODE_READ, (u64)0);
> +   if (status != EFI_SUCCESS) {
> +   efi_printk(sys_table, "Failed to open file: ");
> +   efi_char16_printk(sys_table, filename_16);
> +   efi_printk(sys_table, "\n");
> +   return status;
> +   }
> +
> +   *handle = h;
> +
> +   info_sz = 0;
> +   status = efi_early->call((unsigned long)h->get_info, h, _guid,
> +_sz, NULL);
> +   if (status != EFI_BUFFER_TOO_SMALL) {
> +   efi_printk(sys_table, "Failed to get file info size\n");
> +   return status;
> +   }
> +
> +grow:
> +   status = efi_early->call(efi_early->allocate_pool, EFI_LOADER_DATA,
> +info_sz, (void **));
> +   if (status != EFI_SUCCESS) {
> +   efi_printk(sys_table, "Failed to alloc mem for file info\n");
> +   return status;
> +   }
> +
> +   status = efi_early->call((unsigned long)h->get_info, h, _guid,
> +_sz, info);
> +   if (status == EFI_BUFFER_TOO_SMALL) {
> +   efi_early->call(efi_early->free_pool, info);
> +   goto grow;
> +   }
> +
> +   *file_sz = info->file_size;
> +   efi_early->call(efi_early->free_pool, info);
> +
> +   if (status != EFI_SUCCESS)
> +   efi_printk(sys_table, "Failed to get initrd info\n");
> +
> +   return status;
> +}
> +
> +static inline efi_status_t
> +efi_file_read(void *__fh, void *handle, unsigned long *size, void *addr)
> +{
> +   

Re: [PATCH v2 06/13] x86/efi: Build our own EFI services pointer table

[Roy Franz]

On Tue, Mar 4, 2014 at 5:14 AM, Matt Fleming m...@console-pimps.org wrote:
 From: Matt Fleming matt.flem...@intel.com

 It's not possible to dereference the EFI System table directly when
 booting a 64-bit kernel on a 32-bit EFI firmware because the size of
 pointers don't match.

 In preparation for supporting the above use case, build a list of
 function pointers on boot so that callers don't have to worry about
 converting pointer sizes through multiple levels of indirection.

 Signed-off-by: Matt Fleming matt.flem...@intel.com
 ---
  arch/x86/boot/compressed/eboot.c   | 319 
 -
  arch/x86/boot/compressed/eboot.h   |  16 ++
  arch/x86/boot/compressed/head_32.S |  48 -
  arch/x86/boot/compressed/head_64.S |  57 --
  drivers/firmware/efi/efi-stub-helper.c | 148 ---
  5 files changed, 377 insertions(+), 211 deletions(-)

 diff --git a/arch/x86/boot/compressed/eboot.c 
 b/arch/x86/boot/compressed/eboot.c
 index a7677babf946..42548168bdc3 100644
 --- a/arch/x86/boot/compressed/eboot.c
 +++ b/arch/x86/boot/compressed/eboot.c
 @@ -19,10 +19,145 @@

  static efi_system_table_t *sys_table;

 +static struct efi_config *efi_early;
 +
 +#define BOOT_SERVICES(bits)\
 +static void setup_boot_services##bits(struct efi_config *c)\
 +{  \
 +   efi_system_table_##bits##_t *table; \
 +   efi_boot_services_##bits##_t *bt;   \
 +   \
 +   table = (typeof(table))sys_table;   \
 +   \
 +   c-text_output = table-con_out;\
 +   \
 +   bt = (typeof(bt))(unsigned long)(table-boottime);  \
 +   \
 +   c-allocate_pool = bt-allocate_pool;   \
 +   c-allocate_pages = bt-allocate_pages; \
 +   c-get_memory_map = bt-get_memory_map; \
 +   c-free_pool = bt-free_pool;   \
 +   c-free_pages = bt-free_pages; \
 +   c-locate_handle = bt-locate_handle;   \
 +   c-handle_protocol = bt-handle_protocol;   \
 +   c-exit_boot_services = bt-exit_boot_services; \
 +}
 +BOOT_SERVICES(32);
 +BOOT_SERVICES(64);

 -#include ../../../../drivers/firmware/efi/efi-stub-helper.c
 +static void efi_printk(efi_system_table_t *, char *);
 +static void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
 +
 +static efi_status_t
 +efi_file_size(efi_system_table_t *sys_table, void *__fh,
 + efi_char16_t *filename_16, void **handle, u64 *file_sz)
 +{
 +   efi_file_handle_t *h, *fh = __fh;
 +   efi_file_info_t *info;
 +   efi_status_t status;
 +   efi_guid_t info_guid = EFI_FILE_INFO_ID;
 +   u32 info_sz;
 +
 +   status = efi_early-call((unsigned long)fh-open, fh, h, filename_16,
 +EFI_FILE_MODE_READ, (u64)0);
 +   if (status != EFI_SUCCESS) {
 +   efi_printk(sys_table, Failed to open file: );
 +   efi_char16_printk(sys_table, filename_16);
 +   efi_printk(sys_table, \n);
 +   return status;
 +   }
 +
 +   *handle = h;
 +
 +   info_sz = 0;
 +   status = efi_early-call((unsigned long)h-get_info, h, info_guid,
 +info_sz, NULL);
 +   if (status != EFI_BUFFER_TOO_SMALL) {
 +   efi_printk(sys_table, Failed to get file info size\n);
 +   return status;
 +   }
 +
 +grow:
 +   status = efi_early-call(efi_early-allocate_pool, EFI_LOADER_DATA,
 +info_sz, (void **)info);
 +   if (status != EFI_SUCCESS) {
 +   efi_printk(sys_table, Failed to alloc mem for file info\n);
 +   return status;
 +   }
 +
 +   status = efi_early-call((unsigned long)h-get_info, h, info_guid,
 +info_sz, info);
 +   if (status == EFI_BUFFER_TOO_SMALL) {
 +   efi_early-call(efi_early-free_pool, info);
 +   goto grow;
 +   }
 +
 +   *file_sz = info-file_size;
 +   efi_early-call(efi_early-free_pool, info);
 +
 +   if (status != EFI_SUCCESS)
 +   efi_printk(sys_table, Failed to get initrd info\n);
 +
 +   return status;
 +}
 +
 +static inline efi_status_t
 +efi_file_read(void *__fh, void *handle, unsigned long *size, void *addr)
 +{
 +   efi_file_handle_t *fh = __fh;
 +   return efi_early-call((unsigned 

Re: [PATCH v2 11/15] arm64: add EFI stub

[Roy Franz]

On Tue, Mar 18, 2014 at 2:40 PM, Mark Salter  wrote:
> On Tue, 2014-03-18 at 18:28 +, Catalin Marinas wrote:
>> On Tue, Mar 18, 2014 at 02:40:29PM +, Mark Salter wrote:
>> > On Tue, 2014-03-18 at 12:09 +, Catalin Marinas wrote:
>> > > On Thu, Mar 13, 2014 at 10:47:04PM +, Leif Lindholm wrote:
>> > > > --- /dev/null
>> > > > +++ b/arch/arm64/kernel/efi-entry.S
>> > > > @@ -0,0 +1,93 @@
>> > > > +/*
>> > > > + * EFI entry point.
>> > > > + *
>> > > > + * Copyright (C) 2013 Red Hat, Inc.
>> > > > + * Author: Mark Salter 
>> > > > + *
>> > > > + * This program is free software; you can redistribute it and/or 
>> > > > modify
>> > > > + * it under the terms of the GNU General Public License version 2 as
>> > > > + * published by the Free Software Foundation.
>> > > > + *
>> > > > + */
>> > > > +#include 
>> > > > +#include 
>> > > > +
>> > > > +#include 
>> > > > +
>> > > > +#define EFI_LOAD_ERROR 0x8001
>> > > > +
>> > > > +   __INIT
>> > > > +
>> > > > +   /*
>> > > > +* We arrive here from the EFI boot manager with:
>> > > > +*
>> > > > +** MMU on with identity-mapped RAM.
>> > > > +** Icache and Dcache on
>> > > > +*
>> > > > +* We will most likely be running from some place other than 
>> > > > where
>> > > > +* we want to be. The kernel image wants to be placed at 
>> > > > TEXT_OFFSET
>> > > > +* from start of RAM.
>> > > > +*/
>> > > > +ENTRY(efi_stub_entry)
>> > > > +   stp x29, x30, [sp, #-32]!
>> > > > +
>> > > > +   /*
>> > > > +* Call efi_entry to do the real work.
>> > > > +* x0 and x1 are already set up by firmware. Current runtime
>> > > > +* address of image is calculated and passed via *image_addr.
>> > > > +*
>> > > > +* unsigned long efi_entry(void *handle,
>> > > > +* efi_system_table_t *sys_table,
>> > > > +* unsigned long *image_addr) ;
>> > > > +*/
>> > > > +   adrpx8, _text
>> > > > +   add x8, x8, #:lo12:_text
>> > > > +   add x2, sp, 16
>> > > > +   str x8, [x2]
>> > > > +   bl  efi_entry
>> > > > +   cmn x0, #1
>> > > > +   b.eqefi_load_fail
>> > > > +
>> > > > +   /*
>> > > > +* efi_entry() will have relocated the kernel image if 
>> > > > necessary
>> > > > +* and we return here with device tree address in x0 and the 
>> > > > kernel
>> > > > +* entry point stored at *image_addr. Save those values in 
>> > > > registers
>> > > > +* which are preserved by __flush_dcache_all.
>> > > > +*/
>> > > > +   ldr x1, [sp, #16]
>> > > > +   mov x20, x0
>> > > > +   mov x21, x1
>> > > > +
>> > > > +   /* Turn off Dcache and MMU */
>> > > > +   mrs x0, CurrentEL
>> > > > +   cmp x0, #PSR_MODE_EL2t
>> > > > +   ccmpx0, #PSR_MODE_EL2h, #0x4, ne
>> > > > +   b.ne1f
>> > > > +   mrs x0, sctlr_el2
>> > > > +   bic x0, x0, #1 << 0 // clear SCTLR.M
>> > > > +   bic x0, x0, #1 << 2 // clear SCTLR.C
>> > > > +   msr sctlr_el2, x0
>> > > > +   isb
>> > > > +   b   2f
>> > > > +1:
>> > > > +   mrs x0, sctlr_el1
>> > > > +   bic x0, x0, #1 << 0 // clear SCTLR.M
>> > > > +   bic x0, x0, #1 << 2 // clear SCTLR.C
>> > > > +   msr sctlr_el1, x0
>> > > > +   isb
>> > > > +2:
>> > > > +   bl  __flush_dcache_all
>> > >
>> > > In linux-next I'm pushing a patch which no longer exports the
>> > > __flush_dcache_all function. The reason is that it doesn't really work
>> > > if you have a (not fully transparent) external cache like on the Applied
>> > > Micro boards. There other issues when running as a guest as well.
>> > >
>> > > If you know exactly what needs to be flushed here, can you use a range
>> > > (MVA) operation?
>> >
>> > This is just before the EFI stub jumps to kernel proper. The only things
>> > in the dcache would be from identity mapped references to RAM used by
>> > UEFI. The booting.txt doc says dcache should be off and invalidated. I
>> > am just wanting to comply with that. The code here doesn't really know
>> > the extent of DRAM to flush by address.
>>
>> Does UEFI do anything with the caches before invoking the EFI_STUB code?
>> I guess it doesn't since that's just another application for it. Can
>> UEFI flush the caches via exit boot? When is this called?
>>
>> As I said, we have a real problem here since the EFI_STUB call does not
>> have information about the SoC to be able to flush all the caches. But
>> UEFI should know more about the hardware.
>>
>> If UEFI doesn't handle the caches, the only thing left to EFI_STUB is to
>> flush by MVA. We don't need to flush the whole DRAM (and I would even
>> recommend it) but at least the relevant kernel code/data touched with
>> the MMU disabled.
>>
>
> So, it goes like 

Re: [PATCH v2 11/15] arm64: add EFI stub

[Roy Franz]

On Tue, Mar 18, 2014 at 2:40 PM, Mark Salter msal...@redhat.com wrote:
 On Tue, 2014-03-18 at 18:28 +, Catalin Marinas wrote:
 On Tue, Mar 18, 2014 at 02:40:29PM +, Mark Salter wrote:
  On Tue, 2014-03-18 at 12:09 +, Catalin Marinas wrote:
   On Thu, Mar 13, 2014 at 10:47:04PM +, Leif Lindholm wrote:
--- /dev/null
+++ b/arch/arm64/kernel/efi-entry.S
@@ -0,0 +1,93 @@
+/*
+ * EFI entry point.
+ *
+ * Copyright (C) 2013 Red Hat, Inc.
+ * Author: Mark Salter msal...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or 
modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include linux/linkage.h
+#include linux/init.h
+
+#include asm/assembler.h
+
+#define EFI_LOAD_ERROR 0x8001
+
+   __INIT
+
+   /*
+* We arrive here from the EFI boot manager with:
+*
+** MMU on with identity-mapped RAM.
+** Icache and Dcache on
+*
+* We will most likely be running from some place other than 
where
+* we want to be. The kernel image wants to be placed at 
TEXT_OFFSET
+* from start of RAM.
+*/
+ENTRY(efi_stub_entry)
+   stp x29, x30, [sp, #-32]!
+
+   /*
+* Call efi_entry to do the real work.
+* x0 and x1 are already set up by firmware. Current runtime
+* address of image is calculated and passed via *image_addr.
+*
+* unsigned long efi_entry(void *handle,
+* efi_system_table_t *sys_table,
+* unsigned long *image_addr) ;
+*/
+   adrpx8, _text
+   add x8, x8, #:lo12:_text
+   add x2, sp, 16
+   str x8, [x2]
+   bl  efi_entry
+   cmn x0, #1
+   b.eqefi_load_fail
+
+   /*
+* efi_entry() will have relocated the kernel image if 
necessary
+* and we return here with device tree address in x0 and the 
kernel
+* entry point stored at *image_addr. Save those values in 
registers
+* which are preserved by __flush_dcache_all.
+*/
+   ldr x1, [sp, #16]
+   mov x20, x0
+   mov x21, x1
+
+   /* Turn off Dcache and MMU */
+   mrs x0, CurrentEL
+   cmp x0, #PSR_MODE_EL2t
+   ccmpx0, #PSR_MODE_EL2h, #0x4, ne
+   b.ne1f
+   mrs x0, sctlr_el2
+   bic x0, x0, #1  0 // clear SCTLR.M
+   bic x0, x0, #1  2 // clear SCTLR.C
+   msr sctlr_el2, x0
+   isb
+   b   2f
+1:
+   mrs x0, sctlr_el1
+   bic x0, x0, #1  0 // clear SCTLR.M
+   bic x0, x0, #1  2 // clear SCTLR.C
+   msr sctlr_el1, x0
+   isb
+2:
+   bl  __flush_dcache_all
  
   In linux-next I'm pushing a patch which no longer exports the
   __flush_dcache_all function. The reason is that it doesn't really work
   if you have a (not fully transparent) external cache like on the Applied
   Micro boards. There other issues when running as a guest as well.
  
   If you know exactly what needs to be flushed here, can you use a range
   (MVA) operation?
 
  This is just before the EFI stub jumps to kernel proper. The only things
  in the dcache would be from identity mapped references to RAM used by
  UEFI. The booting.txt doc says dcache should be off and invalidated. I
  am just wanting to comply with that. The code here doesn't really know
  the extent of DRAM to flush by address.

 Does UEFI do anything with the caches before invoking the EFI_STUB code?
 I guess it doesn't since that's just another application for it. Can
 UEFI flush the caches via exit boot? When is this called?

 As I said, we have a real problem here since the EFI_STUB call does not
 have information about the SoC to be able to flush all the caches. But
 UEFI should know more about the hardware.

 If UEFI doesn't handle the caches, the only thing left to EFI_STUB is to
 flush by MVA. We don't need to flush the whole DRAM (and I would even
 recommend it) but at least the relevant kernel code/data touched with
 the MMU disabled.


 So, it goes like this:

   1) UEFI calls stub with MMU/Caches on. Stub/kernel can be anywhere.
   2) Stub runs and relocates kernel to the desired runtime location
  but continues to execute from wherever UEFI loaded it until just
  after ExitBootServices().
   3) After ExitBootServices, efi_entry() returns relocated entry point
  for kernel to efi_stub_entry() in efi-entry.S where the Dcache and
  MMU are turned off, the __flush_dcache_all is called, then 

Re: [PATCH 06/22] Add helper functions used by arm/arm64

[Roy Franz]

On Mon, Mar 3, 2014 at 6:08 AM, Matt Fleming  wrote:
> On Fri, 14 Feb, at 11:02:49AM, Roy Franz wrote:
>>
>> The get_dram_base() function is only used by arm/arm64, but
>> there is nothing architecture specific about it, which is why I put it
>> here to begin with.  I don't feel strongly about this either way.
>
> Sorry Roy, I just realised that you probably wanted a response from me
> about this last point.
>
> OK, leaving get_dram_base() in efi-stub-helper.c is fine.
>
> FYI, "NUL" isn't a typo,
>
>> - options_size++;  /* NUL termination */
> [...]
>> + options_size++;  /* NULL termination */
>
> http://en.wikipedia.org/wiki/Null_character
>
> --
> Matt Fleming, Intel Open Source Technology Center

Thanks - I'll take care of this in the next revision.

Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/22] Add helper functions used by arm/arm64

[Roy Franz]

On Mon, Mar 3, 2014 at 6:08 AM, Matt Fleming m...@console-pimps.org wrote:
 On Fri, 14 Feb, at 11:02:49AM, Roy Franz wrote:

 The get_dram_base() function is only used by arm/arm64, but
 there is nothing architecture specific about it, which is why I put it
 here to begin with.  I don't feel strongly about this either way.

 Sorry Roy, I just realised that you probably wanted a response from me
 about this last point.

 OK, leaving get_dram_base() in efi-stub-helper.c is fine.

 FYI, NUL isn't a typo,

 - options_size++;  /* NUL termination */
 [...]
 + options_size++;  /* NULL termination */

 http://en.wikipedia.org/wiki/Null_character

 --
 Matt Fleming, Intel Open Source Technology Center

Thanks - I'll take care of this in the next revision.

Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/22] Add helper functions used by arm/arm64

[Roy Franz]

On Thu, Feb 13, 2014 at 3:26 AM, Matt Fleming  wrote:
> On Wed, 05 Feb, at 05:03:57PM, Leif Lindholm wrote:
>> From: Roy Franz 
>>
>> Add the get_dram_base() function and efi_call_physN() macros
>> that are shared by arm/arm64.
>>
>> Signed-off-by: Roy Franz 
>> Signed-off-by: Leif Lindholm 
>> ---
>>  drivers/firmware/efi/efi-stub-helper.c |   63 
>> +---
>>  1 file changed, 50 insertions(+), 13 deletions(-)
>
> These changes should be in drivers/firmware/efi/arm-stub.c -
> efi-stub-helper.c is not a dumping ground for random
> architecture-specific code.

Hi Matt,

  I will move those functions/macros to the arm-stub.c file.  I agree
that the macros should go there, as they are the arm specific versions
and conflict with the x86 versions defined elsewhere.  These were
there before the arm-stub.c file was added and didn't get moved when
it was.  The get_dram_base() function is only used by arm/arm64, but
there is nothing architecture specific about it, which is why I put it
here to begin with.  I don't feel strongly about this either way.

Thanks,
Roy


>
> --
> Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/22] Add helper functions used by arm/arm64

[Roy Franz]

On Thu, Feb 13, 2014 at 3:26 AM, Matt Fleming m...@console-pimps.org wrote:
 On Wed, 05 Feb, at 05:03:57PM, Leif Lindholm wrote:
 From: Roy Franz roy.fr...@linaro.org

 Add the get_dram_base() function and efi_call_physN() macros
 that are shared by arm/arm64.

 Signed-off-by: Roy Franz roy.fr...@linaro.org
 Signed-off-by: Leif Lindholm leif.lindh...@linaro.org
 ---
  drivers/firmware/efi/efi-stub-helper.c |   63 
 +---
  1 file changed, 50 insertions(+), 13 deletions(-)

 These changes should be in drivers/firmware/efi/arm-stub.c -
 efi-stub-helper.c is not a dumping ground for random
 architecture-specific code.

Hi Matt,

  I will move those functions/macros to the arm-stub.c file.  I agree
that the macros should go there, as they are the arm specific versions
and conflict with the x86 versions defined elsewhere.  These were
there before the arm-stub.c file was added and didn't get moved when
it was.  The get_dram_base() function is only used by arm/arm64, but
there is nothing architecture specific about it, which is why I put it
here to begin with.  I don't feel strongly about this either way.

Thanks,
Roy



 --
 Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V6 6/8] Add EFI stub for ARM

[Roy Franz]

On Tue, Jan 14, 2014 at 5:47 PM, Roy Franz  wrote:
> On Tue, Jan 14, 2014 at 1:05 AM, Ard Biesheuvel
>  wrote:
>> On 10 January 2014 17:30, Roy Franz  wrote:
>>> This patch adds EFI stub support for the ARM Linux kernel.  The EFI stub
>>> operates similarly to the x86 stub: it is a shim between the EFI firmware
>>> and the normal zImage entry point, and sets up the environment that the
>>> zImage is expecting.  This includes loading the initrd (optionaly) and
>>> device tree from the system partition based on the kernel command line.
>>> The stub updates the device tree as necessary, adding entries for EFI
>>> runtime services. The PE/COFF "MZ" header at offset 0 results in the
>>> first instruction being an add that corrupts r5, which is not used by
>>> the zImage interface.
>>>
>>> Signed-off-by: Roy Franz 
>>> Acked-by: Grant Likely 
>>> ---
>>
>> [...]
>>
>>> diff --git a/arch/arm/boot/compressed/efi-header.S 
>>> b/arch/arm/boot/compressed/efi-header.S
>>> new file mode 100644
>>> index 000..dbb7101
>>> --- /dev/null
>>> +++ b/arch/arm/boot/compressed/efi-header.S
>>> @@ -0,0 +1,117 @@
>>> +@ Copyright (C) 2013 Linaro Ltd;  
>>> +@
>>> +@ This file contains the PE/COFF header that is part of the
>>> +@ EFI stub.
>>> +@
>>> +
>>> +   .org0x3c
>>> +   @
>>> +   @ The PE header can be anywhere in the file, but for
>>> +   @ simplicity we keep it together with the MSDOS header
>>> +   @ The offset to the PE/COFF header needs to be at offset
>>> +   @ 0x3C in the MSDOS header.
>>> +   @ The only 2 fields of the MSDOS header that are used are this
>>> +   @ PE/COFF offset, and the "MZ" bytes at offset 0x0.
>>> +   @
>>> +   .long   pe_header   @ Offset to the PE header.
>>> +
>>> +  .align 3
>>> +pe_header:
>>> +   .ascii  "PE"
>>> +   .short  0
>>> +
>>> +coff_header:
>>> +   .short  0x01c2  @ ARM or Thumb
>>
>> Could you explain why you are using 0x1c2 (Thumb) here and not 0x1c0 (ARM) ?
>>
>> Cheers,
>> Ard.
>
> Nope.  It should be 0x1c0.
>
> Roy

OK, now I resolved the nagging feeling that I had already fixed
this...   Right now, the EDK2 UEFI implementation
requires the machine type for ARM to be "0x1c2".  I don't think that
this is correct, but correcting this in EDK2 slipped through
the cracks, but is now back on my todo list.

I think that for now we should leave this as 0x1c2 so that the
unpatched EDK2 builds will boot it, and some time after EDK2 is
updated
this can be changed.  I'll work on a patch for EDK2 and get the
discussion going on that list to resolve this in EDK2.


Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V6 6/8] Add EFI stub for ARM

[Roy Franz]

On Tue, Jan 14, 2014 at 1:05 AM, Ard Biesheuvel
 wrote:
> On 10 January 2014 17:30, Roy Franz  wrote:
>> This patch adds EFI stub support for the ARM Linux kernel.  The EFI stub
>> operates similarly to the x86 stub: it is a shim between the EFI firmware
>> and the normal zImage entry point, and sets up the environment that the
>> zImage is expecting.  This includes loading the initrd (optionaly) and
>> device tree from the system partition based on the kernel command line.
>> The stub updates the device tree as necessary, adding entries for EFI
>> runtime services. The PE/COFF "MZ" header at offset 0 results in the
>> first instruction being an add that corrupts r5, which is not used by
>> the zImage interface.
>>
>> Signed-off-by: Roy Franz 
>> Acked-by: Grant Likely 
>> ---
>
> [...]
>
>> diff --git a/arch/arm/boot/compressed/efi-header.S 
>> b/arch/arm/boot/compressed/efi-header.S
>> new file mode 100644
>> index 000..dbb7101
>> --- /dev/null
>> +++ b/arch/arm/boot/compressed/efi-header.S
>> @@ -0,0 +1,117 @@
>> +@ Copyright (C) 2013 Linaro Ltd;  
>> +@
>> +@ This file contains the PE/COFF header that is part of the
>> +@ EFI stub.
>> +@
>> +
>> +   .org0x3c
>> +   @
>> +   @ The PE header can be anywhere in the file, but for
>> +   @ simplicity we keep it together with the MSDOS header
>> +   @ The offset to the PE/COFF header needs to be at offset
>> +   @ 0x3C in the MSDOS header.
>> +   @ The only 2 fields of the MSDOS header that are used are this
>> +   @ PE/COFF offset, and the "MZ" bytes at offset 0x0.
>> +   @
>> +   .long   pe_header   @ Offset to the PE header.
>> +
>> +  .align 3
>> +pe_header:
>> +   .ascii  "PE"
>> +   .short  0
>> +
>> +coff_header:
>> +   .short  0x01c2  @ ARM or Thumb
>
> Could you explain why you are using 0x1c2 (Thumb) here and not 0x1c0 (ARM) ?
>
> Cheers,
> Ard.

Nope.  It should be 0x1c0.

Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V6 3/8] Add helper function to get and convert EFI command line

[Roy Franz]

On Mon, Jan 13, 2014 at 7:04 AM, Matt Fleming  wrote:
> On Fri, 10 Jan, at 08:30:12AM, Roy Franz wrote:
>> Add an EFI stub helper function to retrieve the EFI command line using
>> the LOADED_IMAGE_PROTOCOL, and convert it to ASCII.  This function will
>> be shared by the various EFI stub implementations.
>>
>> Signed-off-by: Roy Franz 
>> ---
>>  drivers/firmware/efi/efi-stub-helper.c |   30 ++
>>  1 file changed, 30 insertions(+)
>>
>> diff --git a/drivers/firmware/efi/efi-stub-helper.c 
>> b/drivers/firmware/efi/efi-stub-helper.c
>> index eb5d2eb..f657456 100644
>> --- a/drivers/firmware/efi/efi-stub-helper.c
>> +++ b/drivers/firmware/efi/efi-stub-helper.c
>> @@ -637,3 +637,33 @@ static char 
>> *efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
>>   *cmd_line_len = options_size;
>>   return (char *)cmdline_addr;
>>  }
>> +
>> +/*
>> + * get the command line from EFI, using the LOADED_IMAGE
>> + * protocol, and convert to ASCII.
>> + *
>> + */
>> +static void efi_get_cmdline(efi_system_table_t *sys_table,
>> +   efi_loaded_image_t **image,
>> +   void *handle, char **cmdline_ptr)
>> +{
>
> Wouldn't this prototype make more sense?
>
> static char *efi_get_cmdline(efi_system_table_t *sys_table,
>  efi_loaded_image_t **image,
>  void *handle);
>
> Is this function really worth implementing at all? Certainly on x86, we
> lookup the loaded image protocol for reasons other than parsing the
> command line, and so would need to do it in the caller anyway.
>
> --
> Matt Fleming, Intel Open Source Technology Center

Yeah, this should just go away.  This was the result of some
over-zealous moving code from arm/arm64 to shared code.

Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V6 0/8] Add ARM EFI stub

[Roy Franz]

On Mon, Jan 13, 2014 at 7:07 AM, Matt Fleming  wrote:
> On Fri, 10 Jan, at 08:30:09AM, Roy Franz wrote:
>> This patch series adds EFI stub support for the ARM architecture.  The
>> stub for ARM is implemented in a similar manner to x86 in that it is a
>> shim layer between EFI and the normal zImage/bzImage boot process, and
>> that an image with the stub configured is bootable as both a zImage and
>> EFI application.  This patchset adds common code that is shared with
>> the ARM64 EFI stub.
>>
>> This patch depends on Leif Lindholm's ARM v7 runtime services patchset, which
>> in turn depends on Mark Salter's early_io_remap() patchset.  This EFI stub
>> patchset can be tested without those by simply modifying the Kconfig for
>> EFI_STUB to not depend on EFI.  The kernel will boot using the stub,
>> however no EFI support will be available in the kernel.
>>
>> I have addressed all the feedback I have recieved to date, and I am hoping
>> that this patchset is acceptable for merging into 3.14.  It has been
>> functionally stable for some time, and provides useful functionality.
>> Further consolidation of the ARM/ARM64 stubs planned as part of the
>> ongoing development of the stubs and supporting tools for both
>> architectures (getting the FDT from a UEFI configuration table, using UEFI
>> memory map instead of FDT for memory description.)
>
> Is this going to Linus via one of the ARM maintainer trees?
>
> --
> Matt Fleming, Intel Open Source Technology Center

Hi Matt,

Yes, this is planned to go through one of the ARM trees.  Given
that this relies on the early_io_remap
patchsets that have not been accepted yet, I don't see this being
accepted for 3.14.

Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V6 6/8] Add EFI stub for ARM

[Roy Franz]

On Tue, Jan 14, 2014 at 11:29 AM, Rob Herring  wrote:
> On Fri, Jan 10, 2014 at 10:30 AM, Roy Franz  wrote:
>> This patch adds EFI stub support for the ARM Linux kernel.  The EFI stub
>> operates similarly to the x86 stub: it is a shim between the EFI firmware
>> and the normal zImage entry point, and sets up the environment that the
>> zImage is expecting.  This includes loading the initrd (optionaly) and
>> device tree from the system partition based on the kernel command line.
>> The stub updates the device tree as necessary, adding entries for EFI
>> runtime services. The PE/COFF "MZ" header at offset 0 results in the
>> first instruction being an add that corrupts r5, which is not used by
>> the zImage interface.
>>
>> Signed-off-by: Roy Franz 
>> Acked-by: Grant Likely 
>> ---
>
> [snip]
>
>> +   /* Look up the base of DRAM from the device tree. */
>> +   fdt = (void *)fdt_addr;
>> +   node = fdt_subnode_offset(fdt, 0, "memory");
>> +   region = fdt_getprop(fdt, node, "reg", NULL);
>> +   if (region) {
>> +   dram_base = fdt64_to_cpu(region->base);
>
> This will not work if the address is 32-bit size.
>
>> +   } else {
>> +   /* There is no way to get amount or addresses of physical
>> +* memory installed using EFI calls.  If the device tree
>> +* we read from disk doesn't have this, there is no way
>> +* for us to construct this informaion.
>> +*/
>> +   pr_efi_err(sys_table, "No 'memory' node in device tree.\n");
>> +   goto fail_free_fdt;
>
> The current pc can't be used to determine the DRAM base like AUTO_ZRELADDR?
>
> Rob

Hi Rob,

   UEFI may load the stub based kernel anywhere, so we don't get any
useful information from where we were loaded.
I am currently working on getting the base address from the EFI memory
map, so all of the above code will go away, the only FDT
operations that the stub will perform is to add the EFI related fields.

Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] arm64: add EFI stub

[Roy Franz]

On Tue, Jan 14, 2014 at 6:44 AM, Mark Salter  wrote:
> On Mon, 2014-01-13 at 19:49 +0100, Arnd Bergmann wrote:
>> On Friday 10 January 2014, Mark Salter wrote:
>> > This patch adds PE/COFF header fields to the start of the Image
>> > so that it appears as an EFI application to EFI firmware. An EFI
>> > stub is included to allow direct booting of the kernel Image. Due
>> > to EFI firmware limitations, only little endian kernels with 4K
>> > page sizes are supported at this time. Support in the COFF header
>> > for signed images was provided by Ard Biesheuvel.
>> >
>> > Signed-off-by: Mark Salter 
>> > Signed-off-by: Ard Biesheuvel 
>>
>> You got the ordering of the S-o-b lines wrong. Since you send the
>> patch, your name should come last.
>
> Yes.
>
>>
>> > +config EFI_STUB
>> > + bool "EFI stub support"
>> > + depends on !ARM64_64K_PAGES && OF
>> > + select LIBFDT
>> > + default y
>> > + help
>> > +   This kernel feature allows an Image to be loaded directly
>> > +   by EFI firmware without the use of a bootloader.
>> > +   See Documentation/efi-stub.txt for more information.
>> > +
>> >  endmenu
>>
>> Why not ARM64_64K_PAGES? I thought that it was going to be the
>> default for a lot of distros that would need to run on UEFI systems.
>
> The UEFI spec currently mandates 4k page size. We may be able to work
> around that or get the spec changed, but for now it is just 4k pages.
>
>>
>> >  menu "Userspace binary formats"
>> > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> > index 5ba2fd4..1c52b84 100644
>> > --- a/arch/arm64/kernel/Makefile
>> > +++ b/arch/arm64/kernel/Makefile
>> > @@ -4,6 +4,8 @@
>> >
>> >  CPPFLAGS_vmlinux.lds := -DTEXT_OFFSET=$(TEXT_OFFSET)
>> >  AFLAGS_head.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
>> > +CFLAGS_efi-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) \
>> > +-I$(src)/../../../scripts/dtc/libfdt
>>
>> Hmm, this is pretty ugly. I notice the same has been done on MIPS
>> as well, but I'd hope we can find a proper way to do it.
>
> Yes, I just copied that from mips. I can look into some more.
>
>>
>> > diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
>> > new file mode 100644
>> > index 000..10d02bf
>> > --- /dev/null
>> > +++ b/arch/arm64/kernel/efi-stub.c
>> > +
>> > +/* Include shared EFI stub code */
>> > +#include "../../../drivers/firmware/efi/efi-stub-helper.c"
>> > +#include "../../../drivers/firmware/efi/fdt.c"
>>
>> It gets worse here.
>
> Well, I'm open to suggestions here. The shared code has to work with
> stubs which are built into kernel (arm64) and which are part of the
> compressed image wrapper.
>

The decompression algorithms are shared among the compressed image
wrappers using #include of C code, so this is
following that convention.  The only other mechanism that I saw for
sharing code with the compressed image wrappers was
copying of files, as is done with the FDT files for the ARM compressed
wrapper.  I agree that neither of these is elegant, but
whatever we do needs to work for compiling into the decompression
wrapper (arm) and the kernel proper (arm64).

Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] arm64: add EFI stub

[Roy Franz]

On Tue, Jan 14, 2014 at 6:44 AM, Mark Salter msal...@redhat.com wrote:
 On Mon, 2014-01-13 at 19:49 +0100, Arnd Bergmann wrote:
 On Friday 10 January 2014, Mark Salter wrote:
  This patch adds PE/COFF header fields to the start of the Image
  so that it appears as an EFI application to EFI firmware. An EFI
  stub is included to allow direct booting of the kernel Image. Due
  to EFI firmware limitations, only little endian kernels with 4K
  page sizes are supported at this time. Support in the COFF header
  for signed images was provided by Ard Biesheuvel.
 
  Signed-off-by: Mark Salter msal...@redhat.com
  Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org

 You got the ordering of the S-o-b lines wrong. Since you send the
 patch, your name should come last.

 Yes.


  +config EFI_STUB
  + bool EFI stub support
  + depends on !ARM64_64K_PAGES  OF
  + select LIBFDT
  + default y
  + help
  +   This kernel feature allows an Image to be loaded directly
  +   by EFI firmware without the use of a bootloader.
  +   See Documentation/efi-stub.txt for more information.
  +
   endmenu

 Why not ARM64_64K_PAGES? I thought that it was going to be the
 default for a lot of distros that would need to run on UEFI systems.

 The UEFI spec currently mandates 4k page size. We may be able to work
 around that or get the spec changed, but for now it is just 4k pages.


   menu Userspace binary formats
  diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
  index 5ba2fd4..1c52b84 100644
  --- a/arch/arm64/kernel/Makefile
  +++ b/arch/arm64/kernel/Makefile
  @@ -4,6 +4,8 @@
 
   CPPFLAGS_vmlinux.lds := -DTEXT_OFFSET=$(TEXT_OFFSET)
   AFLAGS_head.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
  +CFLAGS_efi-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) \
  +-I$(src)/../../../scripts/dtc/libfdt

 Hmm, this is pretty ugly. I notice the same has been done on MIPS
 as well, but I'd hope we can find a proper way to do it.

 Yes, I just copied that from mips. I can look into some more.


  diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
  new file mode 100644
  index 000..10d02bf
  --- /dev/null
  +++ b/arch/arm64/kernel/efi-stub.c
  +
  +/* Include shared EFI stub code */
  +#include ../../../drivers/firmware/efi/efi-stub-helper.c
  +#include ../../../drivers/firmware/efi/fdt.c

 It gets worse here.

 Well, I'm open to suggestions here. The shared code has to work with
 stubs which are built into kernel (arm64) and which are part of the
 compressed image wrapper.


The decompression algorithms are shared among the compressed image
wrappers using #include of C code, so this is
following that convention.  The only other mechanism that I saw for
sharing code with the compressed image wrappers was
copying of files, as is done with the FDT files for the ARM compressed
wrapper.  I agree that neither of these is elegant, but
whatever we do needs to work for compiling into the decompression
wrapper (arm) and the kernel proper (arm64).

Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V6 6/8] Add EFI stub for ARM

[Roy Franz]

On Tue, Jan 14, 2014 at 11:29 AM, Rob Herring robherri...@gmail.com wrote:
 On Fri, Jan 10, 2014 at 10:30 AM, Roy Franz roy.fr...@linaro.org wrote:
 This patch adds EFI stub support for the ARM Linux kernel.  The EFI stub
 operates similarly to the x86 stub: it is a shim between the EFI firmware
 and the normal zImage entry point, and sets up the environment that the
 zImage is expecting.  This includes loading the initrd (optionaly) and
 device tree from the system partition based on the kernel command line.
 The stub updates the device tree as necessary, adding entries for EFI
 runtime services. The PE/COFF MZ header at offset 0 results in the
 first instruction being an add that corrupts r5, which is not used by
 the zImage interface.

 Signed-off-by: Roy Franz roy.fr...@linaro.org
 Acked-by: Grant Likely grant.lik...@linaro.org
 ---

 [snip]

 +   /* Look up the base of DRAM from the device tree. */
 +   fdt = (void *)fdt_addr;
 +   node = fdt_subnode_offset(fdt, 0, memory);
 +   region = fdt_getprop(fdt, node, reg, NULL);
 +   if (region) {
 +   dram_base = fdt64_to_cpu(region-base);

 This will not work if the address is 32-bit size.

 +   } else {
 +   /* There is no way to get amount or addresses of physical
 +* memory installed using EFI calls.  If the device tree
 +* we read from disk doesn't have this, there is no way
 +* for us to construct this informaion.
 +*/
 +   pr_efi_err(sys_table, No 'memory' node in device tree.\n);
 +   goto fail_free_fdt;

 The current pc can't be used to determine the DRAM base like AUTO_ZRELADDR?

 Rob

Hi Rob,

   UEFI may load the stub based kernel anywhere, so we don't get any
useful information from where we were loaded.
I am currently working on getting the base address from the EFI memory
map, so all of the above code will go away, the only FDT
operations that the stub will perform is to add the EFI related fields.

Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V6 0/8] Add ARM EFI stub

[Roy Franz]

On Mon, Jan 13, 2014 at 7:07 AM, Matt Fleming m...@console-pimps.org wrote:
 On Fri, 10 Jan, at 08:30:09AM, Roy Franz wrote:
 This patch series adds EFI stub support for the ARM architecture.  The
 stub for ARM is implemented in a similar manner to x86 in that it is a
 shim layer between EFI and the normal zImage/bzImage boot process, and
 that an image with the stub configured is bootable as both a zImage and
 EFI application.  This patchset adds common code that is shared with
 the ARM64 EFI stub.

 This patch depends on Leif Lindholm's ARM v7 runtime services patchset, which
 in turn depends on Mark Salter's early_io_remap() patchset.  This EFI stub
 patchset can be tested without those by simply modifying the Kconfig for
 EFI_STUB to not depend on EFI.  The kernel will boot using the stub,
 however no EFI support will be available in the kernel.

 I have addressed all the feedback I have recieved to date, and I am hoping
 that this patchset is acceptable for merging into 3.14.  It has been
 functionally stable for some time, and provides useful functionality.
 Further consolidation of the ARM/ARM64 stubs planned as part of the
 ongoing development of the stubs and supporting tools for both
 architectures (getting the FDT from a UEFI configuration table, using UEFI
 memory map instead of FDT for memory description.)

 Is this going to Linus via one of the ARM maintainer trees?

 --
 Matt Fleming, Intel Open Source Technology Center

Hi Matt,

Yes, this is planned to go through one of the ARM trees.  Given
that this relies on the early_io_remap
patchsets that have not been accepted yet, I don't see this being
accepted for 3.14.

Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V6 3/8] Add helper function to get and convert EFI command line

[Roy Franz]

On Mon, Jan 13, 2014 at 7:04 AM, Matt Fleming m...@console-pimps.org wrote:
 On Fri, 10 Jan, at 08:30:12AM, Roy Franz wrote:
 Add an EFI stub helper function to retrieve the EFI command line using
 the LOADED_IMAGE_PROTOCOL, and convert it to ASCII.  This function will
 be shared by the various EFI stub implementations.

 Signed-off-by: Roy Franz roy.fr...@linaro.org
 ---
  drivers/firmware/efi/efi-stub-helper.c |   30 ++
  1 file changed, 30 insertions(+)

 diff --git a/drivers/firmware/efi/efi-stub-helper.c 
 b/drivers/firmware/efi/efi-stub-helper.c
 index eb5d2eb..f657456 100644
 --- a/drivers/firmware/efi/efi-stub-helper.c
 +++ b/drivers/firmware/efi/efi-stub-helper.c
 @@ -637,3 +637,33 @@ static char 
 *efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
   *cmd_line_len = options_size;
   return (char *)cmdline_addr;
  }
 +
 +/*
 + * get the command line from EFI, using the LOADED_IMAGE
 + * protocol, and convert to ASCII.
 + *
 + */
 +static void efi_get_cmdline(efi_system_table_t *sys_table,
 +   efi_loaded_image_t **image,
 +   void *handle, char **cmdline_ptr)
 +{

 Wouldn't this prototype make more sense?

 static char *efi_get_cmdline(efi_system_table_t *sys_table,
  efi_loaded_image_t **image,
  void *handle);

 Is this function really worth implementing at all? Certainly on x86, we
 lookup the loaded image protocol for reasons other than parsing the
 command line, and so would need to do it in the caller anyway.

 --
 Matt Fleming, Intel Open Source Technology Center

Yeah, this should just go away.  This was the result of some
over-zealous moving code from arm/arm64 to shared code.

Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V6 6/8] Add EFI stub for ARM

[Roy Franz]

On Tue, Jan 14, 2014 at 1:05 AM, Ard Biesheuvel
ard.biesheu...@linaro.org wrote:
 On 10 January 2014 17:30, Roy Franz roy.fr...@linaro.org wrote:
 This patch adds EFI stub support for the ARM Linux kernel.  The EFI stub
 operates similarly to the x86 stub: it is a shim between the EFI firmware
 and the normal zImage entry point, and sets up the environment that the
 zImage is expecting.  This includes loading the initrd (optionaly) and
 device tree from the system partition based on the kernel command line.
 The stub updates the device tree as necessary, adding entries for EFI
 runtime services. The PE/COFF MZ header at offset 0 results in the
 first instruction being an add that corrupts r5, which is not used by
 the zImage interface.

 Signed-off-by: Roy Franz roy.fr...@linaro.org
 Acked-by: Grant Likely grant.lik...@linaro.org
 ---

 [...]

 diff --git a/arch/arm/boot/compressed/efi-header.S 
 b/arch/arm/boot/compressed/efi-header.S
 new file mode 100644
 index 000..dbb7101
 --- /dev/null
 +++ b/arch/arm/boot/compressed/efi-header.S
 @@ -0,0 +1,117 @@
 +@ Copyright (C) 2013 Linaro Ltd;  roy.fr...@linaro.org
 +@
 +@ This file contains the PE/COFF header that is part of the
 +@ EFI stub.
 +@
 +
 +   .org0x3c
 +   @
 +   @ The PE header can be anywhere in the file, but for
 +   @ simplicity we keep it together with the MSDOS header
 +   @ The offset to the PE/COFF header needs to be at offset
 +   @ 0x3C in the MSDOS header.
 +   @ The only 2 fields of the MSDOS header that are used are this
 +   @ PE/COFF offset, and the MZ bytes at offset 0x0.
 +   @
 +   .long   pe_header   @ Offset to the PE header.
 +
 +  .align 3
 +pe_header:
 +   .ascii  PE
 +   .short  0
 +
 +coff_header:
 +   .short  0x01c2  @ ARM or Thumb

 Could you explain why you are using 0x1c2 (Thumb) here and not 0x1c0 (ARM) ?

 Cheers,
 Ard.

Nope.  It should be 0x1c0.

Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V6 6/8] Add EFI stub for ARM

[Roy Franz]

On Tue, Jan 14, 2014 at 5:47 PM, Roy Franz roy.fr...@linaro.org wrote:
 On Tue, Jan 14, 2014 at 1:05 AM, Ard Biesheuvel
 ard.biesheu...@linaro.org wrote:
 On 10 January 2014 17:30, Roy Franz roy.fr...@linaro.org wrote:
 This patch adds EFI stub support for the ARM Linux kernel.  The EFI stub
 operates similarly to the x86 stub: it is a shim between the EFI firmware
 and the normal zImage entry point, and sets up the environment that the
 zImage is expecting.  This includes loading the initrd (optionaly) and
 device tree from the system partition based on the kernel command line.
 The stub updates the device tree as necessary, adding entries for EFI
 runtime services. The PE/COFF MZ header at offset 0 results in the
 first instruction being an add that corrupts r5, which is not used by
 the zImage interface.

 Signed-off-by: Roy Franz roy.fr...@linaro.org
 Acked-by: Grant Likely grant.lik...@linaro.org
 ---

 [...]

 diff --git a/arch/arm/boot/compressed/efi-header.S 
 b/arch/arm/boot/compressed/efi-header.S
 new file mode 100644
 index 000..dbb7101
 --- /dev/null
 +++ b/arch/arm/boot/compressed/efi-header.S
 @@ -0,0 +1,117 @@
 +@ Copyright (C) 2013 Linaro Ltd;  roy.fr...@linaro.org
 +@
 +@ This file contains the PE/COFF header that is part of the
 +@ EFI stub.
 +@
 +
 +   .org0x3c
 +   @
 +   @ The PE header can be anywhere in the file, but for
 +   @ simplicity we keep it together with the MSDOS header
 +   @ The offset to the PE/COFF header needs to be at offset
 +   @ 0x3C in the MSDOS header.
 +   @ The only 2 fields of the MSDOS header that are used are this
 +   @ PE/COFF offset, and the MZ bytes at offset 0x0.
 +   @
 +   .long   pe_header   @ Offset to the PE header.
 +
 +  .align 3
 +pe_header:
 +   .ascii  PE
 +   .short  0
 +
 +coff_header:
 +   .short  0x01c2  @ ARM or Thumb

 Could you explain why you are using 0x1c2 (Thumb) here and not 0x1c0 (ARM) ?

 Cheers,
 Ard.

 Nope.  It should be 0x1c0.

 Roy

OK, now I resolved the nagging feeling that I had already fixed
this...   Right now, the EDK2 UEFI implementation
requires the machine type for ARM to be 0x1c2.  I don't think that
this is correct, but correcting this in EDK2 slipped through
the cracks, but is now back on my todo list.

I think that for now we should leave this as 0x1c2 so that the
unpatched EDK2 builds will boot it, and some time after EDK2 is
updated
this can be changed.  I'll work on a patch for EDK2 and get the
discussion going on that list to resolve this in EDK2.


Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 3/8] Add helper function to get and convert EFI command line

[Roy Franz]

Add an EFI stub helper function to retrieve the EFI command line using
the LOADED_IMAGE_PROTOCOL, and convert it to ASCII.  This function will
be shared by the various EFI stub implementations.

Signed-off-by: Roy Franz 
---
 drivers/firmware/efi/efi-stub-helper.c |   30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index eb5d2eb..f657456 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -637,3 +637,33 @@ static char 
*efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
*cmd_line_len = options_size;
return (char *)cmdline_addr;
 }
+
+/*
+ * get the command line from EFI, using the LOADED_IMAGE
+ * protocol, and convert to ASCII.
+ *
+ */
+static void efi_get_cmdline(efi_system_table_t *sys_table,
+ efi_loaded_image_t **image,
+ void *handle, char **cmdline_ptr)
+{
+   efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
+   efi_status_t status;
+   int cmdline_size;
+
+   status = efi_call_phys3(sys_table->boottime->handle_protocol,
+   handle, , (void *)image);
+   if (status != EFI_SUCCESS) {
+   pr_efi_err(sys_table, "Failed to get handle for 
LOADED_IMAGE_PROTOCOL\n");
+   *cmdline_ptr = NULL;
+   return;
+   }
+
+   /*
+* We are going to copy this into device tree, so we don't care where
+* in memory it is.
+*/
+   *cmdline_ptr = efi_convert_cmdline_to_ascii(sys_table, *image,
+   _size);
+
+}
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 4/8] Add shared FDT related functions for ARM/ARM64

[Roy Franz]

Both ARM and ARM64 stubs will update the device tree that they pass to
the kernel.  In both cases they primarily need to add the same UEFI
related information, so the function can be shared.  Create a new FDT
related file for this to avoid use of architecture #ifdefs in
efi-stub-helper.c.

Signed-off-by: Roy Franz 
Acked-by: Grant Likely 
---
 drivers/firmware/efi/fdt.c |  225 
 1 file changed, 225 insertions(+)
 create mode 100644 drivers/firmware/efi/fdt.c

diff --git a/drivers/firmware/efi/fdt.c b/drivers/firmware/efi/fdt.c
new file mode 100644
index 000..e38f330
--- /dev/null
+++ b/drivers/firmware/efi/fdt.c
@@ -0,0 +1,225 @@
+/*
+ * FDT related Helper functions used by the EFI stub on multiple
+ * architectures. This should be #included by the EFI stub
+ * implementation files.
+ *
+ * Copyright 2013 Linaro Limited; author Roy Franz
+ *
+ * This file is part of the Linux kernel, and is made available
+ * under the terms of the GNU General Public License version 2.
+ *
+ */
+
+struct fdt_region {
+   u64 base;
+   u64 size;
+};
+
+static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
+  void *fdt, int new_fdt_size, char *cmdline_ptr,
+  u64 initrd_addr, u64 initrd_size,
+  efi_memory_desc_t *memory_map,
+  unsigned long map_size, unsigned long desc_size,
+  u32 desc_ver)
+{
+   int node;
+   int status;
+   u32 fdt_val32;
+   u64 fdt_val64;
+
+   /*
+* Copy definition of linux_banner here.  Since this code is
+* built as part of the decompressor for ARM v7, pulling
+* in version.c where linux_banner is defined for the
+* kernel brings other kernel dependencies with it.
+*/
+   const char linux_banner[] =
+   "Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
+   LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
+
+   status = fdt_open_into(orig_fdt, fdt, new_fdt_size);
+   if (status != 0)
+   goto fdt_set_fail;
+
+   node = fdt_subnode_offset(fdt, 0, "chosen");
+   if (node < 0) {
+   node = fdt_add_subnode(fdt, 0, "chosen");
+   if (node < 0) {
+   status = node; /* node is error code when negative */
+   goto fdt_set_fail;
+   }
+   }
+
+   if ((cmdline_ptr != NULL) && (strlen(cmdline_ptr) > 0)) {
+   status = fdt_setprop(fdt, node, "bootargs", cmdline_ptr,
+strlen(cmdline_ptr) + 1);
+   if (status)
+   goto fdt_set_fail;
+   }
+
+   /* Set initrd address/end in device tree, if present */
+   if (initrd_size != 0) {
+   u64 initrd_image_end;
+   u64 initrd_image_start = cpu_to_fdt64(initrd_addr);
+   status = fdt_setprop(fdt, node, "linux,initrd-start",
+_image_start, sizeof(u64));
+   if (status)
+   goto fdt_set_fail;
+   initrd_image_end = cpu_to_fdt64(initrd_addr + initrd_size);
+   status = fdt_setprop(fdt, node, "linux,initrd-end",
+_image_end, sizeof(u64));
+   if (status)
+   goto fdt_set_fail;
+   }
+
+   /* Add FDT entries for EFI runtime services in chosen node. */
+   node = fdt_subnode_offset(fdt, 0, "chosen");
+   fdt_val64 = cpu_to_fdt64((u64)(unsigned long)sys_table);
+   status = fdt_setprop(fdt, node, "linux,uefi-system-table",
+_val64, sizeof(fdt_val64));
+   if (status)
+   goto fdt_set_fail;
+
+   fdt_val64 = cpu_to_fdt64((u64)(unsigned long)memory_map);
+   status = fdt_setprop(fdt, node, "linux,uefi-mmap-start",
+_val64,  sizeof(fdt_val64));
+   if (status)
+   goto fdt_set_fail;
+
+   fdt_val32 = cpu_to_fdt32(map_size);
+   status = fdt_setprop(fdt, node, "linux,uefi-mmap-size",
+_val32,  sizeof(fdt_val32));
+   if (status)
+   goto fdt_set_fail;
+
+   fdt_val32 = cpu_to_fdt32(desc_size);
+   status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-size",
+_val32, sizeof(fdt_val32));
+   if (status)
+   goto fdt_set_fail;
+
+   fdt_val32 = cpu_to_fdt32(desc_ver);
+   status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-ver",
+_val32, sizeof(fdt_val32));
+   if (status)
+   goto fdt_set_fa

[PATCH V6 1/8] efi-stub.txt updates for ARM

[Roy Franz]

Update efi-stub.txt documentation to be more general
and not x86 specific.  Add ARM only "dtb=" command
line option description.

Signed-off-by: Roy Franz 
Acked-by: Grant Likely 
---
 Documentation/efi-stub.txt |   27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index 44e6bb6..a55a0cd 100644
--- a/Documentation/efi-stub.txt
+++ b/Documentation/efi-stub.txt
@@ -1,13 +1,16 @@
  The EFI Boot Stub
 ---
 
-On the x86 platform, a bzImage can masquerade as a PE/COFF image,
-thereby convincing EFI firmware loaders to load it as an EFI
-executable. The code that modifies the bzImage header, along with the
-EFI-specific entry point that the firmware loader jumps to are
-collectively known as the "EFI boot stub", and live in
+On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
+as a PE/COFF image, thereby convincing EFI firmware loaders to load
+it as an EFI executable. The code that modifies the bzImage header,
+along with the EFI-specific entry point that the firmware loader
+jumps to are collectively known as the "EFI boot stub", and live in
 arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
-respectively.
+respectively. For ARM the EFI stub is implemented in
+arch/arm/boot/compressed/efi-header.S and
+arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared
+between architectures is in drivers/firmware/efi/efi-stub-helper.c.
 
 By using the EFI boot stub it's possible to boot a Linux kernel
 without the use of a conventional EFI boot loader, such as grub or
@@ -23,7 +26,9 @@ The bzImage located in arch/x86/boot/bzImage must be copied 
to the EFI
 System Partiion (ESP) and renamed with the extension ".efi". Without
 the extension the EFI firmware loader will refuse to execute it. It's
 not possible to execute bzImage.efi from the usual Linux file systems
-because EFI firmware doesn't have support for them.
+because EFI firmware doesn't have support for them. For ARM the
+arch/arm/boot/zImage should be copied to the system partition, and it
+may not need to be renamed.
 
 
  Passing kernel parameters from the EFI shell
@@ -63,3 +68,11 @@ Notice how bzImage.efi can be specified with a relative 
path. That's
 because the image we're executing is interpreted by the EFI shell,
 which understands relative paths, whereas the rest of the command line
 is passed to bzImage.efi.
+
+
+ The "dtb=" option
+
+For the ARM architecture, we also need to be able to provide a device
+tree to the kernel. This is done with the "dtb=" command line option,
+and is processed in the same manner as the "initrd=" option that is
+described above.
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 7/8] Disable stack protection for decompressor/stub

[Roy Franz]

The ARM decompressor/EFI stub do not implement the functions
(__stack_chk_guard_setup, etc) that are required for support of
stack protection.  The actual enablement of stack protection is
controlled by heuristics in GCC, which the code added for the EFI
stub triggers when CONFIG_STACKPROTECTOR is set.  Even with
CONFIG_STACKPROTECTOR set, the decompressor was never compiled
with stack protection actually enabled. Adding -fno-stack-protector
to the decompressor/stub build keeps it building without stack
protection as it has always been built.
The x86 decompressor/stub is also built with -fno-stack-protector.

Signed-off-by: Roy Franz 
---
 arch/arm/boot/compressed/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile 
b/arch/arm/boot/compressed/Makefile
index c0c7fee..7974791 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -132,7 +132,7 @@ ORIG_CFLAGS := $(KBUILD_CFLAGS)
 KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
 endif
 
-ccflags-y := -fpic -mno-single-pic-base -fno-builtin -I$(obj)
+ccflags-y := -fpic -mno-single-pic-base -fno-builtin -fno-stack-protector 
-I$(obj)
 asflags-y := -DZIMAGE
 
 # Supply kernel BSS size to the decompressor via a linker symbol.
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 6/8] Add EFI stub for ARM

[Roy Franz]

This patch adds EFI stub support for the ARM Linux kernel.  The EFI stub
operates similarly to the x86 stub: it is a shim between the EFI firmware
and the normal zImage entry point, and sets up the environment that the
zImage is expecting.  This includes loading the initrd (optionaly) and
device tree from the system partition based on the kernel command line.
The stub updates the device tree as necessary, adding entries for EFI
runtime services. The PE/COFF "MZ" header at offset 0 results in the
first instruction being an add that corrupts r5, which is not used by
the zImage interface.

Signed-off-by: Roy Franz 
Acked-by: Grant Likely 
---
 arch/arm/boot/compressed/Makefile |   15 ++-
 arch/arm/boot/compressed/efi-header.S |  117 ++
 arch/arm/boot/compressed/efi-stub.c   |  214 +
 arch/arm/boot/compressed/efi-stub.h   |5 +
 arch/arm/boot/compressed/head.S   |   83 -
 5 files changed, 426 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/boot/compressed/efi-header.S
 create mode 100644 arch/arm/boot/compressed/efi-stub.c
 create mode 100644 arch/arm/boot/compressed/efi-stub.h

diff --git a/arch/arm/boot/compressed/Makefile 
b/arch/arm/boot/compressed/Makefile
index e7190bb..c0c7fee 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -99,11 +99,22 @@ libfdt_objs := $(addsuffix .o, $(basename $(libfdt)))
 $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: 
$(srctree)/scripts/dtc/libfdt/%
$(call cmd,shipped)
 
-$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
+$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o efi-stub.o): \
$(addprefix $(obj)/,$(libfdt_hdrs))
 
 ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
-OBJS   += $(libfdt_objs) atags_to_fdt.o
+OBJS   += atags_to_fdt.o
+USE_LIBFDT = y
+endif
+
+ifeq ($(CONFIG_EFI_STUB),y)
+CFLAGS_efi-stub.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
+OBJS   += efi-stub.o
+USE_LIBFDT = y
+endif
+
+ifeq ($(USE_LIBFDT),y)
+OBJS   += $(libfdt_objs)
 endif
 
 targets   := vmlinux vmlinux.lds \
diff --git a/arch/arm/boot/compressed/efi-header.S 
b/arch/arm/boot/compressed/efi-header.S
new file mode 100644
index 000..dbb7101
--- /dev/null
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -0,0 +1,117 @@
+@ Copyright (C) 2013 Linaro Ltd;  
+@
+@ This file contains the PE/COFF header that is part of the
+@ EFI stub.
+@
+
+   .org0x3c
+   @
+   @ The PE header can be anywhere in the file, but for
+   @ simplicity we keep it together with the MSDOS header
+   @ The offset to the PE/COFF header needs to be at offset
+   @ 0x3C in the MSDOS header.
+   @ The only 2 fields of the MSDOS header that are used are this
+   @ PE/COFF offset, and the "MZ" bytes at offset 0x0.
+   @
+   .long   pe_header   @ Offset to the PE header.
+
+  .align 3
+pe_header:
+   .ascii  "PE"
+   .short  0
+
+coff_header:
+   .short  0x01c2  @ ARM or Thumb
+   .short  2   @ nr_sections
+   .long   0   @ TimeDateStamp
+   .long   0   @ PointerToSymbolTable
+   .long   1   @ NumberOfSymbols
+   .short  section_table - optional_header @ SizeOfOptionalHeader
+   .short  0x306   @ Characteristics.
+   @ IMAGE_FILE_32BIT_MACHINE |
+   @ IMAGE_FILE_DEBUG_STRIPPED |
+   @ IMAGE_FILE_EXECUTABLE_IMAGE |
+   @ IMAGE_FILE_LINE_NUMS_STRIPPED
+
+optional_header:
+   .short  0x10b   @ PE32 format
+   .byte   0x02@ MajorLinkerVersion
+   .byte   0x14@ MinorLinkerVersion
+
+   .long   _edata - efi_stub_entry @ SizeOfCode
+
+   .long   0   @ SizeOfInitializedData
+   .long   0   @ SizeOfUninitializedData
+
+   .long   efi_stub_entry  @ AddressOfEntryPoint
+   .long   efi_stub_entry  @ BaseOfCode
+   .long   0   @ data
+
+extra_header_fields:
+   .long   0   @ ImageBase
+   .long   0x20@ SectionAlignment
+   .long   0x8 @ FileAlignment
+   .short  0   @ MajorOperatingSystemVersion
+   .short  0   @ MinorOperatingSystemVersion
+   .short  0   @ MajorImageVersion
+   .short  0   @ MinorImageVersion
+   .short  0   @ MajorSubs

[PATCH V6 8/8] Add config EFI_STUB for ARM to Kconfig

[Roy Franz]

The previous patches have added the implementation of the EFI stub
functionality to the kernel, so now the Kconfig support is added
to enable it.

Signed-off-by: Roy Franz 
---
 arch/arm/Kconfig |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1ab24cc..b650a38 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1867,6 +1867,17 @@ config EFI
  However, even with this option, the resultant kernel will
  continue to boot on non-UEFI platforms.
 
+config EFI_STUB
+   bool "EFI stub support"
+   depends on EFI && !CPU_BIG_ENDIAN
+   ---help---
+ This kernel feature allows a zImage to be loaded directly by EFI
+ firmware without the use of a bootloader.  A PE/COFF header is
+ added to the zImage in a way that makes the binary both a Linux
+ zImage and an PE/COFF executable that can be executed directly by
+ EFI firmware.
+ See Documentation/efi-stub.txt for more information.
+
 config SECCOMP
bool
prompt "Enable seccomp to safely compute untrusted bytecode"
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 0/8] Add ARM EFI stub

[Roy Franz]

This patch series adds EFI stub support for the ARM architecture.  The 
stub for ARM is implemented in a similar manner to x86 in that it is a 
shim layer between EFI and the normal zImage/bzImage boot process, and 
that an image with the stub configured is bootable as both a zImage and 
EFI application.  This patchset adds common code that is shared with
the ARM64 EFI stub.

This patch depends on Leif Lindholm's ARM v7 runtime services patchset, which 
in turn depends on Mark Salter's early_io_remap() patchset.  This EFI stub 
patchset can be tested without those by simply modifying the Kconfig for 
EFI_STUB to not depend on EFI.  The kernel will boot using the stub, 
however no EFI support will be available in the kernel.

I have addressed all the feedback I have recieved to date, and I am hoping 
that this patchset is acceptable for merging into 3.14.  It has been 
functionally stable for some time, and provides useful functionality.  
Further consolidation of the ARM/ARM64 stubs planned as part of the 
ongoing development of the stubs and supporting tools for both 
architectures (getting the FDT from a UEFI configuration table, using UEFI 
memory map instead of FDT for memory description.) 



Changes since v5:
* Move more code dealing with the Device tree to common code shared by
  ARM and ARM64.
* move formatting of informative and error messaging to common code to
  harmonize formatting between ARM/ARM64 stubs.

Changes since v4:
* Common and x86 EFI stub changes that this patch depends on were merged
  in 3.13.
* Updated FDT bindings to match agreed upon bindings in Leif's runtime
  services patchset.  This includes adding the kernel_banner version string,
  and changing how the EFI memory map is passed.  The EFI memory map is now
  allocated as EFI_RUNTIME_SERVICES_DATA since it may be passed to the kernel.
  The FDT bindings for arm/arm64 are identical.
* Added space in PE/COFF header for signature to allow signing of the image
  for EFI secure boot.
* Moved shared FDT function to drivers/firmware/efi/fdt.c.  This will be shared
  with arm64.  (Mark Salter has a patchset for the arm64 stub.)


Changes since v3:
* Common and x86 EFI stub changes have been broken out and submitted separately.
  This patch series depends on the "[PATCH V5 00/18] ARM EFI stub common code"
  series as merged by Matt Fleming. (Patch 10 of that series omitted)
* Re-added -fno-stack-protector.  Needed for compilation with 
  CONFIG_CC_STACKPROTECTOR option.  Cannot easily add support for stack 
  protection since there are no functions in stub that never return, which 
  is a requirement for use.  (x86 stub also disables stack protector.)
  Note that even in the absense of -fno-stack-protector, stack protection
  was never present in the decompressor, as the required functions are not
  implemented.
* Fixed long summaries in commit messages.
* Further cleanups of assembly in head.S


Changes since v2:
* Now depends on "arm: Add [U]EFI runtime services support" patches by 
leif.lindh...@linaro.org.
  The EFI memory map is the only memory map passed to the kernel, so EFI support
  is now required.
* remove "-fno-stack-protector" from decompressor Makefile.  The current code 
doesn't
  trigger the stack protection, so the decompressor now compiles with it still
  on.  Note that there has never been any stack protection in the decompressor
  since the stack usage doesn't trigger the heuristic in GCC, so right now
  the "-fno-stack-protector" is a noop.
* Changed EFI command line handling to not have a fixed limit.
* Change FDT memory allocation to retry with a larger allocation if
  first educated guess is inadequate.
* Correctly set 'SizeOfCode' in PE/COFF header.
* Reviewed ".setup" section that is in x86 PE/COFF header.  This is used for x86
  to account for code that is not in the .text section.  We don't need this
  for ARM, as all of our code is in the .text section, or in the PE/COFF header
  itself.
* Moved EFI_STUB_ERROR #define to header file to share between stub C and ASM.
* Variety of cleanups and fixes in head.S.
* Changed update_fdt_and_exit_boot() to just update the device tree, and
  renamed appropriately.  Memory allocations moved out of this function as
  well, which enables the retries if the initial FDT size is too small.
  Note that in order to do the retried allocations, the original FDT and 
  command line memory regions are left allocated.  This is OK since the kernel
  has the memory map and will free these allocations along with the initrd
  and new fdt allocations.
* Added prefix to all prints, reduced number of prints, and reviewed all
  messages.
* Change mixed usage of dtb/fdt to all be fdt or "device tree" in efi-stub.c
* remove unnecessary zimage_size variable from relocate_kernel()
* correct return types on EFI functions - should be efi_status_t, not int.
Roy Franz (8):
  efi-stub.txt updates for ARM
  Add shared printk w

[PATCH V6 5/8] Add strstr to compressed string.c for ARM.

[Roy Franz]

The shared efi-stub-helper.c functions require a strstr implementation.
The EFI stub is part of the decompressor, so it does not use the kernel
strstr() implementation.  This patch adds a strstr() implementation to
the string.c file for the decompressor, with the implementation copied
from the arch/x86/boot/string.c file used by the x86 decompressor.

Signed-off-by: Roy Franz 
Reviewed-by: Grant Likely 
---
 arch/arm/boot/compressed/string.c |   21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/compressed/string.c 
b/arch/arm/boot/compressed/string.c
index 36e53ef..5397792 100644
--- a/arch/arm/boot/compressed/string.c
+++ b/arch/arm/boot/compressed/string.c
@@ -111,6 +111,27 @@ char *strchr(const char *s, int c)
return (char *)s;
 }
 
+/**
+ * strstr - Find the first substring in a %NUL terminated string
+ * @s1: The string to be searched
+ * @s2: The string to search for
+ */
+char *strstr(const char *s1, const char *s2)
+{
+   size_t l1, l2;
+
+   l2 = strlen(s2);
+   if (!l2)
+   return (char *)s1;
+   l1 = strlen(s1);
+   while (l1 >= l2) {
+   l1--;
+   if (!memcmp(s1, s2, l2))
+   return (char *)s1;
+   s1++;
+   }
+   return NULL;
+}
 #undef memset
 
 void *memset(void *s, int c, size_t count)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 2/8] Add shared printk wrapper for consistent prefixing

[Roy Franz]

Add a wrapper for printk to standardize the prefix for informational and
error messages from the EFI stub.

Signed-off-by: Roy Franz 
---
 drivers/firmware/efi/efi-stub-helper.c |   25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index b6bffbf..eb5d2eb 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -45,6 +45,9 @@ static void efi_printk(efi_system_table_t *sys_table_arg, 
char *str)
}
 }
 
+#define pr_efi(sys_table, msg) efi_printk(sys_table, "EFI stub: "msg)
+#define pr_efi_err(sys_table, msg) efi_printk(sys_table, "EFI stub: ERROR: 
"msg)
+
 
 static efi_status_t efi_get_memory_map(efi_system_table_t *sys_table_arg,
   efi_memory_desc_t **map,
@@ -324,7 +327,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
nr_files * sizeof(*files),
(void **));
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, "Failed to alloc mem for file handle 
list\n");
+   pr_efi_err(sys_table_arg, "Failed to alloc mem for file handle 
list\n");
goto fail;
}
 
@@ -376,13 +379,13 @@ static efi_status_t 
handle_cmdline_files(efi_system_table_t *sys_table_arg,
image->device_handle, _proto,
(void **));
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, "Failed to handle 
fs_proto\n");
+   pr_efi_err(sys_table_arg, "Failed to handle 
fs_proto\n");
goto free_files;
}
 
status = efi_call_phys2(io->open_volume, io, );
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, "Failed to open 
volume\n");
+   pr_efi_err(sys_table_arg, "Failed to open 
volume\n");
goto free_files;
}
}
@@ -390,7 +393,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
status = efi_call_phys5(fh->open, fh, , filename_16,
EFI_FILE_MODE_READ, (u64)0);
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, "Failed to open file: ");
+   pr_efi_err(sys_table_arg, "Failed to open file: ");
efi_char16_printk(sys_table_arg, filename_16);
efi_printk(sys_table_arg, "\n");
goto close_handles;
@@ -402,7 +405,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
status = efi_call_phys4(h->get_info, h, _guid,
_sz, NULL);
if (status != EFI_BUFFER_TOO_SMALL) {
-   efi_printk(sys_table_arg, "Failed to get file info 
size\n");
+   pr_efi_err(sys_table_arg, "Failed to get file info 
size\n");
goto close_handles;
}
 
@@ -411,7 +414,7 @@ grow:
EFI_LOADER_DATA, info_sz,
(void **));
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, "Failed to alloc mem for file 
info\n");
+   pr_efi_err(sys_table_arg, "Failed to alloc mem for file 
info\n");
goto close_handles;
}
 
@@ -427,7 +430,7 @@ grow:
efi_call_phys1(sys_table_arg->boottime->free_pool, info);
 
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, "Failed to get file info\n");
+   pr_efi_err(sys_table_arg, "Failed to get file info\n");
goto close_handles;
}
 
@@ -446,13 +449,13 @@ grow:
status = efi_high_alloc(sys_table_arg, file_size_total, 0x1000,
_addr, max_addr);
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, "Failed to alloc highmem for 
files\n");
+   pr_efi_err(sys_table_arg, "Failed to alloc highmem for 
files\n");
goto close_handles;
}
 
/* We've run out of free low memory. */
if (file_addr > max_addr) {
-  

[PATCH V6 5/8] Add strstr to compressed string.c for ARM.

[Roy Franz]

The shared efi-stub-helper.c functions require a strstr implementation.
The EFI stub is part of the decompressor, so it does not use the kernel
strstr() implementation.  This patch adds a strstr() implementation to
the string.c file for the decompressor, with the implementation copied
from the arch/x86/boot/string.c file used by the x86 decompressor.

Signed-off-by: Roy Franz roy.fr...@linaro.org
Reviewed-by: Grant Likely grant.lik...@linaro.org
---
 arch/arm/boot/compressed/string.c |   21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/compressed/string.c 
b/arch/arm/boot/compressed/string.c
index 36e53ef..5397792 100644
--- a/arch/arm/boot/compressed/string.c
+++ b/arch/arm/boot/compressed/string.c
@@ -111,6 +111,27 @@ char *strchr(const char *s, int c)
return (char *)s;
 }
 
+/**
+ * strstr - Find the first substring in a %NUL terminated string
+ * @s1: The string to be searched
+ * @s2: The string to search for
+ */
+char *strstr(const char *s1, const char *s2)
+{
+   size_t l1, l2;
+
+   l2 = strlen(s2);
+   if (!l2)
+   return (char *)s1;
+   l1 = strlen(s1);
+   while (l1 = l2) {
+   l1--;
+   if (!memcmp(s1, s2, l2))
+   return (char *)s1;
+   s1++;
+   }
+   return NULL;
+}
 #undef memset
 
 void *memset(void *s, int c, size_t count)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 0/8] Add ARM EFI stub

[Roy Franz]

This patch series adds EFI stub support for the ARM architecture.  The 
stub for ARM is implemented in a similar manner to x86 in that it is a 
shim layer between EFI and the normal zImage/bzImage boot process, and 
that an image with the stub configured is bootable as both a zImage and 
EFI application.  This patchset adds common code that is shared with
the ARM64 EFI stub.

This patch depends on Leif Lindholm's ARM v7 runtime services patchset, which 
in turn depends on Mark Salter's early_io_remap() patchset.  This EFI stub 
patchset can be tested without those by simply modifying the Kconfig for 
EFI_STUB to not depend on EFI.  The kernel will boot using the stub, 
however no EFI support will be available in the kernel.

I have addressed all the feedback I have recieved to date, and I am hoping 
that this patchset is acceptable for merging into 3.14.  It has been 
functionally stable for some time, and provides useful functionality.  
Further consolidation of the ARM/ARM64 stubs planned as part of the 
ongoing development of the stubs and supporting tools for both 
architectures (getting the FDT from a UEFI configuration table, using UEFI 
memory map instead of FDT for memory description.) 



Changes since v5:
* Move more code dealing with the Device tree to common code shared by
  ARM and ARM64.
* move formatting of informative and error messaging to common code to
  harmonize formatting between ARM/ARM64 stubs.

Changes since v4:
* Common and x86 EFI stub changes that this patch depends on were merged
  in 3.13.
* Updated FDT bindings to match agreed upon bindings in Leif's runtime
  services patchset.  This includes adding the kernel_banner version string,
  and changing how the EFI memory map is passed.  The EFI memory map is now
  allocated as EFI_RUNTIME_SERVICES_DATA since it may be passed to the kernel.
  The FDT bindings for arm/arm64 are identical.
* Added space in PE/COFF header for signature to allow signing of the image
  for EFI secure boot.
* Moved shared FDT function to drivers/firmware/efi/fdt.c.  This will be shared
  with arm64.  (Mark Salter has a patchset for the arm64 stub.)


Changes since v3:
* Common and x86 EFI stub changes have been broken out and submitted separately.
  This patch series depends on the [PATCH V5 00/18] ARM EFI stub common code
  series as merged by Matt Fleming. (Patch 10 of that series omitted)
* Re-added -fno-stack-protector.  Needed for compilation with 
  CONFIG_CC_STACKPROTECTOR option.  Cannot easily add support for stack 
  protection since there are no functions in stub that never return, which 
  is a requirement for use.  (x86 stub also disables stack protector.)
  Note that even in the absense of -fno-stack-protector, stack protection
  was never present in the decompressor, as the required functions are not
  implemented.
* Fixed long summaries in commit messages.
* Further cleanups of assembly in head.S


Changes since v2:
* Now depends on arm: Add [U]EFI runtime services support patches by 
leif.lindh...@linaro.org.
  The EFI memory map is the only memory map passed to the kernel, so EFI support
  is now required.
* remove -fno-stack-protector from decompressor Makefile.  The current code 
doesn't
  trigger the stack protection, so the decompressor now compiles with it still
  on.  Note that there has never been any stack protection in the decompressor
  since the stack usage doesn't trigger the heuristic in GCC, so right now
  the -fno-stack-protector is a noop.
* Changed EFI command line handling to not have a fixed limit.
* Change FDT memory allocation to retry with a larger allocation if
  first educated guess is inadequate.
* Correctly set 'SizeOfCode' in PE/COFF header.
* Reviewed .setup section that is in x86 PE/COFF header.  This is used for x86
  to account for code that is not in the .text section.  We don't need this
  for ARM, as all of our code is in the .text section, or in the PE/COFF header
  itself.
* Moved EFI_STUB_ERROR #define to header file to share between stub C and ASM.
* Variety of cleanups and fixes in head.S.
* Changed update_fdt_and_exit_boot() to just update the device tree, and
  renamed appropriately.  Memory allocations moved out of this function as
  well, which enables the retries if the initial FDT size is too small.
  Note that in order to do the retried allocations, the original FDT and 
  command line memory regions are left allocated.  This is OK since the kernel
  has the memory map and will free these allocations along with the initrd
  and new fdt allocations.
* Added prefix to all prints, reduced number of prints, and reviewed all
  messages.
* Change mixed usage of dtb/fdt to all be fdt or device tree in efi-stub.c
* remove unnecessary zimage_size variable from relocate_kernel()
* correct return types on EFI functions - should be efi_status_t, not int.
Roy Franz (8):
  efi-stub.txt updates for ARM
  Add shared printk wrapper for consistent prefixing
  Add helper function to get and convert EFI

[PATCH V6 2/8] Add shared printk wrapper for consistent prefixing

[Roy Franz]

Add a wrapper for printk to standardize the prefix for informational and
error messages from the EFI stub.

Signed-off-by: Roy Franz roy.fr...@linaro.org
---
 drivers/firmware/efi/efi-stub-helper.c |   25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index b6bffbf..eb5d2eb 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -45,6 +45,9 @@ static void efi_printk(efi_system_table_t *sys_table_arg, 
char *str)
}
 }
 
+#define pr_efi(sys_table, msg) efi_printk(sys_table, EFI stub: msg)
+#define pr_efi_err(sys_table, msg) efi_printk(sys_table, EFI stub: ERROR: 
msg)
+
 
 static efi_status_t efi_get_memory_map(efi_system_table_t *sys_table_arg,
   efi_memory_desc_t **map,
@@ -324,7 +327,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
nr_files * sizeof(*files),
(void **)files);
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, Failed to alloc mem for file handle 
list\n);
+   pr_efi_err(sys_table_arg, Failed to alloc mem for file handle 
list\n);
goto fail;
}
 
@@ -376,13 +379,13 @@ static efi_status_t 
handle_cmdline_files(efi_system_table_t *sys_table_arg,
image-device_handle, fs_proto,
(void **)io);
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, Failed to handle 
fs_proto\n);
+   pr_efi_err(sys_table_arg, Failed to handle 
fs_proto\n);
goto free_files;
}
 
status = efi_call_phys2(io-open_volume, io, fh);
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, Failed to open 
volume\n);
+   pr_efi_err(sys_table_arg, Failed to open 
volume\n);
goto free_files;
}
}
@@ -390,7 +393,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
status = efi_call_phys5(fh-open, fh, h, filename_16,
EFI_FILE_MODE_READ, (u64)0);
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, Failed to open file: );
+   pr_efi_err(sys_table_arg, Failed to open file: );
efi_char16_printk(sys_table_arg, filename_16);
efi_printk(sys_table_arg, \n);
goto close_handles;
@@ -402,7 +405,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
status = efi_call_phys4(h-get_info, h, info_guid,
info_sz, NULL);
if (status != EFI_BUFFER_TOO_SMALL) {
-   efi_printk(sys_table_arg, Failed to get file info 
size\n);
+   pr_efi_err(sys_table_arg, Failed to get file info 
size\n);
goto close_handles;
}
 
@@ -411,7 +414,7 @@ grow:
EFI_LOADER_DATA, info_sz,
(void **)info);
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, Failed to alloc mem for file 
info\n);
+   pr_efi_err(sys_table_arg, Failed to alloc mem for file 
info\n);
goto close_handles;
}
 
@@ -427,7 +430,7 @@ grow:
efi_call_phys1(sys_table_arg-boottime-free_pool, info);
 
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, Failed to get file info\n);
+   pr_efi_err(sys_table_arg, Failed to get file info\n);
goto close_handles;
}
 
@@ -446,13 +449,13 @@ grow:
status = efi_high_alloc(sys_table_arg, file_size_total, 0x1000,
file_addr, max_addr);
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, Failed to alloc highmem for 
files\n);
+   pr_efi_err(sys_table_arg, Failed to alloc highmem for 
files\n);
goto close_handles;
}
 
/* We've run out of free low memory. */
if (file_addr  max_addr) {
-   efi_printk(sys_table_arg, We've run out of free low 
memory\n);
+   pr_efi_err(sys_table_arg, We've run out of free low 
memory\n);
status = EFI_INVALID_PARAMETER;
goto

[PATCH V6 8/8] Add config EFI_STUB for ARM to Kconfig

[Roy Franz]

The previous patches have added the implementation of the EFI stub
functionality to the kernel, so now the Kconfig support is added
to enable it.

Signed-off-by: Roy Franz roy.fr...@linaro.org
---
 arch/arm/Kconfig |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1ab24cc..b650a38 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1867,6 +1867,17 @@ config EFI
  However, even with this option, the resultant kernel will
  continue to boot on non-UEFI platforms.
 
+config EFI_STUB
+   bool EFI stub support
+   depends on EFI  !CPU_BIG_ENDIAN
+   ---help---
+ This kernel feature allows a zImage to be loaded directly by EFI
+ firmware without the use of a bootloader.  A PE/COFF header is
+ added to the zImage in a way that makes the binary both a Linux
+ zImage and an PE/COFF executable that can be executed directly by
+ EFI firmware.
+ See Documentation/efi-stub.txt for more information.
+
 config SECCOMP
bool
prompt Enable seccomp to safely compute untrusted bytecode
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 6/8] Add EFI stub for ARM

[Roy Franz]

This patch adds EFI stub support for the ARM Linux kernel.  The EFI stub
operates similarly to the x86 stub: it is a shim between the EFI firmware
and the normal zImage entry point, and sets up the environment that the
zImage is expecting.  This includes loading the initrd (optionaly) and
device tree from the system partition based on the kernel command line.
The stub updates the device tree as necessary, adding entries for EFI
runtime services. The PE/COFF MZ header at offset 0 results in the
first instruction being an add that corrupts r5, which is not used by
the zImage interface.

Signed-off-by: Roy Franz roy.fr...@linaro.org
Acked-by: Grant Likely grant.lik...@linaro.org
---
 arch/arm/boot/compressed/Makefile |   15 ++-
 arch/arm/boot/compressed/efi-header.S |  117 ++
 arch/arm/boot/compressed/efi-stub.c   |  214 +
 arch/arm/boot/compressed/efi-stub.h   |5 +
 arch/arm/boot/compressed/head.S   |   83 -
 5 files changed, 426 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/boot/compressed/efi-header.S
 create mode 100644 arch/arm/boot/compressed/efi-stub.c
 create mode 100644 arch/arm/boot/compressed/efi-stub.h

diff --git a/arch/arm/boot/compressed/Makefile 
b/arch/arm/boot/compressed/Makefile
index e7190bb..c0c7fee 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -99,11 +99,22 @@ libfdt_objs := $(addsuffix .o, $(basename $(libfdt)))
 $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: 
$(srctree)/scripts/dtc/libfdt/%
$(call cmd,shipped)
 
-$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
+$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o efi-stub.o): \
$(addprefix $(obj)/,$(libfdt_hdrs))
 
 ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
-OBJS   += $(libfdt_objs) atags_to_fdt.o
+OBJS   += atags_to_fdt.o
+USE_LIBFDT = y
+endif
+
+ifeq ($(CONFIG_EFI_STUB),y)
+CFLAGS_efi-stub.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
+OBJS   += efi-stub.o
+USE_LIBFDT = y
+endif
+
+ifeq ($(USE_LIBFDT),y)
+OBJS   += $(libfdt_objs)
 endif
 
 targets   := vmlinux vmlinux.lds \
diff --git a/arch/arm/boot/compressed/efi-header.S 
b/arch/arm/boot/compressed/efi-header.S
new file mode 100644
index 000..dbb7101
--- /dev/null
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -0,0 +1,117 @@
+@ Copyright (C) 2013 Linaro Ltd;  roy.fr...@linaro.org
+@
+@ This file contains the PE/COFF header that is part of the
+@ EFI stub.
+@
+
+   .org0x3c
+   @
+   @ The PE header can be anywhere in the file, but for
+   @ simplicity we keep it together with the MSDOS header
+   @ The offset to the PE/COFF header needs to be at offset
+   @ 0x3C in the MSDOS header.
+   @ The only 2 fields of the MSDOS header that are used are this
+   @ PE/COFF offset, and the MZ bytes at offset 0x0.
+   @
+   .long   pe_header   @ Offset to the PE header.
+
+  .align 3
+pe_header:
+   .ascii  PE
+   .short  0
+
+coff_header:
+   .short  0x01c2  @ ARM or Thumb
+   .short  2   @ nr_sections
+   .long   0   @ TimeDateStamp
+   .long   0   @ PointerToSymbolTable
+   .long   1   @ NumberOfSymbols
+   .short  section_table - optional_header @ SizeOfOptionalHeader
+   .short  0x306   @ Characteristics.
+   @ IMAGE_FILE_32BIT_MACHINE |
+   @ IMAGE_FILE_DEBUG_STRIPPED |
+   @ IMAGE_FILE_EXECUTABLE_IMAGE |
+   @ IMAGE_FILE_LINE_NUMS_STRIPPED
+
+optional_header:
+   .short  0x10b   @ PE32 format
+   .byte   0x02@ MajorLinkerVersion
+   .byte   0x14@ MinorLinkerVersion
+
+   .long   _edata - efi_stub_entry @ SizeOfCode
+
+   .long   0   @ SizeOfInitializedData
+   .long   0   @ SizeOfUninitializedData
+
+   .long   efi_stub_entry  @ AddressOfEntryPoint
+   .long   efi_stub_entry  @ BaseOfCode
+   .long   0   @ data
+
+extra_header_fields:
+   .long   0   @ ImageBase
+   .long   0x20@ SectionAlignment
+   .long   0x8 @ FileAlignment
+   .short  0   @ MajorOperatingSystemVersion
+   .short  0   @ MinorOperatingSystemVersion
+   .short  0   @ MajorImageVersion
+   .short  0   @ MinorImageVersion
+   .short  0

[PATCH V6 7/8] Disable stack protection for decompressor/stub

[Roy Franz]

The ARM decompressor/EFI stub do not implement the functions
(__stack_chk_guard_setup, etc) that are required for support of
stack protection.  The actual enablement of stack protection is
controlled by heuristics in GCC, which the code added for the EFI
stub triggers when CONFIG_STACKPROTECTOR is set.  Even with
CONFIG_STACKPROTECTOR set, the decompressor was never compiled
with stack protection actually enabled. Adding -fno-stack-protector
to the decompressor/stub build keeps it building without stack
protection as it has always been built.
The x86 decompressor/stub is also built with -fno-stack-protector.

Signed-off-by: Roy Franz roy.fr...@linaro.org
---
 arch/arm/boot/compressed/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile 
b/arch/arm/boot/compressed/Makefile
index c0c7fee..7974791 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -132,7 +132,7 @@ ORIG_CFLAGS := $(KBUILD_CFLAGS)
 KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
 endif
 
-ccflags-y := -fpic -mno-single-pic-base -fno-builtin -I$(obj)
+ccflags-y := -fpic -mno-single-pic-base -fno-builtin -fno-stack-protector 
-I$(obj)
 asflags-y := -DZIMAGE
 
 # Supply kernel BSS size to the decompressor via a linker symbol.
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 4/8] Add shared FDT related functions for ARM/ARM64

[Roy Franz]

Both ARM and ARM64 stubs will update the device tree that they pass to
the kernel.  In both cases they primarily need to add the same UEFI
related information, so the function can be shared.  Create a new FDT
related file for this to avoid use of architecture #ifdefs in
efi-stub-helper.c.

Signed-off-by: Roy Franz roy.fr...@linaro.org
Acked-by: Grant Likely grant.lik...@linaro.org
---
 drivers/firmware/efi/fdt.c |  225 
 1 file changed, 225 insertions(+)
 create mode 100644 drivers/firmware/efi/fdt.c

diff --git a/drivers/firmware/efi/fdt.c b/drivers/firmware/efi/fdt.c
new file mode 100644
index 000..e38f330
--- /dev/null
+++ b/drivers/firmware/efi/fdt.c
@@ -0,0 +1,225 @@
+/*
+ * FDT related Helper functions used by the EFI stub on multiple
+ * architectures. This should be #included by the EFI stub
+ * implementation files.
+ *
+ * Copyright 2013 Linaro Limited; author Roy Franz
+ *
+ * This file is part of the Linux kernel, and is made available
+ * under the terms of the GNU General Public License version 2.
+ *
+ */
+
+struct fdt_region {
+   u64 base;
+   u64 size;
+};
+
+static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
+  void *fdt, int new_fdt_size, char *cmdline_ptr,
+  u64 initrd_addr, u64 initrd_size,
+  efi_memory_desc_t *memory_map,
+  unsigned long map_size, unsigned long desc_size,
+  u32 desc_ver)
+{
+   int node;
+   int status;
+   u32 fdt_val32;
+   u64 fdt_val64;
+
+   /*
+* Copy definition of linux_banner here.  Since this code is
+* built as part of the decompressor for ARM v7, pulling
+* in version.c where linux_banner is defined for the
+* kernel brings other kernel dependencies with it.
+*/
+   const char linux_banner[] =
+   Linux version  UTS_RELEASE  ( LINUX_COMPILE_BY @
+   LINUX_COMPILE_HOST ) ( LINUX_COMPILER )  UTS_VERSION \n;
+
+   status = fdt_open_into(orig_fdt, fdt, new_fdt_size);
+   if (status != 0)
+   goto fdt_set_fail;
+
+   node = fdt_subnode_offset(fdt, 0, chosen);
+   if (node  0) {
+   node = fdt_add_subnode(fdt, 0, chosen);
+   if (node  0) {
+   status = node; /* node is error code when negative */
+   goto fdt_set_fail;
+   }
+   }
+
+   if ((cmdline_ptr != NULL)  (strlen(cmdline_ptr)  0)) {
+   status = fdt_setprop(fdt, node, bootargs, cmdline_ptr,
+strlen(cmdline_ptr) + 1);
+   if (status)
+   goto fdt_set_fail;
+   }
+
+   /* Set initrd address/end in device tree, if present */
+   if (initrd_size != 0) {
+   u64 initrd_image_end;
+   u64 initrd_image_start = cpu_to_fdt64(initrd_addr);
+   status = fdt_setprop(fdt, node, linux,initrd-start,
+initrd_image_start, sizeof(u64));
+   if (status)
+   goto fdt_set_fail;
+   initrd_image_end = cpu_to_fdt64(initrd_addr + initrd_size);
+   status = fdt_setprop(fdt, node, linux,initrd-end,
+initrd_image_end, sizeof(u64));
+   if (status)
+   goto fdt_set_fail;
+   }
+
+   /* Add FDT entries for EFI runtime services in chosen node. */
+   node = fdt_subnode_offset(fdt, 0, chosen);
+   fdt_val64 = cpu_to_fdt64((u64)(unsigned long)sys_table);
+   status = fdt_setprop(fdt, node, linux,uefi-system-table,
+fdt_val64, sizeof(fdt_val64));
+   if (status)
+   goto fdt_set_fail;
+
+   fdt_val64 = cpu_to_fdt64((u64)(unsigned long)memory_map);
+   status = fdt_setprop(fdt, node, linux,uefi-mmap-start,
+fdt_val64,  sizeof(fdt_val64));
+   if (status)
+   goto fdt_set_fail;
+
+   fdt_val32 = cpu_to_fdt32(map_size);
+   status = fdt_setprop(fdt, node, linux,uefi-mmap-size,
+fdt_val32,  sizeof(fdt_val32));
+   if (status)
+   goto fdt_set_fail;
+
+   fdt_val32 = cpu_to_fdt32(desc_size);
+   status = fdt_setprop(fdt, node, linux,uefi-mmap-desc-size,
+fdt_val32, sizeof(fdt_val32));
+   if (status)
+   goto fdt_set_fail;
+
+   fdt_val32 = cpu_to_fdt32(desc_ver);
+   status = fdt_setprop(fdt, node, linux,uefi-mmap-desc-ver,
+fdt_val32, sizeof(fdt_val32));
+   if (status)
+   goto fdt_set_fail;
+
+   /*
+* Add kernel version banner so stub/kernel match can be
+* verified.
+*/
+   status = fdt_setprop_string(fdt, node, linux,uefi-stub-kern-ver

[PATCH V6 1/8] efi-stub.txt updates for ARM

[Roy Franz]

Update efi-stub.txt documentation to be more general
and not x86 specific.  Add ARM only dtb= command
line option description.

Signed-off-by: Roy Franz roy.fr...@linaro.org
Acked-by: Grant Likely grant.lik...@linaro.org
---
 Documentation/efi-stub.txt |   27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index 44e6bb6..a55a0cd 100644
--- a/Documentation/efi-stub.txt
+++ b/Documentation/efi-stub.txt
@@ -1,13 +1,16 @@
  The EFI Boot Stub
 ---
 
-On the x86 platform, a bzImage can masquerade as a PE/COFF image,
-thereby convincing EFI firmware loaders to load it as an EFI
-executable. The code that modifies the bzImage header, along with the
-EFI-specific entry point that the firmware loader jumps to are
-collectively known as the EFI boot stub, and live in
+On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
+as a PE/COFF image, thereby convincing EFI firmware loaders to load
+it as an EFI executable. The code that modifies the bzImage header,
+along with the EFI-specific entry point that the firmware loader
+jumps to are collectively known as the EFI boot stub, and live in
 arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
-respectively.
+respectively. For ARM the EFI stub is implemented in
+arch/arm/boot/compressed/efi-header.S and
+arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared
+between architectures is in drivers/firmware/efi/efi-stub-helper.c.
 
 By using the EFI boot stub it's possible to boot a Linux kernel
 without the use of a conventional EFI boot loader, such as grub or
@@ -23,7 +26,9 @@ The bzImage located in arch/x86/boot/bzImage must be copied 
to the EFI
 System Partiion (ESP) and renamed with the extension .efi. Without
 the extension the EFI firmware loader will refuse to execute it. It's
 not possible to execute bzImage.efi from the usual Linux file systems
-because EFI firmware doesn't have support for them.
+because EFI firmware doesn't have support for them. For ARM the
+arch/arm/boot/zImage should be copied to the system partition, and it
+may not need to be renamed.
 
 
  Passing kernel parameters from the EFI shell
@@ -63,3 +68,11 @@ Notice how bzImage.efi can be specified with a relative 
path. That's
 because the image we're executing is interpreted by the EFI shell,
 which understands relative paths, whereas the rest of the command line
 is passed to bzImage.efi.
+
+
+ The dtb= option
+
+For the ARM architecture, we also need to be able to provide a device
+tree to the kernel. This is done with the dtb= command line option,
+and is processed in the same manner as the initrd= option that is
+described above.
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 3/8] Add helper function to get and convert EFI command line

[Roy Franz]

Add an EFI stub helper function to retrieve the EFI command line using
the LOADED_IMAGE_PROTOCOL, and convert it to ASCII.  This function will
be shared by the various EFI stub implementations.

Signed-off-by: Roy Franz roy.fr...@linaro.org
---
 drivers/firmware/efi/efi-stub-helper.c |   30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index eb5d2eb..f657456 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -637,3 +637,33 @@ static char 
*efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
*cmd_line_len = options_size;
return (char *)cmdline_addr;
 }
+
+/*
+ * get the command line from EFI, using the LOADED_IMAGE
+ * protocol, and convert to ASCII.
+ *
+ */
+static void efi_get_cmdline(efi_system_table_t *sys_table,
+ efi_loaded_image_t **image,
+ void *handle, char **cmdline_ptr)
+{
+   efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
+   efi_status_t status;
+   int cmdline_size;
+
+   status = efi_call_phys3(sys_table-boottime-handle_protocol,
+   handle, proto, (void *)image);
+   if (status != EFI_SUCCESS) {
+   pr_efi_err(sys_table, Failed to get handle for 
LOADED_IMAGE_PROTOCOL\n);
+   *cmdline_ptr = NULL;
+   return;
+   }
+
+   /*
+* We are going to copy this into device tree, so we don't care where
+* in memory it is.
+*/
+   *cmdline_ptr = efi_convert_cmdline_to_ascii(sys_table, *image,
+   cmdline_size);
+
+}
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

[Roy Franz]

On Tue, Dec 10, 2013 at 4:30 AM, Grant Likely  wrote:
> On Fri, 6 Dec 2013 11:20:45 -0600, Matt Sealey  wrote:
>> On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett  wrote:
>> > On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
>> Grant suggested I should propose some patches; sure, if I'm not otherwise 
>> busy.
>>
>> Maybe the Linaro guys can recommend a platform (real or emulated) that
>> would be best to test it on with the available UEFI?
>
> Roy Franz (cc'd) has got UEFI running under QEMU. A few modifications
> were required to both stock UEFI and QEMU. I'm not sure what the status
> of mainlining those patches is. I think there are still a few things
> that Roy has to fix, but you should be able to get the current patches
> from him to get going.
>
> g.
>

Hi Grant and Matt,

I have put together a quick wiki page describing the current status,
with git trees for
UEFI and QEMU, and instructions for running the model.  I just whipped
this up now, so it
is pretty basic, but should have all the required information.

https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/VersatileExpress/QEMU

Please let me know if you have any questions.

Thanks,
Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

[Roy Franz]

On Tue, Dec 10, 2013 at 4:30 AM, Grant Likely grant.lik...@linaro.org wrote:
 On Fri, 6 Dec 2013 11:20:45 -0600, Matt Sealey n...@bakuhatsu.net wrote:
 On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
  On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
 Grant suggested I should propose some patches; sure, if I'm not otherwise 
 busy.

 Maybe the Linaro guys can recommend a platform (real or emulated) that
 would be best to test it on with the available UEFI?

 Roy Franz (cc'd) has got UEFI running under QEMU. A few modifications
 were required to both stock UEFI and QEMU. I'm not sure what the status
 of mainlining those patches is. I think there are still a few things
 that Roy has to fix, but you should be able to get the current patches
 from him to get going.

 g.


Hi Grant and Matt,

I have put together a quick wiki page describing the current status,
with git trees for
UEFI and QEMU, and instructions for running the model.  I just whipped
this up now, so it
is pretty basic, but should have all the required information.

https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/VersatileExpress/QEMU

Please let me know if you have any questions.

Thanks,
Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V5 4/6] Add EFI stub for ARM

[Roy Franz]

On Thu, Dec 5, 2013 at 12:00 PM, Grant Likely  wrote:
> On Wed, 27 Nov 2013 15:31:53 -0800, Roy Franz  wrote:
>> This patch adds EFI stub support for the ARM Linux kernel.  The EFI stub
>> operates similarly to the x86 stub: it is a shim between the EFI firmware
>> and the normal zImage entry point, and sets up the environment that the
>> zImage is expecting.  This includes loading the initrd (optionaly) and
>> device tree from the system partition based on the kernel command line.
>> The stub updates the device tree as necessary, adding entries for EFI
>> runtime services. The PE/COFF "MZ" header at offset 0 results in the
>> first instruction being an add that corrupts r5, which is not used by
>> the zImage interface.
>>
>> Signed-off-by: Roy Franz 
>
> I'm going to review this patch side-by-side with the ARM64 patch written
> by Mark. There are things that can still be consolidated. Otherwise the
> patch looks good.
>
>> ---
>> diff --git a/arch/arm/boot/compressed/efi-stub.c 
>> b/arch/arm/boot/compressed/efi-stub.c
>> new file mode 100644
>> index 000..2bd559d
>> --- /dev/null
>> +++ b/arch/arm/boot/compressed/efi-stub.c
>> @@ -0,0 +1,291 @@
>> +/*
>> + * linux/arch/arm/boot/compressed/efi-stub.c
>> + *
>> + * Copyright (C) 2013 Linaro Ltd;  
>> + *
>> + * This file implements the EFI boot stub for the ARM kernel
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +#include 
>> +#include 
>> +#include "efi-stub.h"
>> +
>> +/* EFI function call wrappers.  These are not required for
>> + * ARM, but wrappers are required for X86 to convert between
>> + * ABIs.  These wrappers are provided to allow code sharing
>> + * between X86 and ARM.  Since these wrappers directly invoke the
>> + * EFI function pointer, the function pointer type must be properly
>> + * defined, which is not the case for X86  One advantage of this is
>> + * it allows for type checking of arguments, which is not
>> + * possible with the X86 wrappers.
>> + */
>> +#define efi_call_phys0(f)f()
>> +#define efi_call_phys1(f, a1)f(a1)
>> +#define efi_call_phys2(f, a1, a2)f(a1, a2)
>> +#define efi_call_phys3(f, a1, a2, a3)f(a1, a2, a3)
>> +#define efi_call_phys4(f, a1, a2, a3, a4)f(a1, a2, a3, a4)
>> +#define efi_call_phys5(f, a1, a2, a3, a4, a5)f(a1, a2, a3, a4, a5)
>
> Identical to ARM64. I would put this into a common header usable by
> platforms that can call the functions directly.
>
>> +
>> +/* The maximum uncompressed kernel size is 32 MBytes, so we will reserve
>> + * that for the decompressed kernel.  We have no easy way to tell what
>> + * the actuall size of code + data the uncompressed kernel will use.
>> + */
>> +#define MAX_UNCOMP_KERNEL_SIZE   0x0200
>> +
>> +/* The kernel zImage should be located between 32 Mbytes
>> + * and 128 MBytes from the base of DRAM.  The min
>> + * address leaves space for a maximal size uncompressed image,
>> + * and the max address is due to how the zImage decompressor
>> + * picks a destination address.
>> + */
>> +#define ZIMAGE_OFFSET_LIMIT  0x0800
>> +#define MIN_ZIMAGE_OFFSETMAX_UNCOMP_KERNEL_SIZE
>> +
>> +#define PRINTK_PREFIX"EFIstub: "
>> +
>> +struct fdt_region {
>> + u64 base;
>> + u64 size;
>> +};
>
> Identical to ARM64; move to header.
>
>> +
>> +
>> +/* Include shared EFI stub code, and required headers. */
>> +#include "../../../../include/generated/compile.h"
>> +#include "../../../../include/generated/utsrelease.h"
>> +#include "../../../../drivers/firmware/efi/efi-stub-helper.c"
>> +#include "../../../../drivers/firmware/efi/fdt.c"
>> +
>> +
>> +int efi_entry(void *handle, efi_system_table_t *sys_table,
>> +   unsigned long *zimage_addr)
>> +{
>> + efi_loaded_image_t *image;
>> + int status;
>> + unsigned long nr_pages;
>> + const struct fdt_region *region;
>> +
>> + void *fdt;
>> + int err;
>> + int node;
>> + unsigned long zimage_size = 0;
>> + unsigned long dram_base;
>> + /* addr/point and size pairs for memory management*/
>> + unsigned long initrd_addr

Re: [PATCH V5 2/6] Add shared update_fdt() function for ARM/ARM64

[Roy Franz]

On Thu, Dec 5, 2013 at 11:24 AM, Grant Likely  wrote:
> On Wed, 27 Nov 2013 15:31:51 -0800, Roy Franz  wrote:
>> Both ARM and ARM64 stubs will update the device tree
>> that they pass to the kernel.  In both cases they
>> primarily need to add the same UEFI related information,
>> so the function can be shared.
>> Create a new FDT related file for this to avoid use
>> of architecture #ifdefs in efi-stub-helper.c
>> Change EFI allocation type for memory map to
>> EFI_RUNTIME_SERVICES_DATA, since we are passing
>> this buffer to the kernel, or immediately freeing it.
>>
>> Signed-off-by: Roy Franz 
>
> Hi Roy,
>
> Comments below...
>
>> +static efi_status_t update_fdt(efi_system_table_t *sys_table, void 
>> *orig_fdt,
>> +void *fdt, int new_fdt_size, char *cmdline_ptr,
>> +u64 initrd_addr, u64 initrd_size,
>> +efi_memory_desc_t *memory_map,
>> +unsigned long map_size, unsigned long desc_size,
>> +u32 desc_ver)
>> +{
>> + int node;
>> + int status;
>> + u32 fdt_val32;
>> + u64 fdt_val64;
>> + /* Copy definition of linux_banner here.  Since this code is
>> +  * built as part of the decompressor for ARM v7, pulling
>> +  * in version.c where linux_banner is defined for the
>> +  * kernel brings other kernel dependencies with it.
>> +  */
>> + const char linux_banner[] =
>> + "Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
>> + LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
>
> This is inherently fragile because the string is now defined in two
> places. This issue shouldn't hold off merging the patch, but a follow up
> patch should be crafted to make it possible to pull in version.c without
> the other dependencies
>
> Then again, the version.c strings have a very big "DON'T TOUCH" warning
> on them so I'm probably worrying about nothing.  :-)

I wasn't really happy about copying the definition here, but as this
will be verified by UEFI
code in the kernel if this every is changed it should not be much of a
problem in practice.
I can take a look at what changes would be required for using
version.c here.  I haven't worked
out what would need to be done, but was hesitant to make changes there
to support a one-off use
of the kernel version string outside of the kernel (ie in the
decompressor/stub), and was trying to keep
this patchset limited to changing arm/EFI code.

>
>> +
>> + status = fdt_open_into(orig_fdt, fdt, new_fdt_size);
>> + if (status != 0)
>> + goto fdt_set_fail;
>> +
>> + node = fdt_subnode_offset(fdt, 0, "chosen");
>> + if (node < 0) {
>> + node = fdt_add_subnode(fdt, 0, "chosen");
>> + if (node < 0) {
>> + status = node; /* node is error code when negative */
>> + goto fdt_set_fail;
>> + }
>> + }
>> +
>> + if ((cmdline_ptr != NULL) && (strlen(cmdline_ptr) > 0)) {
>> + status = fdt_setprop(fdt, node, "bootargs", cmdline_ptr,
>> +  strlen(cmdline_ptr) + 1);
>> + if (status)
>> + goto fdt_set_fail;
>> + }
>> +
>> + /* Set intird address/end in device tree, if present */
>
> sp. initrd
>
> None of the above comments are blockers though.
>
> Acked-by: Grant Likely 
>

Thanks,
Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/