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

[Grygorii Strashko <grygorii.strashko@ti.com>]

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@kernel.org> 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