[U-Boot] [PATCH v3 2/5] devres: introduce Devres (Managed Device Resource) framework

[Masahiro Yamada]

2015-07-24 8:20 GMT+09:00 Simon Glass <sjg at chromium.org>:
> Hi Masahiro,
>
> On 23 July 2015 at 00:17, Masahiro Yamada <yamada.masahiro at socionext.com> wrote:
>> In U-Boot's driver model, memory is basically allocated and freed
>> in the core framework.  So, low level drivers generally only have
>> to specify the size of needed memory with .priv_auto_alloc_size,
>> .platdata_auto_alloc_size, etc.  Nevertheless, some drivers still
>> need to allocate/free memory on their own in case they cannot
>> statically know the necessary memory size.  So, I believe it is
>> reasonable enough to port Devres into U-boot.
>>
>> Devres, which originates in Linux, manages device resources for each
>> device and automatically releases them on driver detach.  With devres,
>> device resources are guaranteed to be freed whether initialization
>> fails half-way or the device gets detached.
>>
>> The basic idea is totally the same to that of Linux, but I tweaked
>> it a bit so that it fits in U-Boot's driver model.
>>
>> In U-Boot, drivers are activated in two steps: binding and probing.
>> Binding puts a driver and a device together.  It is just data
>> manipulation on the system memory, so nothing has happened on the
>> hardware device at this moment.  When the device is really used, it
>> is probed.  Probing initializes the real hardware device to make it
>> really ready for use.
>>
>> So, the resources acquired during the probing process must be freed
>> when the device is removed.  Likewise, what has been allocated in
>> binding should be released when the device is unbound.  The struct
>> devres has a member "probe" to remember when the resource was
>> allocated.
>>
>> CONFIG_DEBUG_DEVRES is also supported for easier debugging.
>> If enabled, debug messages are printed each time a resource is
>> allocated/freed.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
>> ---



>
> Please can you add comments for these fields? I'm not sure what
> dr_release_t is for, for exable.


OK, I commented this structure in v4.

The dr_release_t is a callback that is automatically invoked
when the resource is freed.

This callback should do the opposite action to the allocator.

For example,
devm_ioremap() calls iounmap() in the release callback,
devm_clk_get() calls clk_put() in the release callback, etc.



>> +struct devres {
>> +       struct list_head                entry;
>> +       dr_release_t                    release;
>> +       bool                            probe;
>> +#ifdef CONFIG_DEBUG_DEVRES
>> +       const char                      *name;
>> +       size_t                          size;
>> +#endif
>> +       unsigned long long              data[];
>> +};
>> +
>> +
>> +static void release_nodes(struct udevice *dev, struct list_head *head,
>> +                         bool probe_only)
>> +{
>> +       struct devres *dr, *tmp;
>> +
>> +       list_for_each_entry_safe_reverse(dr, tmp, head, entry)  {
>> +               if (probe_only && !dr->probe)
>> +                       break;
>> +               devres_log(dev, dr, "REL");
>> +               dr->release(dev, dr->data);
>
> Somewhere in the header file can you please explain the use case for
> the release() method?

I explained above, but I am not sure if it should be explained in the
header file.
Such a thing is generally explained in a README.
Uh, I am too laze to write a README...

But you can find one in Linux: Documentation/driver-modeol/devres.txt

And, use cases are everywhere in the kernel code.





-- 
Best Regards
Masahiro Yamada