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 <jjhib...@ti.com> wrote:


On 30/10/2019 02:48, Simon Glass wrote:
On Mon, 30 Sep 2019 at 10:15, Jean-Jacques Hiblot <jjhib...@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 <jjhib...@ti.com>
---

   drivers/reset/reset-uclass.c | 116 +++++++++++++++++++++++++++++-
   include/reset.h              | 135 ++++++++++++++++++++++++++++++++++-
   2 files changed, 247 insertions(+), 4 deletions(-)
Reviewed-by: Simon Glass <s...@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

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to