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

Simon Goldschmidt simon.k.r.goldschmidt at gmail.com
Tue Nov 5 16:42:13 UTC 2019


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


Regards,
Simon


More information about the U-Boot mailing list