[U-Boot] [PATCH v2 00/14] Devres (Managed Device Resource) for U-Boot

[Albert ARIBAUD]

Hello Masahiro,

On Mon, 13 Jul 2015 13:17:03 +0900, Masahiro Yamada
<yamada.masahiro at socionext.com> wrote:
> 
> Please refer to the commit message of 06/14
> for what this series wants to do.

Remark: you could use "Series-notes:" in 6/14 to have patman directly
include said notes here instead of referring the reader to the patch.

> Masahiro Yamada (14):
>   x86: delete unneeded declarations of disable_irq() and enable_irq()
>   linux_compat: remove cpu_relax() define
>   linux_compat: move vzalloc() to header file as an inline function
>   linux_compat: handle __GFP_ZERO in kmalloc()
>   dm: add DM_FLAG_BOUND flag
>   devres: introduce Devres (Managed Device Resource) framework
>   devres: add devm_kmalloc() and friends (managed memory allocators)
>   dm: refactor device_bind() and device_unbind() with devm_kzalloc()
>   dm: merge fail_alloc labels
>   linux_compat: introduce GFP_DMA flag for kmalloc()
>   dm: refactor device_probe() and device_remove() with devm_kzalloc()
>   devres: add debug command to dump device resources
>   dm: remove redundant CONFIG_DM from driver/core/Makefile
>   devres: compile Devres iif CONFIG_DM_DEVICE_REMOVE is enabled

I am still unsure why this is necessary. I had a discussion on the
list with Simon, see last message here:

<https://www.mail-archive.com/u-boot@lists.denx.de/msg177031.html>

Unless I'm mistaken, the only case where we actually have a leak that
this series would fix is in some cases of binding USB devices / drivers
multiple times, and even then, it would take a considerable amount of
repeated bindings before U-Boot could become unable to boot a payload;
a scenario that I find unlikely.

I do understand the general goal of fixing bugs when we ind them; but I
question the global benefit of fixing this specific leak bug by adding a
whole new feature with a lot of code to U-Boot, as opposed to fixing
it in a more ad hoc way with much less less code volume and complexity.

Amicalement,
-- 
Albert.