Hi Takahiro,
On Mon, 11 Oct 2021 at 00:43, AKASHI Takahiro
<takahiro.aka...@linaro.org> wrote:
>
> Simon,
>
> On Sun, Oct 10, 2021 at 08:14:18AM -0600, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Thu, 30 Sept 2021 at 23:04, AKASHI Takahiro
> > <takahiro.aka...@linaro.org> wrote:
> > >
> > > This member field in udevice will be used to dereference from udevice
> > > to efi_object (or efi_handle).
> > >
> > > Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
> > > ---
> > > include/dm/device.h | 4 ++++
> > > 1 file changed, 4 insertions(+)
> >
> > I think this should be generalised.
> >
> > Can we add a simple API for attaching things to devices? Something like:
>
> Ok.
>
>
> > config DM_TAG
> > bool "Support tags attached to devices"
> >
> > enum dm_tag_t {
> > DM_TAG_EFI = 0,
> >
> > DM_TAG_COUNT,
> > };
> >
> > ret = dev_tag_set_ptr(dev, DM_TAG_EFI, ptr);
> >
> > void *ptr = dev_tag_get_ptr(dev, DM_TAG_EFI);
> >
> > ulong val = dev_tag_get_val(dev, DM_TAG_EFI);
> >
> > Under the hood I think for now we could have a simple list of tags for
> > all of DM:
> >
> > struct dmtag_node {
> > struct list_head sibling;
> > struct udevice *dev;
> > enum dm_tag_t tag;
> > union {
> > void *ptr;
> > ulong val;
> > };
> > };
>
> Just let me make sure; Do you intend that we have a *single* list of tags
> in the system instead of maintaining a list *per udevice*?
Yes I would prefer not to have a list per udevice, although the API
could be adjusted to iterate through all tags for a particular
udevice, if that is needed (dev_tag_first...() dev_tag_next...().
Looking at some of your other patches I think you might need to
support multiple tags for EFI, if there are different things. But
perhaps a list is necesary.
>
> -Takahiro Akashi
>
>
> > This can be useful in other situations, for example I think we need to
> > be able to send an event when a device is probed so that other devices
> > (with tags attached) can take action. But in any case, it makes the
> > API separate from the data structure, so aids refactoring later.
> >
> > If we find that this is slow we can change the impl, but I doubt it
> > will matter fornow.
> >
[..]
Regards,
Simon
