From: Brian Norris <briannorris@chromium.org>
To: Michal Gorlas <michal.gorlas@9elements.com>
Cc: Tzung-Bi Shih <tzungbi@kernel.org>,
Julius Werner <jwerner@chromium.org>,
marcello.bauer@9elements.com, chrome-platform@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/3] firmware: coreboot: loader for Linux-owned SMI handler
Date: Thu, 12 Jun 2025 15:38:21 -0700 [thread overview]
Message-ID: <aEtW3e7mwjTTvfO9@google.com> (raw)
In-Reply-To: <6cfb5bae79c153c54da298c396adb8a28b5e785a.1749734094.git.michal.gorlas@9elements.com>
On Thu, Jun 12, 2025 at 04:05:49PM +0200, Michal Gorlas wrote:
> Places a blob with Linux-owned SMI handler in the lower 4GB of memory, calculates
> entry points for the it and triggers SMI to coreboot's SMI handler
> informing it where to look for Linux-owned SMI handler.
>
> Signed-off-by: Michal Gorlas <michal.gorlas@9elements.com>
> ---
> drivers/firmware/google/Makefile | 9 ++
> drivers/firmware/google/mm_blob.S | 20 +++
> drivers/firmware/google/mm_loader.c | 186 ++++++++++++++++++++++++++++
...
> --- /dev/null
> +++ b/drivers/firmware/google/mm_loader.c
> @@ -0,0 +1,186 @@
...
> +static int register_entry_point(struct mm_info *data, uint32_t entry_point)
> +{
> + u64 cmd;
> + u8 status;
> +
> + cmd = data->register_mm_entry_command |
> + (PAYLOAD_MM_REGISTER_ENTRY << 8);
> + status = trigger_smi(cmd, entry_point, 5);
> + pr_info(DRIVER_NAME ": %s: SMI returned %x\n", __func__, status);
Don't print this kind of debug stuff at INFO level. If you need it, use
KERN_DEBUG.
Once this gets attached to a proper device/driver, you probably want
dev_dbg(), if anything.
> +
> + return status;
> +}
> +
> + /* At this point relocations are done and we can do some cool
/*
* Multiline comment style is like this.
* i.e., start with "/*" on its own line.
* You got this right most of the time.
*/
> + * pointer arithmetics to help coreboot determine correct entry
> + * point based on offsets.
> + */
> + entry32_offset = mm_header->mm_entry_32 - (unsigned long)shared_buffer;
> + entry64_offset = mm_header->mm_entry_64 - (unsigned long)shared_buffer;
> +
> + mm_header->mm_entry_32 = entry32_offset;
> + mm_header->mm_entry_64 = entry64_offset;
> +
> + return (unsigned long)shared_buffer;
> +}
> +
> +static int __init mm_loader_init(void)
> +{
> + u32 entry_point;
> +
> + if (!mm_info)
> + return -ENOMEM;
Hmm, so you have two modules, mm_info and mm_loader. mm_loader depends
on mm_info, but doesn't actually express that dependency. Can you just
merge mm_loader into mm_info or vice versa? Or at least, pass the
necessary data directly between the two, not as some implicit ordering
like this.
> +
> + entry_point = place_handler();
> +
> + if (register_entry_point(mm_info, entry_point)) {
> + pr_warn(DRIVER_NAME ": registering entry point for MM payload failed.\n");
> + kfree(mm_info);
> + mm_info = NULL;
> + free_pages((unsigned long)shared_buffer, get_order(blob_size));
> + return -1;
> + }
> +
> + mdelay(100);
Why the delay? At least use a comment to tell us. And if it's really
needed, use msleep(), not mdelay(). scripts/checkpatch.pl should have
warned you. And, please use scripts/checkpatch.pl if you aren't already
;)
> +
> + kfree(mm_info);
> + mm_info = NULL;
This is odd and racy, having one module free data provided by another,
where that other module might also free it. Hopefully this gets
simplified if you manage to combine the modules, like I suggest.
> + free_pages((unsigned long)shared_buffer, get_order(blob_size));
> +
> + return 0;
> +}
> +
> +static void __exit mm_loader_exit(void)
> +{
> + pr_info(DRIVER_NAME ": DONE\n");
> +}
Remove this function. We don't do prints like this.
Brian
> +
> +module_init(mm_loader_init);
> +module_exit(mm_loader_exit);
> +
> +MODULE_AUTHOR("Michal Gorlas <michal.gorlas@9elements.com>");
> +MODULE_DESCRIPTION("MM Payload loader - installs Linux-owned SMI handler");
> +MODULE_LICENSE("GPL v2");
> --
> 2.49.0
>
next prev parent reply other threads:[~2025-06-12 22:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-12 14:05 [PATCH v1 0/3] firmware: coreboot: Support for System Management Interrupt (SMI) handling in coreboot payload (MM payload concept) Michal Gorlas
2025-06-12 14:05 ` [PATCH v1 1/3] firmware: coreboot: support for parsing SMM related informations from coreboot tables Michal Gorlas
2025-06-12 22:37 ` Brian Norris
2025-06-14 12:53 ` Michal Gorlas
2025-06-16 18:16 ` Brian Norris
2025-06-17 9:37 ` Michal Gorlas
2025-06-12 14:05 ` [PATCH v1 2/3] firmware: coreboot: loader for Linux-owned SMI handler Michal Gorlas
2025-06-12 22:38 ` Brian Norris [this message]
2025-06-14 12:59 ` Michal Gorlas
2025-06-16 18:07 ` Brian Norris
2025-06-17 11:39 ` Michal Gorlas
2025-06-13 5:21 ` kernel test robot
2025-06-12 14:05 ` [PATCH v1 3/3] firmware: coreboot: Linux-owned SMI handler to be loaded by coreboot Michal Gorlas
2025-06-12 22:38 ` Brian Norris
2025-06-13 12:11 ` kernel test robot
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=aEtW3e7mwjTTvfO9@google.com \
--to=briannorris@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=jwerner@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcello.bauer@9elements.com \
--cc=michal.gorlas@9elements.com \
--cc=tzungbi@kernel.org \
/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