[PATCH v3 04/12] dm: Introduce xxx_get_dma_range()

[Simon Glass]

Hi Nicolas,

On Mon, 21 Dec 2020 at 06:03, Nicolas Saenz Julienne
<nsaenzjulienne at 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
> > <nsaenzjulienne at 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 <nsaenzjulienne at 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 <sjg at 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