linux-kernel - Re: [PATCH RFC 1/3] reset: replace boolean parameters with flags parameter

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: <5500e3d44be69f5bc843e5b2159f6d0aead24ff9.camel@pengutronix.de>
Date: Wed, 26 Jun 2024 18:17:11 +0200
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Uwe Kleine-König <u.kleine-koenig@...libre.com>
Cc: Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>, Masami Hiramatsu
 <mhiramat@...nel.org>, Lad Prabhakar
 <prabhakar.mahadev-lad.rj@...renesas.com>,  Geert Uytterhoeven
 <geert+renesas@...der.be>, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org,  kernel@...gutronix.de
Subject: Re: [PATCH RFC 1/3] reset: replace boolean parameters with flags
 parameter

Hi Uwe,

On Sa, 2024-06-22 at 09:47 +0200, Uwe Kleine-König wrote:
> Hello Philipp,
> 
> I like the idea in general. Just a detail concern down below.

Thank you, much appreciated.

> On Fri, Jun 21, 2024 at 04:45:02PM +0200, Philipp Zabel wrote:
> > @@ -999,8 +1001,9 @@ static struct reset_controller_dev *__reset_find_rcdev(const struct of_phandle_a
> >  
> >  struct reset_control *
> >  __of_reset_control_get(struct device_node *node, const char *id, int index,
> > -		       bool shared, bool optional, bool acquired)
> > +		       enum reset_control_flags flags)
> >  {
> > +	bool optional = flags & RESET_CONTROL_FLAGS_BIT_OPTIONAL;
> >  	bool gpio_fallback = false;
> >  	struct reset_control *rstc;
> >  	struct reset_controller_dev *rcdev;
> > @@ -1065,7 +1068,7 @@ __of_reset_control_get(struct device_node *node, const char *id, int index,
> >  	}
> >  
> >  	/* reset_list_mutex also protects the rcdev's reset_control list */
> > -	rstc = __reset_control_get_internal(rcdev, rstc_id, shared, acquired);
> > +	rstc = __reset_control_get_internal(rcdev, rstc_id, flags);
> 
> If RESET_CONTROL_FLAGS_BIT_OPTIONAL was passed to
> __of_reset_control_get(), you're forwarding it to
> __reset_control_get_internal(). But the latter doesn't do anything with
> that flag. I wonder if the API would be still less prone to error if
> you'd filter out RESET_CONTROL_FLAGS_BIT_OPTIONAL before passing to
> __reset_control_get_internal() and in __reset_control_get_internal() add
> a check for unsupported flags.

Yes, I'll do that. For every enum value with the optional bit set,
there is a corresponding value without it.

> >  out_unlock:
> >  	mutex_unlock(&reset_list_mutex);
> > @@ -1096,8 +1099,9 @@ __reset_controller_by_name(const char *name)
> >  
> >  static struct reset_control *
> >  __reset_control_get_from_lookup(struct device *dev, const char *con_id,
> > -				bool shared, bool optional, bool acquired)
> > +				enum reset_control_flags flags)
> >  {
> > +	bool optional = flags & RESET_CONTROL_FLAGS_BIT_OPTIONAL;
> >  	const struct reset_control_lookup *lookup;
> >  	struct reset_controller_dev *rcdev;
> >  	const char *dev_id = dev_name(dev);
> > [...]
> > @@ -1422,7 +1423,7 @@ EXPORT_SYMBOL_GPL(of_reset_control_array_get);
> >   * Returns pointer to allocated reset_control on success or error on failure
> >   */
> >  struct reset_control *
> > -devm_reset_control_array_get(struct device *dev, bool shared, bool optional)
> > +devm_reset_control_array_get(struct device *dev, enum reset_control_flags flags)
> >  {
> >  	struct reset_control **ptr, *rstc;
> >  
> > @@ -1431,7 +1432,7 @@ devm_reset_control_array_get(struct device *dev, bool shared, bool optional)
> >  	if (!ptr)
> >  		return ERR_PTR(-ENOMEM);
> >  
> > -	rstc = of_reset_control_array_get(dev->of_node, shared, optional, true);
> > +	rstc = of_reset_control_array_get(dev->of_node, flags);
> 
> Is it an error if the new devm_reset_control_array_get() is called
> without RESET_CONTROL_FLAGS_BIT_ACQUIRED in flags?

I'd be inclined to consider this not-an-error.

There is one user of of_reset_control_array_get_exclusive_released(),
so it should work in theory. Of course nobody is using both devres and
the acquire/release API at the same time, and there is no
devm_reset_control_array_get_exclusive_released() wrapper.

regards
Philipp