mbox series

[0/2] Add iterator for an entity's data links

Message ID 20220621163457.766496-1-djrscally@gmail.com
Headers show
Series Add iterator for an entity's data links | expand

Message

Daniel Scally June 21, 2022, 4:34 p.m. UTC 
There are a bunch of places in the kernel where code iterates over an entity's
links to perform some action. Those almost invariably have the implicit
assumption that those links are data links, which might not be true following
the introduction of ancillary links. Add a dedicated iterator that skips any
non data links for use instead, which will allow that assumption to hold true.

Daniel Scally (2):
  media: media-entity.h: Add iterator for entity data links
  media: entity: Use dedicated data link iterator

 drivers/media/mc/mc-entity.c |  6 +++---
 include/media/media-entity.h | 26 ++++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 3 deletions(-)

Comments

Laurent Pinchart June 22, 2022, 9:16 a.m. UTC | #1 
Hi Daniel,

Thank you for the patch.

On Tue, Jun 21, 2022 at 05:34:56PM +0100, Daniel Scally wrote:
> Iterating over the links for an entity is a somewhat common need
> through the media subsystem, but generally the assumption is that
> they will all be data links. To meet that assumption add a new macro
> that iterates through an entity's links and skips non-data links.
> 
> Signed-off-by: Daniel Scally <djrscally@gmail.com>
> ---
>  include/media/media-entity.h | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index a9a1c0ec5d1c..b13f67f33508 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -550,6 +550,32 @@ static inline bool media_entity_enum_intersects(
>  				 min(ent_enum1->idx_max, ent_enum2->idx_max));
>  }
>  
> +static inline struct media_link *
> +__media_entity_next_data_link(struct media_entity *entity,
> +			      struct media_link *pos)

We could make this more dynamic by passing the link type as an argument,
adding more iteration macros for different link types in the future
would then be easier. Up to you.

> +{
> +	if (!pos) {
> +		list_for_each_entry(pos, &entity->links, list)
> +			if ((pos->flags & MEDIA_LNK_FL_LINK_TYPE) ==
> +			    MEDIA_LNK_FL_DATA_LINK)
> +				return pos;
> +
> +		return NULL;
> +	}
> +
> +	list_for_each_entry_continue(pos, &entity->links, list)
> +		if ((pos->flags & MEDIA_LNK_FL_LINK_TYPE) ==
> +		    MEDIA_LNK_FL_DATA_LINK)
> +			return pos;

This could be simplified to

	if (!pos)
		pos = list_entry(&entity->links, struct media_link, list);

	list_for_each_entry_continue(pos, &entity->links, list) {
		if ((pos->flags & MEDIA_LNK_FL_LINK_TYPE) ==
		    MEDIA_LNK_FL_DATA_LINK)
			return pos;
	}

> +
> +	return NULL;
> +}

This is a bit big for an inline function, could we move the
implementation to the .c file ?

> +
> +#define for_each_media_entity_data_link(entity, pos)		\

s/pos/link/ ?

> +	for (pos = __media_entity_next_data_link(entity, NULL);	\
> +	     pos;						\
> +	     pos = __media_entity_next_data_link(entity, pos))
> +

I'm afraid this needs documentation :-)
(https://lore.kernel.org/linux-media/20220301161156.1119557-13-tomi.valkeinen@ideasonboard.com/
can be used as an example)

