[PATCH 1/1] lib: utils: identify supported GPIO reset methods

[Heinrich Schuchardt <heinrich.schuchardt@canonical.com>]

On 9/29/21 11:14, Nikita Shubin wrote:
> On Wed, 29 Sep 2021 09:46:55 +0530
> Anup Patel <anup@brainfault.org> wrote:
> 
>> +Nikita
>>
>> On Tue, Sep 28, 2021 at 5:13 PM Heinrich Schuchardt
>> <heinrich.schuchardt@canonical.com> wrote:
>>>
>>> The GPIO reset driver supports reset and poweroff. But not all
>>> boards support both. gpio_system_reset_check() must detect this
>>> situation.
>>>
>>> Signed-off-by: Heinrich Schuchardt
>>> <heinrich.schuchardt@canonical.com>
>>
>> Looks good to me.
>>
>> Reviewed-by: Anup Patel <anup.patel@wdc.com>
>>
>> I had mentioned on the PMIC reset series that we need to improve
>> the sbi_system.h device registration such that reset drivers can
>> register a reset device for a range of reset types. This will allow
>> separate reset drivers (e.g. PMIC+GPIO) for SiFive Unmatched.
>> Also, reset_check() callback will not be required anymore.
>>
>> Regards,
>> Anup
> 
> Looks good to me, however
> 
>>> +       /* hang !!! */
>>> +       sbi_hart_hang();
>>>   }
> 
> Heinrich do we really need to hang here ?
> 
> Despite the gpio_system_reset should never reach the end of function,
> i remember you talked something about returning from function back to
> the sbi_system_reset.

Thanks for reviewing.

As we are calling the check function before invoking the reset function 
this hang will only be running until the power supply is drained.

A calling function is defined as __no_return. Once we correct the whole 
reset driver framework as proposed by Anup we have to remove the 
sbi_hart_hang() here and in other drivers. We then need a small wait 
here and shall return SBI_EFAIL in the most improbable case.

Best regards

Heinrich