Re: [PATCH v2] [media] media-device: use kref for media_device instance

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Shuah,

On Monday 21 Mar 2016 07:42:34 Shuah Khan wrote:
> On 03/21/2016 05:10 AM, Laurent Pinchart wrote:
> > On Friday 18 Mar 2016 21:42:16 Mauro Carvalho Chehab wrote:
> >> Now that the media_device can be used by multiple drivers,
> >> via devres, we need to be sure that it will be dropped only
> >> when all drivers stop using it.
> > 
> > I've discussed this with Shuah previously and I'm surprised to see that
> > the problem hasn't been fixed : using devres for this purpose is just
> > plain wrong. The empty media_device_release_devres() function should have
> > given you a hint.
> > 
> > What we need instead is a list of media devices indexed by struct device
> > (for this use case) or by struct device_node (for DT use cases). It will
> > both simplify the code and get rid of the devres abuse.
> > 
> > Shuah, if I recall correctly you worked on implementing such a solution
> > after our last discussion on the topic. Could you please update us on the
> > status ?
> It is work in progress. I have a working prototype for au0828 which is an
> easier case. I am working on resolving a couple of issues to differentiate
> media devices allocated using the global media device list vs. the ones
> embedded in the driver data structures. We have many of those.
> 
> I had to put this work on the back burner to get the au0882 and
> snd-usb-audio wrapped up. I can get the RFC patches on top of the au0882
> and snd-usb-audio. We can discuss them at the upcoming media summit.
> 
> > In the mean time, let's hold off on this patch, and merge a proper
> > solution instead.
> 
> I think Mauro's restructure helps us with such differentiation and it will
> be easy enough to change out devres to get media get API.

We have build too much technical debt already. I would really dislike seeing 
another hack being merged to fix partial problems when we know what needs to 
be done for a proper implementation. That's not the Linux upstream development 
I've known and grown to love, we don't pile up half-baked patches and hope 
that everything will be magically cleaned up later :-)

-- 
Regards,

Laurent Pinchart