Le vendredi 10 juillet 2026 à 22:42 +0200, Michael Riesch a écrit :
> Hi Paul,
> 
> On 6/25/26 10:23, Paul Elder wrote:
> > [...]
> > > > +// TODO figure out locking for when multiple drivers touch the media graph;
> > > > +// maybe macros for shared versions?
> > > 
> > > Do you mean for when drivers are trying to change link state directly?
> > 
> > I meant for all the operations that act on media device. I'm not sure what
> > there is because I didn't really find anything significant, and I found some
> > action point from some meeting notes somewhere that said "deprecate media_ops"
> > (not assigned to me) so...
> 
> Oh yes, for some reason this ball ended up in our side of the field. But
> actually I think the media_ops are not much of an issue, as you don't
> set them when you create the shared media device. Problem solved, right?

If we effectively don't need them in any drivers using shared context, let's
find a place to add a BUG_ON.

Nicolas

> 
> > If there aren't any then it's a non-issue, but if there are then I was
> > wondering if we need to return the shared media device to the driver (as
> > opposed to a non-shared regular media device) and use shared versions of media
> > device functions that have locking.
> 
> +1
> I would recommend that just to be on the safe side. And I think I would
> make the shared media device an opaque pointer to make sure that there
> won't be any monkey business.
> 
> Thanks and best regards,
> Michael
> 
> > 
> > > 
> > > > +struct media_device_shared {
> > > > +       struct media_device mdev;
> > > > +       struct list_head members;
> > > > +       struct list_head links;
> > > > +
> > > > +       struct list_head list;
> > > > +       struct kref refcount;
> > > > +
> > > > +       struct device *removed_device;
> > > > +};
> > > > +[...]