[Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

[Hans Verkuil]

On 07/28/2016 11:49 PM, Lars-Peter Clausen wrote:
> On 07/27/2016 07:58 PM, Luis R. Rodriguez wrote:
>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>>>> to help enable asynchronous probe, however for built-in devices this requires
>>>> very specific platform knowledge otherwise using async probe will blow up
>>>> your kernel -- if you get it right though, using async probe can help with
>>>
>>> I'm not sure what specific platform knowledge you're thinking of here?
>>> We have coverage for most things in the form of deferred probe (messy
>>> though it is).
>>
>> Deferred probe is a complete a hack and sub-optimal.
> 
> I fully agree. In the past though there were a few good attempts of
> providing something better than probe deferral, but those were always
> quickly shutdown by GregKH for failing to prove that probe deferral
> really is insufficient.
> 
> This probably an issue of presentation, but for future attempts it
> should be kept in mind that hard numbers on why this is better greatly
> improve the chance of it being accepted.

My main problem is not so much with deferred probe (esp. for cyclic dependencies
it is a simple method of solving this, and simple is good). My main problem is
that you can't tell the system that driver A needs to be probed after drivers B,
C and D are probed first.

That would allow us to get rid of v4l2-async.c which is a horrible hack.

That code allows a bridge driver to wait until all dependent drivers are probed.
This really should be core functionality.

Do other subsystems do something similar like drivers/media/v4l2-core/v4l2-async.c?
Does anyone know?

Regards,

	Hans