>  /**
>   * gobj_to_entity - returns the struct &media_entity pointer from the
>   *	@gobj contained on it.
Jacopo Mondi June 22, 2022, 9:22 a.m. UTC | #2 
hi Laurent,

On Wed, Jun 22, 2022 at 12:17:56PM +0300, Laurent Pinchart wrote:
> On Wed, Jun 22, 2022 at 11:08:59AM +0200, Jacopo Mondi wrote:
> > Hi Dan
> >
> > On Tue, Jun 21, 2022 at 05:34:56PM +0100, Daniel Scally wrote:
> > > Iterating over the links for an entity is a somewhat common need
> > > through the media subsystem, but generally the assumption is that
> > > they will all be data links. To meet that assumption add a new macro
> > > that iterates through an entity's links and skips non-data links.
> >
> > Do you foresee usages of a similar iterator but for ancillary (or
> > interface) links ?
> >
> > In that case you could add a 'link_type' flag to
> > __media_entity_next_data_link
> >
> > >
> > > Signed-off-by: Daniel Scally <djrscally@gmail.com>
> > > ---
> > >  include/media/media-entity.h | 26 ++++++++++++++++++++++++++
> > >  1 file changed, 26 insertions(+)
> > >
> > > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > > index a9a1c0ec5d1c..b13f67f33508 100644
> > > --- a/include/media/media-entity.h
> > > +++ b/include/media/media-entity.h
> > > @@ -550,6 +550,32 @@ static inline bool media_entity_enum_intersects(
> > >  				 min(ent_enum1->idx_max, ent_enum2->idx_max));
> > >  }
> > >
> > > +static inline struct media_link *
> >
> > Isn't this a bit too much for inlining ? Also I heard many times that
> > it's not worth anymore trying to outsmart the compiler and inline is
> > discouraged in most cases ? (and it kind of makes sense to me, but I
> > sometimes wonder if that's some form of cargo cult..)
>
> That's right, but in .h files you need to manually inline, otherwise
> you'll end up with one copy per compilation unit.
>

I was suggesting to move it to a .c file in facts, likely mc-entity.c
Daniel Scally June 22, 2022, 9:40 a.m. UTC | #3 
Hi Jacopo

On 22/06/2022 10:08, Jacopo Mondi wrote:
> Hi Dan
>
> On Tue, Jun 21, 2022 at 05:34:56PM +0100, Daniel Scally wrote:
>> Iterating over the links for an entity is a somewhat common need
>> through the media subsystem, but generally the assumption is that
>> they will all be data links. To meet that assumption add a new macro
>> that iterates through an entity's links and skips non-data links.
> Do you foresee usages of a similar iterator but for ancillary (or
> interface) links ?
>
> In that case you could add a 'link_type' flag to
> __media_entity_next_data_link


Ooh this is a great idea - I'm not sure we'd need it for the ancillary
links right now but in the future when the flash gets linked then it
could crop up. I'll add the flag, thanks.

>
>> Signed-off-by: Daniel Scally <djrscally@gmail.com>
>> ---
>>  include/media/media-entity.h | 26 ++++++++++++++++++++++++++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
>> index a9a1c0ec5d1c..b13f67f33508 100644
>> --- a/include/media/media-entity.h
>> +++ b/include/media/media-entity.h
>> @@ -550,6 +550,32 @@ static inline bool media_entity_enum_intersects(
>>  				 min(ent_enum1->idx_max, ent_enum2->idx_max));
>>  }
>>
>> +static inline struct media_link *
> Isn't this a bit too much for inlining ? Also I heard many times that
> it's not worth anymore trying to outsmart the compiler and inline is
> discouraged in most cases ? (and it kind of makes sense to me, but I
> sometimes wonder if that's some form of cargo cult..)


Probably - I'll move the function to media-entity.c instead.

>
>> +__media_entity_next_data_link(struct media_entity *entity,
>> +			      struct media_link *pos)
>> +{
>> +	if (!pos) {
>> +		list_for_each_entry(pos, &entity->links, list)
> nit: coding style requires you to have braces
>
> ------------------------------------------------------------------------------
> from Documentation/process/coding-style.rst:
> Also, use braces when a loop contains more than a single simple statement:
>
> .. code-block:: c
>
> 	while (condition) {
> 		if (test)
> 			do_something();
> 	}
> ------------------------------------------------------------------------------


Good point, thanks :)

>> +			if ((pos->flags & MEDIA_LNK_FL_LINK_TYPE) ==
>> +			    MEDIA_LNK_FL_DATA_LINK)
>> +				return pos;
>> +
>> +		return NULL;
>> +	}
>> +
>> +	list_for_each_entry_continue(pos, &entity->links, list)
>> +		if ((pos->flags & MEDIA_LNK_FL_LINK_TYPE) ==
>> +		    MEDIA_LNK_FL_DATA_LINK)
>> +			return pos;
>> +
>> +	return NULL;
> I wonder if the same could be achieved with list_for_each_entry_from() ?
>
> 	pos = pos ? list_next_entry(pos, list)
> 		  : list_first_entry(&entity->links, typeof(*pos), list);
>
>         list_for_each_entry_from(pos, ...) {
>                 if (...)
>                         return pos;
>
>         }
>
>         return NULL;
>
> If I'm not mistaken the two versions are functionally equivalent..


Yes that's much better - thanks!

>
> The iterator seems a good idea. Do you plan to use it for
> "media: rkisp1: Don't create data links for non-sensor subdevs" too,
> or changing the list of subdevs to iterate is enough there ?


No it's a slightly different problem there actually, I'm going to switch
that to the list of async subdevs in the same way the ipu3-cio2 works as
you suggested instead.


> Thanks
>    j
>
>> +}
>> +
>> +#define for_each_media_entity_data_link(entity, pos)		\
>> +	for (pos = __media_entity_next_data_link(entity, NULL);	\
>> +	     pos;						\
>> +	     pos = __media_entity_next_data_link(entity, pos))
>> +
>>  /**
>>   * gobj_to_entity - returns the struct &media_entity pointer from the
>>   *	@gobj contained on it.
>> --
>> 2.25.1
>>