From: sashiko-bot@kernel.org
To: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, linux-gpio@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 4/9] device property: provide fwnode_property_get_names()
Date: Wed, 04 Nov 2026 14:12:38 +0000 [thread overview]
Message-ID: <sashiko-outbox-197409@kernel.org> (raw)
In-Reply-To: <20261104-fwnode-for-each-prop-v1-4-6e28fe1c72c4@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] device property: missing NULL check for props in fwnode_property_get_names()
--
commit c6de0ca7eaa5586d9db8c473e272baa86e7c8e04
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
device property: provide fwnode_property_get_names()
This commit adds fwnode_property_get_names() to retrieve the list of all
property names for a given firmware node, merging properties from both the
primary and secondary firmware nodes.
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index a97575ff91990..7b0df3dfae53b 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
[ ... ]
> @@ -542,6 +544,81 @@ int fwnode_property_match_string(const struct fwnode_handle *fwnode,
> }
> EXPORT_SYMBOL_GPL(fwnode_property_match_string);
>
> +/**
> + * fwnode_property_get_names - get the list of all properties of this fwnode
> + * @fwnode: Firmware node to get the list of properties for
> + * @props: Pointer to an array of strings. It will contain the address of the
> + * string list containing the property names.
> + *
> + * Return: Number of property names written into *props. If > 0, the caller must
> + * free the array with kfree_strarray(). *props is only valid for
> + * a positive return value.
> + * %-EINVAL if arguments are not valid
> + * %-ENXIO if no suitable firmware interface is present
> + * %-ENOMEM if memory allocation failed
> + *
> + * The list also includes the properties of the secondary firmware node, if
> + * any. Properties present in both nodes are listed once.
> + */
> +int fwnode_property_get_names(const struct fwnode_handle *fwnode, char ***props)
> +{
> + int ret1, ret2 = -ENXIO, n1, n2, i, j, count;
> + char **prim = NULL, **sec = NULL, **merged;
> +
> + if (IS_ERR_OR_NULL(fwnode))
> + return -EINVAL;
> +
> + ret1 = fwnode_call_int_op(fwnode, property_get_names, &prim);
> + if (!IS_ERR_OR_NULL(fwnode->secondary))
> + ret2 = fwnode_call_int_op(fwnode->secondary, property_get_names, &sec);
> +
> + if (ret1 == -ENXIO && ret2 == -ENXIO)
> + return -ENXIO;
> +
> + n1 = max(ret1, 0);
> + n2 = max(ret2, 0);
> +
> + CLASS(strarray, prim_props)(prim, n1);
> + CLASS(strarray, sec_props)(sec, n2);
> +
> + if (ret1 < 0 && ret1 != -ENXIO)
> + return ret1;
> +
> + if (ret2 < 0 && ret2 != -ENXIO)
> + return ret2;
> +
> + if (n1 == 0 && n2 == 0)
> + return 0;
> +
> + merged = kcalloc(n1 + n2, sizeof(*merged), GFP_KERNEL);
> + if (!merged)
> + return -ENOMEM;
> +
> + /* The strings are now owned by merged, only free the container. */
> + for (i = 0; i < n1; i++) {
> + merged[i] = prim_props.array[i];
> + prim_props.array[i] = NULL;
> + }
> + count = n1;
> +
> + /* Properties from the primary node take precedence. */
> + for (i = 0; i < n2; i++) {
> + for (j = 0; j < n1; j++) {
> + if (!strcmp(merged[j], sec_props.array[i]))
> + break;
> + }
> +
> + if (j >= n1) {
> + merged[count++] = sec_props.array[i];
> + sec_props.array[i] = NULL;
> + }
> + }
> +
> + *props = merged;
> + return count;
> +}
[Severity: Medium]
Should fwnode_property_get_names() in drivers/base/property.c also check
!props at entry and return -EINVAL?
The kernel-doc states that -EINVAL is returned if arguments are not valid,
and unlike fwnode_property_read_string_array(), props is not optional.
Because fwnode_property_get_names() passes &prim and &sec to the backend
property_get_names callbacks rather than forwarding props, the backend
callbacks never validate props either.
If a caller passes NULL for props (for instance, expecting it to query the
property count like fwnode_property_read_string_array()), it will return 0
instead of -EINVAL when the node has no properties, or dereference a NULL
props pointer at *props = merged and leak merged and all transferred property
name strings when the node has at least one property.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261104-fwnode-for-each-prop-v1-0-6e28fe1c72c4@oss.qualcomm.com?part=4
next prev parent reply other threads:[~2026-11-04 14:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 14:03 [PATCH 0/9] gpio: make gpiolib-shared more fwnode-centric Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 1/9] device property: fix fwnode_name_eq() for empty node names Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 2/9] lib: string_helpers: implement a CLASS() for string arrays Bartosz Golaszewski
2026-11-04 21:07 ` Andy Shevchenko
2026-11-04 14:03 ` [PATCH 3/9] fwnode: define the property_get_names() operation Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 4/9] device property: provide fwnode_property_get_names() Bartosz Golaszewski
2026-11-04 14:12 ` sashiko-bot [this message]
2026-11-04 21:17 ` Andy Shevchenko
2026-11-04 14:03 ` [PATCH 5/9] of: property: implement the .property_get_names() fwnode operation Bartosz Golaszewski
2026-11-04 14:18 ` sashiko-bot
2026-11-04 21:21 ` Andy Shevchenko
2026-11-04 14:03 ` [PATCH 6/9] fwnode: define the count_references() " Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 7/9] device property: provide fwnode_property_count_references() Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 8/9] of: property: implement the count_references() fwnode operation Bartosz Golaszewski
2026-11-04 15:33 ` Rob Herring
2026-11-04 14:03 ` [PATCH 9/9] gpio: shared: generalize most code to firmware nodes Bartosz Golaszewski
2026-11-04 14:15 ` sashiko-bot
2026-11-04 21:33 ` Andy Shevchenko
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=sashiko-outbox-197409@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.