Hi Walter, On Tue, 7 Jul 2020 at 08:08, Walter Lozano <walter.loz...@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.loz...@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-ag...@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-ag...@denx.de/ > >> > >> Signed-off-by: Walter Lozano <walter.loz...@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
