All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [PATCH 01/10] dtoc: add support to scan drivers
Date: Thu, 11 Jun 2020 10:44:40 -0600	[thread overview]
Message-ID: <CAPnjgZ3k2VnZpuqiAzWjeXHAYRz=dmkPX05PaFV4LBOyqaqrSA@mail.gmail.com> (raw)
In-Reply-To: <7bf6a08d-00eb-a6d8-ea4c-239ccf577169@collabora.com>

Hi Walter,

On Thu, 11 Jun 2020 at 10:15, Walter Lozano <walter.lozano@collabora.com> wrote:
>
> Hi Simon,
>
> On 8/6/20 12:49, Walter Lozano wrote:
> > Hi Simon,
> >
> > On 4/6/20 12:59, Simon Glass wrote:
> >> Hi Walter,
> >>
> >> On Fri, 29 May 2020 at 12:15, Walter Lozano
> >> <walter.lozano@collabora.com> wrote:
> >>> Currently dtoc scans dtbs to convert them to struct platdata and
> >>> to generate U_BOOT_DEVICE entries. These entries need to be filled
> >>> with the driver name, but at this moment the information used is the
> >>> compatible name present in the dtb. This causes that only nodes with
> >>> a compatible name that matches a driver name generate a working
> >>> entry.
> >>>
> >>> In order to improve this behaviour, this patch adds to dtoc the
> >>> capability of scan drivers source code to generate a list of valid
> >>> driver
> >>> names. This allows to rise a warning in the case that an U_BOOT_DEVICE
> >>> entry will try to use a name not valid.
> >>>
> >>> Additionally, in order to add more flexibility to the solution, adds
> >>> the
> >>> U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but
> >>> allows an
> >>> easy way to declare driver name aliases. Thanks to this, dtoc can look
> >>> for the driver name based on its alias when it populates the
> >>> U_BOOT_DEVICE
> >>> entry.
> >>>
> >>> Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
> >>> ---
> >>>   include/dm/device.h        |  7 ++++
> >>>   tools/dtoc/dtb_platdata.py | 83
> >>> ++++++++++++++++++++++++++++++++++++--
> >>>   2 files changed, 86 insertions(+), 4 deletions(-)
> >>>

[..]

> >>> +        """
> >>> +        compat_c, aliases_c = get_compat_name(node)
> >>> +        if compat_c not in self._drivers:
> >>> +            compat_c_old = compat_c
> >>> +            compat_c = self._driver_aliases.get(compat_c)
> >>> +            if not compat_c:
> >>> +                print('WARNING: the driver %s was not found in the
> >>> driver list' % (compat_c_old))
> >> This creates lots of warnings at present. Either we need a patch to
> >> clean up the differences in the source code, or we need to disable the
> >> warning.
> >
> >
> > Regarding this, maybe we should have a list of driver names we don't
> > expect to support, like simple_bus. For this to work probably the best
> > approach is to have a config option similar to CONFIG_OF_REMOVE_PROPS,
> > so each config can add their owns.
>
> I've been thinking about this issue, I think it would be better to only
> print the warning if build is issue with
>
> make V=1
>
> What do you think?

Can we not fix the warnings?

Regards,
Simon

  reply	other threads:[~2020-06-11 16:44 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 18:15 [PATCH 00/10] improve OF_PLATDATA support Walter Lozano
2020-05-29 18:15 ` [PATCH 01/10] dtoc: add support to scan drivers Walter Lozano
2020-06-04 15:59   ` Simon Glass
2020-06-08 15:49     ` Walter Lozano
2020-06-11 16:15       ` Walter Lozano
2020-06-11 16:44         ` Simon Glass [this message]
2020-06-11 16:45       ` Simon Glass
2020-06-11 17:11         ` Walter Lozano
2020-06-11 17:22           ` Simon Glass
2020-06-11 19:07             ` Walter Lozano
2020-06-12  2:22               ` Simon Glass
2020-06-12 17:38                 ` Walter Lozano
2020-06-16 13:43                   ` Simon Glass
2020-05-29 18:15 ` [PATCH 02/10] dtoc: add option to disable warnings Walter Lozano
2020-06-04 15:59   ` Simon Glass
2020-06-08 15:51     ` Walter Lozano
2020-05-29 18:15 ` [PATCH 03/10] dm: doc: update of-plat with the suppor for driver aliases Walter Lozano
2020-06-04 15:59   ` Simon Glass
2020-05-29 18:15 ` [PATCH 04/10] core: drop const for struct driver_info Walter Lozano
2020-06-04 15:59   ` Simon Glass
2020-05-29 18:15 ` [PATCH 05/10] core: extend struct driver_info to point to device Walter Lozano
2020-05-29 18:56   ` Walter Lozano
2020-05-29 19:00     ` Simon Glass
2020-05-29 19:20       ` Walter Lozano
2020-05-29 20:42         ` Simon Glass
2020-06-04 15:59   ` Simon Glass
2020-06-08 15:53     ` Walter Lozano
2020-05-29 18:15 ` [PATCH 06/10] dtoc: extend dtoc to use struct driver_info when linking nodes Walter Lozano
2020-06-04 15:59   ` Simon Glass
2020-05-29 18:15 ` [PATCH 07/10] dm: doc: update of-plat with new phandle support Walter Lozano
2020-06-04 15:59   ` Simon Glass
2020-06-08 15:54     ` Walter Lozano
2020-05-29 18:15 ` [PATCH 08/10] dtoc: update tests to match new platdata Walter Lozano
2020-06-04 15:59   ` Simon Glass
2020-05-29 18:15 ` [PATCH 09/10] dtoc: update dtb_platdata to support cd-gpios Walter Lozano
2020-06-04 15:59   ` Simon Glass
2020-06-08 16:01     ` Walter Lozano
2020-06-14  2:49       ` Simon Glass
2020-05-29 18:15 ` [PATCH 10/10] dtoc add test for cd-gpios Walter Lozano
2020-06-04 15:59   ` Simon Glass
2020-05-29 18:25 ` [PATCH 00/10] improve OF_PLATDATA support Jagan Teki
2020-05-29 19:15   ` Walter Lozano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPnjgZ3k2VnZpuqiAzWjeXHAYRz=dmkPX05PaFV4LBOyqaqrSA@mail.gmail.com' \
    --to=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.