Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-24 Thread Philipp Zabel
On Sun, 2017-07-23 at 20:41 +0200, Linus Walleij wrote: > On Thu, Jul 20, 2017 at 10:46 PM, Dmitry Torokhov > wrote: > > On Thu, Jul 20, 2017 at 5:55 AM, Philipp Zabel > > wrote: > > >>> What about reset_control_get(struct device *, const char *, int flags) > >>> to replace all those variants ?

Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-23 Thread Linus Walleij
On Thu, Jul 20, 2017 at 10:46 PM, Dmitry Torokhov wrote: > On Thu, Jul 20, 2017 at 5:55 AM, Philipp Zabel 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_ge

Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-21 Thread Maxime Ripard
On Wed, Jul 19, 2017 at 05:25:04PM +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 wh

Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-21 Thread Thomas Petazzoni
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

Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-21 Thread Dmitry Torokhov
On Thu, Jul 20, 2017 at 5:55 AM, Philipp Zabel wrote: > Hi Thomas, > > On Thu, 2017-07-20 at 12:36 +0200, Thomas Petazzoni 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 bee

Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-21 Thread Greg Kroah-Hartman
On Wed, Jul 19, 2017 at 05:25:04PM +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 wh

Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-21 Thread Philipp Zabel
Hi Greg, The patches in this series are completely independent of each other, and I would like the subsystem maintainers to apply them at their own leisure. Well, except for the last one, which I will apply only after there are no more users of the transition helpers. On Thu, 2017-07-20 at 10:11

[PATCH 000/102] Convert drivers to explicit reset API

2017-07-21 Thread Philipp Zabel
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 inac

Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-21 Thread Thomas Petazzoni
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 excl

Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-21 Thread Philipp Zabel
Hi Thomas, On Wed, 2017-07-19 at 21:15 +0200, Thomas Petazzoni wrote: > 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 > > li

Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-21 Thread Philipp Zabel
Hi Thomas, On Thu, 2017-07-20 at 12:36 +0200, Thomas Petazzoni 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 > >