[U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT

[Jean-Jacques Hiblot]

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 <jjhiblot at ti.com> 
>> wrote:
>>>
>>>
>>> On 30/10/2019 02:48, Simon Glass wrote:
>>>> On Mon, 30 Sep 2019 at 10:15, Jean-Jacques Hiblot <jjhiblot at ti.com> 
>>>> 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 <jjhiblot at ti.com>
>>>>> ---
>>>>>
>>>>>    drivers/reset/reset-uclass.c | 116 +++++++++++++++++++++++++++++-
>>>>>    include/reset.h              | 135 
>>>>> ++++++++++++++++++++++++++++++++++-
>>>>>    2 files changed, 247 insertions(+), 4 deletions(-)
>>>> Reviewed-by: Simon Glass <sjg at chromium.org>
>>>>
>>>> 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
>