From: Alejandro Colomar <alx+linux-hardening@kernel.org>
To: Bartosz Golaszewski <brgl@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Johan Hovold <johan@kernel.org>,
Hans Verkuil <hverkuil@kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Kees Cook <kees@kernel.org>, Andy Shevchenko <andy@kernel.org>,
Len Brown <lenb@kernel.org>, Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
Linus Walleij <linusw@kernel.org>,
linux-acpi@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
devicetree@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [PATCH 5/9] of: property: implement the .property_get_names() fwnode operation
Date: Tue, 10 Nov 2026 12:10:50 +0100 [thread overview]
Message-ID: <avL4LoCz2wc164zo@devuan> (raw)
In-Reply-To: <ab73ez55exen3ew52svsxfinwsuatppdodu2e2zp6izjwwqwwu@2imxzxwclgtl>
[-- Attachment #1: Type: text/plain, Size: 3008 bytes --]
Hi Bart,
> Date: 2026-11-10 10:00:42+0100
> From: Bartosz Golaszewski <brgl@kernel.org>
>
[...]
> > > > > + names[i] = kstrdup(prop->name, GFP_KERNEL);
> > > >
> > > > Can property be statically defined somewhere? We might want to also optimize
> > > > these duplications with const variant (here or elsewhere, for fwnode generic
> > > > path, I believe).
> > >
> > > Please rephrase because I'm not quite following what you're saying.
> >
> > Can prop->name come from something that is declared as
> >
> > static const ... foo = {
> > ... .name = "bar";
> > };
> >
>
> You can't know it for every instance of struct fwnode_handle, so the
> answer is: no.
>
> PS: is there a way of using match_string() with non-const data?
Given the definition here:
$ grepc match_string .
./include/linux/string.h:int match_string(const char * const *array, size_t n, const char *string);
./lib/string_helpers.c:int match_string(const char * const *array, size_t n, const char *string)
{
int index;
const char *item;
for (index = 0; index < n; index++) {
item = array[index];
if (!item)
break;
if (!strcmp(item, string))
return index;
}
return -EINVAL;
}
You should be able to call it with a cast. It's dangerous, but
technically it works. I'm not encouraging it, though. :)
char **strings;
...
i = match_string((const char *const *) strings, n, "foo");
This is a historic problem in C, which was solved in C++. I have
a proposal paper for the C Committee for solving it as in C++:
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3987.htm>
This paper will be discussed (and probably voted in) in the next meeting
of the committee (which happens next week), so there's a chance that
this will be solved for C2y, and thus the cast will no longer be
necessary.
The history of why this is not allowed in C but is in C++ is, as far as
I've been told, the following:
Back before C and C++ were standardized, C++ invented const, with rules
slightly more allowing than what they are now. This was going to be
standardized first in C89. But very close to the release of C89, they
realized about the danger of converting a const char** to a char**
implicitly. They were so close to the release, that they opted for the
safest approach: disallow any non-trivial conversions.
Later, while standardizing C++98, they realized we could allow a few
more conversions safely, and so they did.
C could have taken advantage of that, and pick C++ rules in C99 or C11,
but for some reason, nobody proposed that. I'm proposing it now. :)
We've already discussed this proposal informally within the committee
for some a year and a half, and there seems to be consensus that we want
it. We're only being careful about the specific language. But I think
I finally got it, and it will go in next week.
Have a lovely day!
Alex
>
> Bart
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-11-10 11:10 UTC|newest]
Thread overview: 37+ 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-05 10:00 ` Sakari Ailus
2026-11-05 11:12 ` Alejandro Colomar
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 21:17 ` Andy Shevchenko
2026-11-09 11:16 ` Bartosz Golaszewski
2026-11-09 12:29 ` Alejandro Colomar
2026-11-09 12:59 ` Bartosz Golaszewski
2026-11-09 14:30 ` Alejandro Colomar
2026-11-09 14:53 ` Bartosz Golaszewski
2026-11-09 11:19 ` Bartosz Golaszewski
2026-11-04 14:03 ` [PATCH 5/9] of: property: implement the .property_get_names() fwnode operation Bartosz Golaszewski
2026-11-04 21:21 ` Andy Shevchenko
2026-11-09 13:07 ` Bartosz Golaszewski
2026-11-09 17:28 ` Andy Shevchenko
2026-11-10 9:00 ` Bartosz Golaszewski
2026-11-10 9:12 ` Andy Shevchenko
2026-11-10 9:50 ` Bartosz Golaszewski
2026-11-10 10:51 ` Andy Shevchenko
2026-11-10 11:33 ` Alejandro Colomar
2026-11-10 14:06 ` Bartosz Golaszewski
2026-11-10 14:23 ` Bartosz Golaszewski
2026-11-10 11:10 ` Alejandro Colomar [this message]
2026-11-10 11:13 ` Alejandro Colomar
2026-11-10 11:35 ` Alejandro Colomar
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 21:33 ` Andy Shevchenko
2026-11-05 6:28 ` kernel test robot
2026-11-05 7:34 ` 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=avL4LoCz2wc164zo@devuan \
--to=alx+linux-hardening@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=dakr@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=djrscally@gmail.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=hverkuil@kernel.org \
--cc=johan@kernel.org \
--cc=kees@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=lenb@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=saravanak@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
all inboxes | Powered by JetHome®