Re: [PATCH 5/9] of: property: implement the .property_get_names() fwnode operation

[Bartosz Golaszewski]

On Tue, Nov 10, 2026 at 10:50:57AM +0100, Bartosz Golaszewski wrote:
> On Tue, Nov 10, 2026 at 11:12:02AM +0200, Andy Shevchenko wrote:
> > On Tue, Nov 10, 2026 at 11:00 AM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
> > > On Mon, Nov 09, 2026 at 07:28:33PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Nov 09, 2026 at 02:07:46PM +0100, Bartosz Golaszewski wrote:
> > > > > On Wed, Nov 04, 2026 at 11:21:15PM +0200, Andy Shevchenko wrote:
> > > > > > On Wed, Nov 04, 2026 at 03:03:47PM +0100, Bartosz Golaszewski wrote:
> > 
> > ...
> > 
> > > > > > > +               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.
> > 
> > I believe I misput my question. If there is any potential that *some*
> > of fwnodes use statically defined string literals for the property
> > name? If so, kstrdup_const() and friends may be a better choice here
> > to save some memory (which is getting more and more expensive these
> > days :-).
> >
> 
> Ah, that makes more sense. I'll look into it.
>

So I believe it doesn't make sense to address it just yet. OF nodes are
created dynamically. We could potentially make use of it for software
nodes but let's cross that bridge when we get there. That would require
making kfree_strarray() const-aware and use kfree_const() for the member
strings.

Bart