Re: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT
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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT
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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT
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. 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. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT
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. If ever the need to fix this arises it could done by tweaking the macros to use another unused address space. JJ Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT
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? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
