From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Tue, 5 Nov 2019 17:42:13 +0100 Subject: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT In-Reply-To: References: <20190930142449.4480-1-jjhiblot@ti.com> <20190930142449.4480-3-jjhiblot@ti.com> <95004f08-a9df-a85b-c500-0d0660a0b7f7@ti.com> Message-ID: <02834d03-dbe5-8b92-8ff4-b1b0b9cd5c4c@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 05.11.2019 um 17:33 schrieb Simon Glass: > Hi Jean-Jacques, > > On Mon, 4 Nov 2019 at 08:41, Jean-Jacques Hiblot wrote: >> >> >> On 30/10/2019 02:48, Simon Glass wrote: >>> On Mon, 30 Sep 2019 at 10:15, Jean-Jacques Hiblot wrote: >>>> Add managed functions to get a reset_ctl from the device-tree, based on a >>>> name or an index. >>>> Also add a managed functions to get a reset_ctl_bulk (array of reset_ctl) >>>> from the device-tree. >>>> >>>> When the device is unbound, the reset controllers are automatically >>>> released and the data structure is freed. >>>> >>>> Signed-off-by: Jean-Jacques Hiblot >>>> --- >>>> >>>> drivers/reset/reset-uclass.c | 116 +++++++++++++++++++++++++++++- >>>> include/reset.h | 135 ++++++++++++++++++++++++++++++++++- >>>> 2 files changed, 247 insertions(+), 4 deletions(-) >>> Reviewed-by: Simon Glass >>> >>> I really don't like these ERR_PTR returns. I suppose they make the >>> code easier to port, and we can be sure that pointers will not be in >>> the last 4KB of address space? >> >> It seems rather unlikely because the returned pointer points to actual >> RAM allocated from the heap. On most platforms I've worked with, the top >> of the address space is not dedicated to memory. Most != all: on socfpga, the internal SRAM is at the end of the address spcae. In SPL, this means the last 4K cannot be used. However, that shouldn't keep us from porting ERR_PTR returns from Linux code. > > Yes that's my comfort. > >> If ever the need to fix >> this arises it could done by tweaking the macros to use another unused >> address space. > > Not easily without doing something platform-specific, as someone else > is currently pushing. That "someone else" would be me. Sadly, I did not get any response: https://patchwork.ozlabs.org/project/uboot/list/?series=137880 Regards, Simon