[PATCH 6/9] dm: core: Support accessing core tags

[Simon Glass]

Hi Takahiro,

On Tue, 5 Jul 2022 at 19:27, AKASHI Takahiro <takahiro.akashi at linaro.org> wrote:
>
> Hi Simon,
>
> On Tue, Jul 05, 2022 at 02:27:54PM +0100, Simon Glass wrote:
> > Hi,
> >
> > On Tue, 5 Jul 2022 at 13:39, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Tue, Jun 28, 2022 at 11:18:51PM +0900, AKASHI Takahiro wrote:
> > > > On Tue, Jun 28, 2022 at 09:37:56AM -0400, Simon Glass wrote:
> > > > > Hi Simon,
> > > > >
> > > > > On Sun, May 08, 2022 at 04:39:24AM -0600, Simon Glass wrote:
> > > > > > At present tag numbers are only allocated for non-core data, meaning that
> > > > > > the 'core' data, like priv and plat, are accessed through dedicated
> > > > > > functions.
> > > > > >
> > > > > > For debugging and consistency it is convenient to use tags for this 'core'
> > > > > > data too. Add support for this, with new tag numbers and functions to
> > > > > > access the pointer and size for each.
> > > > > >
> > > > > > Update one of the test drivers so that the uclass-private data can be
> > > > > > tested here.
> > > > > >
> > > > > > There is some code duplication with functions like device_alloc_priv() but
> > > > > > this is not addressed for now. At some point, some rationalisation may
> > > > > > help to reduce code size, but more thought it needed on that.
> > > > > >
> > > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > > > ---
> > > > > >
> > > > > >  drivers/core/device.c   | 65 +++++++++++++++++++++++++++++++++
> > > > > >  drivers/misc/test_drv.c |  4 ++-
> > > > > >  include/dm/device.h     | 25 +++++++++++++
> > > > > >  include/dm/tag.h        | 13 ++++++-
> > > > > >  test/dm/core.c          | 80 +++++++++++++++++++++++++++++++++++++++++
> > > > > >  tools/dtoc/test_dtoc.py |  4 +++
> > > > > >  6 files changed, 189 insertions(+), 2 deletions(-)
> > > > > >
> > > > > Applied to u-boot-dm, thanks!
> > > >
> > > > I expect you to reply to my comments:
> > > > https://lists.denx.de/pipermail/u-boot/2022-May/483606.html
> > >
> >
> > Oh I missed this as I have not been reading email for some months and
> > did not notice this in patchwork.
> >
> > > Simon?  This is why I haven't applied the PR for -next yet, I was
> > > waiting for your comments here, thanks.
> >
> > The reason is that the tag functionality is optional and is not used
> > for most boards. The new API is a core function.
>
> Please let me make sure your intension: Is this your answer to my question:
>   "Why not (enhance and) re-use dev_tag_get_ptr()?
>    Both functions, at least, share the syntax and even the semantics
>    from user's viewpoint."
>
> > I do expect to be able to rationalise things at some point once we
> > have a bit more code in there, but perhaps in the opposite direction.
>
> So you have a concern that this kind of API (i.e. tag) might disappear
> or be changed and diverge in incompatible(?) direction in the future
> and you think that it's the best for now to have separate APIs for
> different subsystems/users?

It is more the other way around. The tag API is not used by most
boards and is not (yet) a 'required' part of driver model. I have yet
to invest enough time to figure out how this should all pan out, but
my feeling is that, by making the private-data pointers into tags, we
can save data space, if not code space. I am leaning towards joining
tags up more so that we can use the 'tag' concept for private-data
pointers, with the ability to add other tags as a separate feature
which can be enabled or disabled. If we go that way, then
dev_tag_get_ptr() will call the new function I've added for 'core'
tags, otherwise look up its list.

The goal of this patch (and series) is to provide stats to inform the
future direction.

Regards,
Simon