On Wed, Oct 21, 2015 at 04:10:31PM +0200, Takashi Iwai wrote: > On Wed, 21 Oct 2015 16:03:07 +0200, > Russell King - ARM Linux wrote: > > It's only the point if you can code it up properly, which from what I > > read in that file, it isn't. > > An idea can fly without coding, too :) > > > Build the i915 DRM drivers as a module, load up the system, and then > > try removing the i915 DRM module and see what happens to the audio part. > > For starters, you have no protection what so ever against acomp->ops or > > acomp->dev becoming NULL - it's hellishly racy. > > Yes, very likely. > > > Secondly, you reject the initialisation if acomp->ops isn't set, but you > > allow acomp->ops to later become unset by the i915 DRM module being > > removed. If you can cope with acomp->ops being unset at a random point > > during the audio driver's use, why can't you cope with it being set at > > some random point later? > > Setting/unsetting on the fly would be picky because the code does > refcounting. Maybe an easier option is to inc/dec module usage > count appropriately in use. > > > I don't think this code has been thought through at all. > > True, more hardening needed. In any case, this doesn't (and can't) solve the CEC problem, so it's not a solution to the problem at hand. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
