[PATCH 2/2] lib: utils: support both of gpio-poweroff, gpio-reset

[Jessica Clarke]

On 23 Jul 2021, at 00:00, Jessica Clarke <jrtc27 at jrtc27.com> wrote:
> 
> On 22 Jul 2021, at 23:46, Heinrich Schuchardt <heinrich.schuchardt at canonical.com> wrote:
>> 
>> 
>> 
>> On 7/22/21 9:33 PM, Jessica Clarke wrote:
>>> On 22 Jul 2021, at 11:53, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>>> 
>>>> The generic GPIO reset driver has two entries in the match table:
>>>> "gpio-poweroff", "gpio-reset". Only the first entry is considered by
>>>> fdt_reset_init().
>>> This is inaccurate. fdt_reset_init does consider all entries in turn.
>>> The problem is that OpenSBI’s driver attachment is backwards from
>>> normal operating systems. Normal operating systems will iterate over
>>> all devices, and for each device will iterate over all drivers trying
>>> to find the best one, if any. This means multiple instances of the same
>>> driver (including for very different compatible strings) can exist. In
>>> OpenSBI, however, this is turned on its head, with it iterating over
>>> all drivers, trying to find a device that each driver can attach to.
>>> This means multiple instances of the same driver cannot exist, so
>>> whichever of gpio-poweroff and gpio-reset appears in the device tree
>>> first is the one that gets attached to. Splitting the two sets of
>>> functionality out into their own drivers therefore works around this
>>> limitation, though arguably it would be better to alter OpenSBI to
>>> follow a normal driver attachment process as I’m sure this will come up
>>> again eventually.
>>> Jess
>> Hello Jess,
>> 
>> Thanks for taking the discussion to the overall design.
>> 
>> The same logic as in fdt_reset_init() is used in:
>> 
>> * fdt_serial_init() - lib/utils/serial/fdt_serial.c
>> * fdt_ipi_cold_init() - lib/utils/ipi/fdt_ipi.c
>> * fdt_irqchip_cold_init() - lib/utils/irqchip/fdt_irqchip.c
>> * fdt_timer_cold_init() - lib/utils/timer/fdt_timer.c
> 
> Yeah, this was indeed meant to be a general statement about all the device driver classes.
> 
>> Should we first merge this patch and then start to rework the whole driver binding process or would you suggest to apply only patch 1 of the series and do the redesign first?
> 
> Yes, I think given the importance of the functionality your patch adds I think it’s best to merge that and then think about a more robust design for OpenSBI.

(though with the commit message rewritten since as it stands it is rather incorrect)

Jess