Morning both On 22/06/2022 10:22, Jacopo Mondi wrote: > 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@xxxxxxxxx> >>>> --- >>>> 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 The one copy per compilation unit problem spurred the inline indeed - but no problem, I'll move it to the .c
