[RFC 3/4] dtoc: add support for generate stuct udevice_id

[Simon Glass]

Hi Walter,

On Tue, 7 Jul 2020 at 08:08, Walter Lozano <walter.lozano at collabora.com> wrote:
>
> Hi Simon
>
> On 6/7/20 16:21, Simon Glass wrote:
> > Hi Walter,
> >
> > On Fri, 19 Jun 2020 at 15:12, Walter Lozano <walter.lozano at collabora.com> wrote:
> >> Based on several reports there is an increasing concern in the impact
> >> of adding additional features to drivers based on compatible strings.
> >> A good example of this situation is found in [1].
> >>
> >> In order to reduce this impact and as an initial step for further
> >> reduction, propose a new way to declare compatible strings, which allows
> >> to only include the useful ones.
> > What are the useful ones?
>
> The useful ones would be those that are used by the selected DTB by the
> current configuration. The idea of this patch is to declare all the
> possible compatible strings in a way that dtoc can generate code for
> only those which are going to be used, and in this way avoid lots of
> #ifdef like the ones shows in
>
> http://patchwork.ozlabs.org/project/uboot/patch/20200525202429.2146-1-agust@denx.de/
>
>
> >> The idea is to define compatible strings in a way to be easily parsed by
> >> dtoc, which will be responsible to build struct udevice_id [] based on
> >> the compatible strings present in the dtb.
> >>
> >> Additional features can be easily added, such as define constants
> >> depending on the presence of compatible strings, which allows to enable
> >> code blocks only in such cases without the need of adding additional
> >> configuration options.
> >>
> >> [1] http://patchwork.ozlabs.org/project/uboot/patch/20200525202429.2146-1-agust@denx.de/
> >>
> >> Signed-off-by: Walter Lozano <walter.lozano at collabora.com>
> >> ---
> >>   tools/dtoc/dtb_platdata.py | 32 ++++++++++++++++++++++++++++++++
> >>   1 file changed, 32 insertions(+)
> > I think dtoc should be able to parse the compatible strings as they
> > are today - e.g. see the tiny-dm stuff.
>
>
> Yes, I agree. My idea is that dtoc parses compatible strings as they are
> today but also in this new way. The reason for this is to allow dtoc to
> generate the code to include the useful compatible strings. Of course,
> this only makes sense if the idea of generating the compatible string
> associated  code is accepted.
>
> What do you think?

I think this is useful and better than using #ifdef in the source code
for this sort of thing. We need a way to specify the driver_data value
as well, right?

Re naming, perhaps DT_COMPAT() might be better than COMPATIBLE()? Or
even a name that indicates that it is optional, like DT_OPT_COMPAT() ?

Regards,
Simon