search for: reset_control_get

...t;> >> 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 >> >...

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 "fl...

...wrote: > 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. So...

On Thu, Jul 20, 2017 at 10:46 PM, Dmitry Torokhov <dmitry.torokhov at gmail.com> wrote: > On Thu, Jul 20, 2017 at 5:55 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote: >>> What about reset_control_get(struct device *, const char *, int flags) >>> to replace all those variants ? >> >> While I like how this looks, unfortunately (devm_)reset_control_get >> already exists without the flags, so we can't change to that with a >> gentle transition. > > This wa...

On Sun, 2017-07-23 at 20:41 +0200, Linus Walleij wrote: > On Thu, Jul 20, 2017 at 10:46 PM, Dmitry Torokhov > <dmitry.torokhov at gmail.com> wrote: > > On Thu, Jul 20, 2017 at 5:55 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote: > > >>> What about reset_control_get(struct device *, const char *, int flags) > >>> to replace all those variants ? > >> > >> While I like how this looks, unfortunately (devm_)reset_control_get > >> already exists without the flags, so we can't change to that with a > >> gentle tran...

...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...

...iver 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); @@ expression rstc, dev, id; @@ -rstc = reset_control_get_optional(dev, id); +rstc = reset_control_get_optional_exclusive(dev, id); @@ expression rstc, node, id; @@ -rstc = of_reset_control_get(node, id); +rstc = of_reset_control_get_exclusive...

...st part, generated from the following semantic patch: Hey, I'm all for large api changes, but this really seems ackward, isn't there a "better" way to do this? Why not, as you say the "implicit" request is exclusive, just leave everything alone and state that the "reset_control_get()" call is exclusive and make the shared one the "odd" usage as that seems to not be the normal case. That should be a much smaller patch right? That way you don't break everything here, and require 100+ patches to just change the name of a function from one to another and do n...

...nverts 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 introd...

...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); > @@ > expression rstc, dev, id; > @@ > -rstc = reset_control_get_optional(dev, id); > +rstc = reset_control_get_optional_exclusive(dev, id); > @@ > expression rstc, node, id; > @@ > -rstc = of_reset_control_get...