Re: difference between fdtdec and fdt_support ?

["Marek Behún" <marek.behun@nic.cz>]

On Thu, 6 Jan 2022 08:48:48 -0700
Simon Glass <sjg@chromium.org> wrote:

> Hi Marek,
> 
> On Thu, 6 Jan 2022 at 05:21, Marek Behún <marek.behun@nic.cz> wrote:
> >
> > Hi Simon,
> >
> > I am a little confused.
> >
> > We have
> >   common/fdt_support.c
> > and
> >   lib/fdtdec.c
> >
> > The second one implements for example fdtdec_get_is_enabled(), which I
> > would rather expect in fdt_support by name fdt_node_is_available(), or
> > something like that.  
> 
> Should be moved to ofnode

?? But this function is needed for example when fixing device tree for
Linux.

> >
> > Also fdtdec does a strange thing with compatible strings: it declares
> > an enum for compatible strings and then a map which maps this enum
> > values to compatible strings... Why not just use the compatible strings?  
> 
> Did you see the comment?
> 
>  * NOTE: This list is basically a TODO list for things that need to be
>  * converted to driver model. So don't add new things here unless there is a
>  * good reason why driver-model conversion is infeasible. Examples include
>  * things which are used before driver model is available.
> 
> This is effectively a list of things that should be converted to
> driver model. The list should then go away.

Hmm. But can't that be simply made into a list in a comment? Because
currently this is compiled in for every board that uses any such
function from fdtdec, even if they don't use any string from those
compatible strings.

> >
> > What is the purpose of having two files implementing fdt stuff?  
> 
> fdtdec - for reading from the DT. Should go away and be replaced with
> the ofnode API, and fdtaddr.c
> fdt_support - for updating the DT, e.g. for fixups before booting an OS

Thanks! Okay that makes sense. This means that we should also have
fdt_node_is_available() in fdt_support.c which does the same thing.
(For now this can be made a static inline function that calls
 fdtdec_get_is_enabled().)

Marek