From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
Date: Mon, 13 Jul 2015 08:51:58 +0200
Subject: [U-Boot] [PATCH v2 00/14] Devres (Managed Device Resource) for
 U-Boot
In-Reply-To: <1436761037-19635-1-git-send-email-yamada.masahiro@socionext.com>
References: <1436761037-19635-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20150713085158.568a05dd@lilith>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hello Masahiro,

On Mon, 13 Jul 2015 13:17:03 +0900, Masahiro Yamada
<yamada.masahiro@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.