Hi Nicolas, On Mon, 21 Dec 2020 at 06:03, Nicolas Saenz Julienne <nsaenzjulie...@suse.de> wrote: > > Hi Simon, thanks for the review. > > On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote: > > Hi Nicolas, > > > > On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne > > <nsaenzjulie...@suse.de> wrote: > > > > > > Add the following functions to get a specific device's DMA ranges: > > > - dev_get_dma_range() > > > - ofnode_get_dma_range() > > > - of_get_dma_range() > > > - fdt_get_dma_range() > > > They are specially useful in oder to be able validate a physical address > > > space range into a bus's and to convert addresses from and to address > > > spaces. > > > > > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulie...@suse.de> > > > > > > --- > > > Changes since v2: > > > - Return ENOENT instead of ENODEV > > > - Refcount OF nodes > > > > > > Changes since v1: > > > - Fix wrong arguments in of_get_dma_range()'s call to > > > of_translate_dma_address() > > > - Fix build in SPL/TPL and no LIBFDT supprt > > > - Add missing declaration in 'core/read.c' > > > - Address Matthias' comments > > > > > > common/fdt_support.c | 73 +++++++++++++++++++++++++++++++++++++++ > > > drivers/core/of_addr.c | 78 ++++++++++++++++++++++++++++++++++++++++++ > > > drivers/core/ofnode.c | 9 +++++ > > > drivers/core/read.c | 6 ++++ > > > include/dm/of_addr.h | 17 +++++++++ > > > include/dm/ofnode.h | 16 +++++++++ > > > include/dm/read.h | 21 ++++++++++++ > > > include/fdt_support.h | 14 ++++++++ > > > 8 files changed, 234 insertions(+) > > > > Reviewed-by: Simon Glass <s...@chromium.org> > > > > I don't suppose it is worth writing a version that uses the ofnode API > > and thus reduce code size? Probably not since if livetree is enabled, > > I doubt we would ever call the flattree one. Also it is nice to have > > the same livetree code as Linux, where possible. > > As far as the logic is concerned we'd be able to mimic what linux does so it > shouldn't be a problem. > > But I'd be forced to port low level DT code to ofnode. Notably > 'of_match_bus()' > and 'struct of_bus', which IMO have no place in ofnode: it seems to me that > ofnode is an abstraction geared towards simplifying DT consumers. This > wouldn't > provide much benefit to them, with the downside of divering from upstream > Linux's implementation.
Yes that sounds right to me, thanks. Regards, Simon
