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

[AKASHI Takahiro]

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?

-Takahiro Akashi

> Regards,
> Simon