lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqJjo1SBcf=ZLi=iunaHiX6Mt5H6wkoPcecnZmiAcAyihw@mail.gmail.com>
Date: Tue, 5 Mar 2024 11:56:04 -0600
From: Rob Herring <robh+dt@...nel.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Frank Rowand <frowand.list@...il.com>, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH] of: make for_each_property_of_node() available to to !OF

On Tue, Mar 5, 2024 at 2:32 AM Geert Uytterhoeven <geert@...ux-m68korg> wrote:
>
> Hi Bartosz,
>
> On Sun, Mar 3, 2024 at 11:49 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> >
> > for_each_property_of_node() is a macro and so doesn't have a stub inline
> > function for !OF. Move it out of the relevant #ifdef to make it available
> > to all users.
>
> Thanks for your patch, which is now commit ad8ee969d7e34dd3 ("of: make
> for_each_property_of_node() available to to !OF") in dt-rh/for-next
>
> > Fixes: 611cad720148 ("dt: add of_alias_scan and of_alias_get_id")
>
> How is this related?
>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> > ---
> > I have an upcoming driver that will use this but which can also be built
> > on non-DT systems. I'd like to get that in as a fix to avoid inter-tree
> > dependencies later.
>
> Do you have a link?
>
> > --- a/include/linux/of.h
> > +++ b/include/linux/of.h
> > @@ -362,9 +362,6 @@ extern struct device_node *of_get_cpu_state_node(struct device_node *cpu_node,
> >                                                  int index);
> >  extern u64 of_get_cpu_hwid(struct device_node *cpun, unsigned int thread);
> >
> > -#define for_each_property_of_node(dn, pp) \
> > -       for (pp = dn->properties; pp != NULL; pp = pp->next)
> > -
> >  extern int of_n_addr_cells(struct device_node *np);
> >  extern int of_n_size_cells(struct device_node *np);
> >  extern const struct of_device_id *of_match_node(
> > @@ -892,6 +889,9 @@ static inline int of_prop_val_eq(struct property *p1, struct property *p2)
> >                !memcmp(p1->value, p2->value, (size_t)p1->length);
> >  }
> >
> > +#define for_each_property_of_node(dn, pp) \
> > +       for (pp = dn->properties; pp != NULL; pp = pp->next)
>
> Is this safe if !OF? Can dn be NULL?

Good point. I would say running code shouldn't reach this though.
Also, it should be written in a way it gets optimized away if !OF is
valid.

Long term, I want to make struct device_node opaque. So if we really
want to fix this, I think we'd want to convert this to use an iterator
function. Though I guess any user would be mucking with struct
property too, so the whole loop would need to be reworked. So in
conclusion, don't use for_each_property_of_node(). :) Shrug.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