Hi Tom, On Fri, 26 Dec 2025 at 07:53, Tom Rini <[email protected]> wrote: > > On Wed, Dec 24, 2025 at 09:23:59AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 19 Dec 2025 at 13:21, Tom Rini <[email protected]> wrote: > > > > > > The devm alloc functions that we have may follow the Linux kernel model > > > where allocations are (almost always) automatically free()'d. However, > > > quite often we don't enable, in full U-Boot, the corresponding automatic > > > free. This in turn leads to memory leaks. Rather than manually tracking > > > allocations and implementing frees, rework things so that we follow > > > expectations now and enable the DEVRES functionality to manage frees. > > > > > > This turns DEVRES from a prompted symbol to a symbol that must be > > > select'd, and we now remove our non-managed alloc/free functions from > > > outside of xPL builds. > > > > Most of the time boards don't enable DM_DEVICE_REMOVE to save code > > size. > > I'm not talking about DM_DEVICE_REMOVE anywhere in this series.
Without that, devres_release_all() is never called. How are you expecting things to be freed? > > > We certainly don't unbind devices. A memory leak implies some > > sort of problem, but if we are booting the OS, all the memory is > > 'freed' by that process. > > > > What problem are you solving here? It is missing from your commit. > > The problem being solved is stated in the commit message. Can you elaborate a bit? I see a vague reference to memory leaks, but you should explain the problem. Are you trying to free memory before booting an OS? Are you worried about devices being repeatedly probed and removed, thus causing a memory leak within U-Boot? It's just too unclear. Depending on what you are trying to achieve, we should perhaps make DEVRES depend on DM_DEVICE_REMOVE Regards, Simon
