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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
