Re: [PATCH] media: intel-ipu3: cio2: register the mdev on v4l2 async notifier complete
From: Javier Martinez Canillas
Date: Mon Sep 03 2018 - 04:52:13 EST
On 09/03/2018 10:49 AM, Bing Bu Cao wrote:
>
>
> On 09/03/2018 03:35 PM, Javier Martinez Canillas wrote:
>> Hi,
>>
>> Thanks a lot your feedback.
>>
>> On 09/03/2018 09:25 AM, Bing Bu Cao wrote:
>>>
>>> On 08/31/2018 11:20 PM, Javier Martinez Canillas wrote:
>>>> Commit 9832e155f1ed ("[media] media-device: split media initialization and
>>>> registration") split the media_device_register() function in two, to avoid
>>>> a race condition that can happen when the media device node is accessed by
>>>> userpace before the pending subdevices have been asynchronously registered.
>>>>
>>>> But the ipu3-cio2 driver calls the media_device_register() function right
>>>> after calling media_device_init() which defeats the purpose of having two
>>>> separate functions.
>>>>
>>>> In that case, userspace could have a partial view of the media device if
>>>> it opened the media device node before all the pending devices have been
>>>> bound. So instead, only register the media device once all pending v4l2
>>>> subdevices have been registered.
>>> Javier, Thanks for your patch.
>>> IMHO, there are no big differences for registering the cio2 before and after all the subdevices are ready.
>>> User may see a partial view of media graph but it presents what it really is then.
>>> It indicate that device is not available currently not it is not there.
>> I disagree that there are no differences. The media graph shouldn't be exposed
>> until its complete. That's the reason why we have a v4l2 async notifier .bound
>> and .complete callbacks (otherwise the .bound would be enough).
>>
>> It's also the reason why media register was split in _init and _register, as I
>> mentioned in the commit message.
> I revisit the commit 9832e155f1ed and understand and agree that.
Great. Does this mean the patch has your Reviewed-by / Acked-by ?
> Seems like there are some other drivers (such as rcar-vin and omap4iss) still have similar issues.
Yes it seems so. I don't have access to hardware with these IP blocks though,
I'm hesitant to attempt to fix them.
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat