Nouveau - Jul 2017 - [PATCH 000/102] Convert drivers to explicit reset API

Hello,

On Wed, 19 Jul 2017 17:25:04 +0200, Philipp Zabel wrote:
> The reset control API has two modes: exclusive access, where the driver
> expects to have full and immediate control over the state of the reset
> line, and shared (clock-like) access, where drivers only request reset
> deassertion while active, but don't care about the state of the reset
line
> while inactive.
> 
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when
requesting
> reset lines") started to transition the reset control request API
calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior.
> 
> This series converts all drivers that currently implicitly request
> exclusive reset controls to the corresponding explicit API call. It is,
> for the most part, generated from the following semantic patch:
> 
> @@
> expression rstc, dev, id;
> @@
> -rstc = reset_control_get(dev, id);
> +rstc = reset_control_get_exclusive(dev, id);
I don't know if it has been discussed in the past, so forgive me if it
has been. Have you considered adding a "int flags" argument to the
existing reset_control_get_*() functions, rather than introducing
separate exclusive variants ?

Indeed, with a "int flags" argument you could in the future add more
variants/behaviors without actually multiplying the number of
functions. Something like the "flags" argument for request_irq() for
example.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Hello,

On Thu, 20 Jul 2017 11:36:55 +0200, Philipp Zabel wrote:
> > I don't know if it has been discussed in the past, so forgive me
if it
> > has been. Have you considered adding a "int flags" argument
to the
> > existing reset_control_get_*() functions, rather than introducing
> > separate exclusive variants ?
> > 
> > Indeed, with a "int flags" argument you could in the future
add more
> > variants/behaviors without actually multiplying the number of
> > functions. Something like the "flags" argument for
request_irq() for
> > example.  
> 
> I can't find the discussion right now, but I remember we had talked
> about this in the past.
> Behind the scenes, all the inline API functions already call common
> entry points with flags (well, currently separate bool parameters for
> shared and optional).
> One reason against exposing those as an int flags in the user facing API
> is the possibility to accidentally provide a wrong value.
This is a quite strange argument. You could also accidentally use the
wrong variant of the function, just like you could use the wrong flag.

Once again, the next time you have another parameter for those reset
functions, beyond the exclusive/shared variant, you will multiply again
by two the number of functions ? You already have the  exclusive/shared
and optional/mandatory variants, so 4 variants. When you'll add a new
parameter, you'll have 8 variants. Doesn't seem really good.

What about reset_control_get(struct device *, const char *, int flags)
to replace all those variants ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com