On Wed, Oct 21, 2015 at 03:37:47PM +0100, Russell King - ARM Linux wrote:
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.
I will try to fix this once I am done with Skylake drivers.. Plus adding new features like ELD in on my plan for this interface
In any case, this doesn't (and can't) solve the CEC problem, so it's not a solution to the problem at hand.
Sorry am not sure I follow the reasons for that, wouldn't CEC be another slave in such an interface? I though component fwk did allow us to have multiple slaves..