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
