From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Jacques Hiblot Date: Tue, 5 Nov 2019 18:27:49 +0100 Subject: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT In-Reply-To: <02834d03-dbe5-8b92-8ff4-b1b0b9cd5c4c@gmail.com> References: <20190930142449.4480-1-jjhiblot@ti.com> <20190930142449.4480-3-jjhiblot@ti.com> <95004f08-a9df-a85b-c500-0d0660a0b7f7@ti.com> <02834d03-dbe5-8b92-8ff4-b1b0b9cd5c4c@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On 05/11/2019 17:42, Simon Goldschmidt wrote: > 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 Alternatively we could use BIT(0) to flag an error since allocations are always aligned on 4 or more (sizeof(ulong) or 2*sizeof(size_t)) > > > Regards, > Simon >