Re: [RFC v2 0/2] gpio: Support for shared GPIO lines on boards

[Grygorii Strashko]

On 05/11/2019 14:32, Peter Ujfalusi wrote:
> On 05/11/2019 14.15, Grygorii Strashko wrote:
> > On 05/11/2019 11:58, Linus Walleij wrote:
> > > On Mon, Nov 4, 2019 at 8:11 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote:
> > > > [Peter]
> > > > > The device needs the RST line to be high, otherwise it is not
> > > > > accessible. If it does not have reset control how can we make sure that
> > > > > the GPIO line is in correct state?
> > > >
> > > > Just like the reset code, drivers register their use of the reset and
> > > > the core tracks users and prevents resetting when not safe. Maybe the
> > > > reset subsystem needs to learn about GPIO resets. (...)
> > >
> > > I agree. Certainly the reset subsystem can do what the regulator
> > > subsystem is already doing: request the GPIO line nonexclusive
> > > and handle any reference counting and/or quirks that are needed
> > > in a hypothetical drivers/reset/reset-gpio.c driver.
> > >
> > > There is no such driver today, just a "reset" driver in
> > > drivers/power/reset that resets the whole system.
> > >
> > > But I see no problem in creating a proper reset driver in drivers/reset
> > > to handle a few peripherals with a shared GPIO reset line.
> >
> > Personally, I agree with Mark's comment here:
> >
> > > [Mark]
> > > The theory with that was that any usage of this would need the
> > > higher level code using the GPIO to cooperate so they didn't step
> > > on each other's toes so the GPIO code should just punt to it.
> > >
> > > > But let's say that a board design will pick two components (C1 and C2)
> > > > and use the same GPIO line to enable them. We already have the drivers
> > > > for them and they are used in boards already.
> > >
> > > This is basically an attempt to make a generic implementation of
> > > that cooperation for simple cases.
> >
> > This looks like unsolvable problem in generic way.
> > Lets assume there are some generic shared reset controller invented, but
> > then
> > - What if some driver is loaded/unloaded and corresponding device uses
> > shared
> >  Â reset which is de-asserted already?
> >  Â In this case, driver should never ever expect that target device has all
> >  Â registers in default state.
> > - What if reset is required as part of error recovery procedure? The
> > error recovery
> >  Â will not be supported by such design.
> > - PM: Device reset could be part of suspend/resume sequence. if one of
> > the devices
> >  Â is wake-up source, but other are not, those devices might be in very
> > unexpected state during resume.
> > - There could be dependencies on reset timings, shared reset might work for
> >  Â similar devices (like set of net phys) and does not work if connected
> > devices are different.
>
> and some driver shamelessly implements runtime power/reset control while
> other driver does not (they were never used on board where they had
> shared GPIO, probably power at most)
>
> > It seems, the only one case when it might help is system boot when:
> >  Â- similar devices are connected to the reset line
> >  Â- drivers are not expected to be re-loaded
> >  Â- device reset is not part of any recovery procedure
> >  Â- safe reset timings can be defined for all connected devices
> > (but hey - if this is boot only then gpio-hogs should work. Are they?)
>
> That is another thing which almost works ;)
> w/o gpio binding deferred probing is not possible if the GPIO controller
> is probed later.
> In some cases it might be even impossible to make sure that the GPIO
> controller would probe first (GPIO extender on different i2c bus than
> the user(s) of the gpio line)
> In some cases moving around nodes in DT might artificially make things
> work, but then someone compiles the expander as module, or some 'small'
> change in kernel and the probe order on the bus changes.
> I don't think it is a valid thing to have commits on the DT files
> saying: move the expander front/after the hog affected user since since
> Monday the probe order has changed. Then move it back two weeks later ;)

Ok. Above sounds like real problem. The implicit dependence is exist, but can't
be resolved if any driver depends on gpio-hog of some gpio-controller.
Probe deferring of gpio-controller will not lead to probe differing of dependent driver.

Question: will gpio-hog mechanism resolve your case if it works (and probe differing issues)?

--
Best regards,
grygorii