From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Sean Rhodes <sean@starlabs.systems>
Cc: hansg@kernel.org, ilpo.jarvinen@linux.intel.com,
corentin.chary@gmail.com, luke@ljones.dev,
denis.benato@linux.dev, prasanth.ksr@dell.com,
jorge.lopez2@hp.com, mpearson-lenovo@squebb.ca,
derekjohn.clark@gmail.com, josh@joshuagrisham.com,
briannorris@chromium.org, jwerner@chromium.org,
tzimmermann@suse.de, javierm@redhat.com, kees@kernel.org,
u.kleine-koenig@baylibre.com, mst@redhat.com,
chenhuacai@kernel.org, wenst@chromium.org,
florian.fainelli@broadcom.com, titouan.ameline@gmail.com,
linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org, Dell.Client.Kernel@dell.com,
chrome-platform@lists.linux.dev
Subject: Re: [PATCH v6 3/3] firmware: coreboot: Add CFR firmware attributes driver
Date: Fri, 17 Jul 2026 05:53:31 +0000 [thread overview]
Message-ID: <alnDWxTSZv5DKcB9@google.com> (raw)
In-Reply-To: <20260713081317.2954586-4-sean@starlabs.systems>
On Mon, Jul 13, 2026 at 09:13:17AM +0100, Sean Rhodes wrote:
> diff --git a/drivers/firmware/coreboot/coreboot-cfr.c b/drivers/firmware/coreboot/coreboot-cfr.c
...
> +static const struct coreboot_table_entry *
> +coreboot_cfr_child_entry(const void *base, size_t len, u32 tag)
> +{
> + const struct coreboot_table_entry *entry;
> + size_t off = 0;
> +
> + while (off < len) {
To be concise,
for (off = 0; off < len; off += entry->size)
> +static bool coreboot_cfr_value_is_valid(struct coreboot_cfr_setting *setting,
> + u32 value)
> +{
> + u32 delta;
> +
> + if (setting->type != COREBOOT_CFR_SETTING_NUMBER)
> + return coreboot_cfr_label_from_value(setting, value);
This deserves a comment as coreboot_cfr_label_from_value() returns a `char *`
instead of bool.
> +static ssize_t possible_values_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct coreboot_cfr_setting *setting = to_coreboot_cfr_setting(kobj);
> + ssize_t len = 0;
> + unsigned int i;
> +
> + for (i = 0; i < setting->n_values; i++) {
> + len += sysfs_emit_at(buf, len, "%s%s", i ? ";" : "",
> + setting->values[i].label);
> + if (len >= PAGE_SIZE)
> + return len;
Does it really need the check?
> +static int coreboot_cfr_count_enum_values(const void *base, size_t len)
> +{
> + const struct coreboot_table_entry *entry;
> + size_t off = 0;
> + int count = 0;
> +
> + while (off < len) {
To be consie,
for (off = 0; off < len; off += entry->size)
> +static int coreboot_cfr_copy_enum_values(struct coreboot_cfr_setting *setting,
> + const void *base, size_t len)
> +{
> + const struct lb_cfr_enum_value *enum_value;
> + const struct lb_cfr_varbinary *label;
> + const struct coreboot_table_entry *entry;
> + size_t off = 0;
> + int count;
> +
> + count = coreboot_cfr_count_enum_values(base, len);
> + if (count <= 0)
> + return count ?: -EINVAL;
> +
> + setting->values = kcalloc(count, sizeof(*setting->values), GFP_KERNEL);
> + if (!setting->values)
> + return -ENOMEM;
> +
> + while (off < len) {
To be consie,
for (off = 0; off < len; off += entry->size)
> +static int coreboot_cfr_parse_records(struct coreboot_cfr_drvdata *data,
> + const void *base, size_t len)
> +{
> + const struct coreboot_table_entry *entry;
> + const void *child_base;
> + size_t child_len;
> + size_t off = 0;
> + int ret;
> +
> + while (off < len) {
To be concise,
for (off = 0; off < len; off += entry->size)
> + switch (entry->tag) {
> + case CFR_TAG_OPTION_FORM:
> + if (entry->size < sizeof(struct lb_cfr_option_form))
> + return -EINVAL;
> +
> + child_base = base + off + sizeof(struct lb_cfr_option_form);
> + child_len = entry->size - sizeof(struct lb_cfr_option_form);
> + ret = coreboot_cfr_parse_records(data, child_base,
> + child_len);
> + if (ret)
> + return ret;
> + break;
> + case CFR_TAG_OPTION_ENUM:
> + case CFR_TAG_OPTION_NUMBER:
> + case CFR_TAG_OPTION_BOOL:
> + if (entry->size < sizeof(struct lb_cfr_numeric_option))
> + return -EINVAL;
> + ret = coreboot_cfr_add_numeric_option(data, base + off);
> + if (ret)
> + return ret;
> + break;
> + default:
> + break;
Doesn't it need to do anything if sees unknown `entry->tag`?
> +static int coreboot_cfr_probe(struct coreboot_device *dev)
> +{
...
> + data->class_dev = device_create(&firmware_attributes_class, NULL,
> + MKDEV(0, 0), NULL, DRIVER_NAME);
> + if (IS_ERR(data->class_dev)) {
> + ret = PTR_ERR(data->class_dev);
> + goto err_clear_data;
No more data to clear,
return PTR_ERR(...);
> +err_clear_data:
> + return ret;
Nothing to do other than a return. The label can be removed.
next prev parent reply other threads:[~2026-07-17 5:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 16:39 [PATCH v4 0/3] firmware: Add coreboot CFR firmware attributes driver Sean Rhodes
2026-07-13 5:45 ` [PATCH v5 " Sean Rhodes
2026-07-13 5:45 ` [PATCH v5 1/3] firmware: Move firmware attributes class helper Sean Rhodes
2026-07-13 7:13 ` Derek J. Clark
2026-07-13 5:45 ` [PATCH v5 2/3] firmware: Rename google firmware directory to coreboot Sean Rhodes
2026-07-13 5:45 ` [PATCH v5 3/3] firmware: coreboot: Add CFR firmware attributes driver Sean Rhodes
2026-07-13 8:13 ` [PATCH v6 0/3] firmware: Add coreboot " Sean Rhodes
2026-07-13 8:13 ` [PATCH v6 1/3] firmware: Move firmware attributes class helper Sean Rhodes
2026-07-13 10:03 ` Derek J. Clark
2026-07-15 12:11 ` Oliver Lin
2026-07-13 8:13 ` [PATCH v6 2/3] firmware: Rename google firmware directory to coreboot Sean Rhodes
2026-07-13 8:13 ` [PATCH v6 3/3] firmware: coreboot: Add CFR firmware attributes driver Sean Rhodes
2026-07-17 5:53 ` Tzung-Bi Shih [this message]
2026-07-13 9:53 ` [PATCH v6 0/3] firmware: Add coreboot " Derek J. Clark
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=alnDWxTSZv5DKcB9@google.com \
--to=tzungbi@kernel.org \
--cc=Dell.Client.Kernel@dell.com \
--cc=briannorris@chromium.org \
--cc=chenhuacai@kernel.org \
--cc=chrome-platform@lists.linux.dev \
--cc=corentin.chary@gmail.com \
--cc=denis.benato@linux.dev \
--cc=derekjohn.clark@gmail.com \
--cc=florian.fainelli@broadcom.com \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=javierm@redhat.com \
--cc=jorge.lopez2@hp.com \
--cc=josh@joshuagrisham.com \
--cc=jwerner@chromium.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luke@ljones.dev \
--cc=mpearson-lenovo@squebb.ca \
--cc=mst@redhat.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=prasanth.ksr@dell.com \
--cc=sean@starlabs.systems \
--cc=titouan.ameline@gmail.com \
--cc=tzimmermann@suse.de \
--cc=u.kleine-koenig@baylibre.com \
--cc=wenst@chromium.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