From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: patrick.rudolph@9elements.com
Cc: linux-kernel@vger.kernel.org,
Filipe Brandenburger <filbranden@chromium.org>,
Duncan Laurie <dlaurie@chromium.org>,
Aaron Durbin <adurbin@chromium.org>,
Thomas Gleixner <tglx@linutronix.de>,
Samuel Holland <samuel@sholland.org>,
Julius Werner <jwerner@chromium.org>,
Stephen Boyd <swboyd@chromium.org>
Subject: Re: [PATCH 1/2] firmware: coreboot: Export the binary FMAP
Date: Tue, 8 Oct 2019 14:03:17 +0200 [thread overview]
Message-ID: <20191008120317.GA2761030@kroah.com> (raw)
In-Reply-To: <20191008115342.28483-1-patrick.rudolph@9elements.com>
On Tue, Oct 08, 2019 at 01:53:25PM +0200, patrick.rudolph@9elements.com wrote:
> From: Patrick Rudolph <patrick.rudolph@9elements.com>
>
> Expose coreboot's binary FMAP[1] to /sys/firmware/fmap.
>
> coreboot copies the FMAP to a CBMEM buffer at boot since CB:35377[2],
> allowing an architecture independ way of exposing the FMAP to userspace.
>
> Will be used by fwupd[3] to determine the current firmware layout.
>
> [1]: https://doc.coreboot.org/lib/flashmap.html
> [2]: https://review.coreboot.org/c/coreboot/+/35377
> [3]: https://fwupd.org/
>
> Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
> ---
> drivers/firmware/google/Kconfig | 8 ++
> drivers/firmware/google/Makefile | 1 +
> drivers/firmware/google/fmap-coreboot.c | 156 ++++++++++++++++++++++
> drivers/firmware/google/fmap-coreboot.h | 13 ++
> drivers/firmware/google/fmap_serialized.h | 59 ++++++++
> 5 files changed, 237 insertions(+)
> create mode 100644 drivers/firmware/google/fmap-coreboot.c
> create mode 100644 drivers/firmware/google/fmap-coreboot.h
> create mode 100644 drivers/firmware/google/fmap_serialized.h
>
> diff --git a/drivers/firmware/google/Kconfig b/drivers/firmware/google/Kconfig
> index a3a6ca659ffa..5fbbd7b8fef6 100644
> --- a/drivers/firmware/google/Kconfig
> +++ b/drivers/firmware/google/Kconfig
> @@ -74,4 +74,12 @@ config GOOGLE_VPD
> This option enables the kernel to expose the content of Google VPD
> under /sys/firmware/vpd.
>
> +config GOOGLE_FMAP
> + tristate "Coreboot FMAP access"
> + depends on GOOGLE_COREBOOT_TABLE
> + help
> + This option enables the kernel to search for a Google FMAP in
> + the coreboot table. If found, this binary file is exported to userland
> + in the file /sys/firmware/fmap.
> +
> endif # GOOGLE_FIRMWARE
> diff --git a/drivers/firmware/google/Makefile b/drivers/firmware/google/Makefile
> index d17caded5d88..6d31fe167700 100644
> --- a/drivers/firmware/google/Makefile
> +++ b/drivers/firmware/google/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_GOOGLE_FRAMEBUFFER_COREBOOT) += framebuffer-coreboot.o
> obj-$(CONFIG_GOOGLE_MEMCONSOLE) += memconsole.o
> obj-$(CONFIG_GOOGLE_MEMCONSOLE_COREBOOT) += memconsole-coreboot.o
> obj-$(CONFIG_GOOGLE_MEMCONSOLE_X86_LEGACY) += memconsole-x86-legacy.o
> +obj-$(CONFIG_GOOGLE_FMAP) += fmap-coreboot.o
>
> vpd-sysfs-y := vpd.o vpd_decode.o
> obj-$(CONFIG_GOOGLE_VPD) += vpd-sysfs.o
> diff --git a/drivers/firmware/google/fmap-coreboot.c b/drivers/firmware/google/fmap-coreboot.c
> new file mode 100644
> index 000000000000..14050030ebc6
> --- /dev/null
> +++ b/drivers/firmware/google/fmap-coreboot.c
> @@ -0,0 +1,156 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * fmap-coreboot.c
> + *
> + * Exports the binary FMAP through coreboot table.
> + *
> + * Copyright 2012-2013 David Herrmann <dh.herrmann@gmail.com>
> + * Copyright 2017 Google Inc.
> + * Copyright 2019 9elements Agency GmbH <patrick.rudolph@9elements.com>
> + */
> +
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/mm.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/string.h>
> +#include <linux/io.h>
> +
> +#include "coreboot_table.h"
> +#include "fmap_serialized.h"
> +
> +#define CB_TAG_FMAP 0x37
> +
> +static void *fmap;
> +static u32 fmap_size;
> +
> +/*
> + * Convert FMAP region to name.
> + * The caller has to free the string.
> + * Return NULL if no containing region was found.
> + */
> +const char *coreboot_fmap_region_to_name(const u32 start, const u32 size)
> +{
> + const char *name = NULL;
> + struct fmap *iter;
> + u32 size_old = ~0;
> + int i;
> +
> + iter = fmap;
> + /* Find smallest containing region */
> + for (i = 0; i < iter->nareas && fmap; i++) {
> + if (iter->areas[i].offset <= start &&
> + iter->areas[i].size >= size &&
> + iter->areas[i].size <= size_old) {
> + size_old = iter->areas[i].size;
> + name = iter->areas[i].name;
> + }
> + }
> +
> + if (name)
> + return kstrdup(name, GFP_KERNEL);
> + return NULL;
> +}
> +EXPORT_SYMBOL(coreboot_fmap_region_to_name);
> +
> +static ssize_t fmap_read(struct file *filp, struct kobject *kobp,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t pos, size_t count)
> +{
> + if (!fmap)
> + return -ENODEV;
> +
> + return memory_read_from_buffer(buf, count, &pos, fmap, fmap_size);
> +}
> +
> +static int fmap_probe(struct coreboot_device *dev)
> +{
> + struct lb_cbmem_ref *cbmem_ref = &dev->cbmem_ref;
> + struct fmap *header;
> +
> + if (!cbmem_ref)
> + return -ENODEV;
> +
> + header = memremap(cbmem_ref->cbmem_addr, sizeof(*header), MEMREMAP_WB);
> + if (!header) {
> + pr_warn("coreboot: Failed to remap FMAP\n");
Doesn't memremap print an error if it fails?
> + return -ENOMEM;
> + }
> +
> + /* Validate FMAP signature */
> + if (memcmp(header->signature, FMAP_SIGNATURE,
> + sizeof(header->signature))) {
> + pr_warn("coreboot: FMAP signature mismatch\n");
How can this happen? Shouldn't it be an error?
> + memunmap(header);
> + return -ENODEV;
> + }
> +
> + /* Validate FMAP version */
> + if (header->ver_major != FMAP_VER_MAJOR) {
> + pr_warn("coreboot: FMAP version not supported\n");
error?
And why are these not dev_err() and friends?
> + memunmap(header);
> + return -ENODEV;
> + }
> +
> + pr_info("coreboot: Got valid FMAP v%u.%u for 0x%x byte ROM\n",
> + header->ver_major, header->ver_minor, header->size);
Do not be noisy if all goes well. This should be debugging only.
> +
> + fmap_size = sizeof(*header) + header->nareas * sizeof(struct fmap_area);
> + memunmap(header);
> +
> + fmap = devm_memremap(&dev->dev, cbmem_ref->cbmem_addr, fmap_size,
> + MEMREMAP_WB);
> + if (!fmap) {
> + pr_warn("coreboot: Failed to remap FMAP\n");
Same here as above.
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> +static int fmap_remove(struct coreboot_device *dev)
> +{
> + struct platform_device *pdev = dev_get_drvdata(&dev->dev);
> +
> + platform_device_unregister(pdev);
> +
> + return 0;
> +}
> +
> +static struct coreboot_driver fmap_driver = {
> + .probe = fmap_probe,
> + .remove = fmap_remove,
> + .drv = {
> + .name = "fmap",
> + },
> + .tag = CB_TAG_FMAP,
> +};
> +
> +static struct bin_attribute fmap_bin_attr = {
> + .attr = {.name = "fmap", .mode = 0444},
> + .read = fmap_read,
> +};
BIN_ATTR_RO()?
And you forgot the Documentation/ABI/ update for your new sysfs file :(
I'm guessing all of these same issues are in your 2/2 patch, so I'll let
you fix them up and resend the series.
thanks,
greg k-h
next prev parent reply other threads:[~2019-10-08 12:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 11:53 [PATCH 1/2] firmware: coreboot: Export the binary FMAP patrick.rudolph
2019-10-08 11:53 ` [PATCH 2/2] firmware: coreboot: Export active CBFS partition patrick.rudolph
2019-10-08 22:47 ` Stephen Boyd
2019-10-09 21:19 ` Julius Werner
2019-10-10 9:46 ` patrick.rudolph
2019-10-10 14:09 ` Stephen Boyd
2019-10-10 18:37 ` Julius Werner
2019-10-16 20:12 ` Stephen Boyd
2019-10-19 2:14 ` Julius Werner
2019-10-11 0:03 ` Samuel Holland
2019-10-08 12:03 ` Greg Kroah-Hartman [this message]
2019-10-08 22:47 ` [PATCH 1/2] firmware: coreboot: Export the binary FMAP Stephen Boyd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191008120317.GA2761030@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=adurbin@chromium.org \
--cc=dlaurie@chromium.org \
--cc=filbranden@chromium.org \
--cc=jwerner@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patrick.rudolph@9elements.com \
--cc=samuel@sholland.org \
--cc=swboyd@chromium.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).