From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 39C8C91A for ; Mon, 1 Aug 2016 13:14:07 +0000 (UTC) Received: from www381.your-server.de (www381.your-server.de [78.46.137.84]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BFD1F29A for ; Mon, 1 Aug 2016 13:14:04 +0000 (UTC) To: Laurent Pinchart , ksummit-discuss@lists.linuxfoundation.org References: <98eb563b-5d62-74df-692a-f2aa4f7b07b8@xs4all.nl> <20160729111303.GA10376@sirena.org.uk> <2525670.QGOuaEkzC4@avalon> From: Lars-Peter Clausen Message-ID: Date: Mon, 1 Aug 2016 15:14:00 +0200 MIME-Version: 1.0 In-Reply-To: <2525670.QGOuaEkzC4@avalon> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "vegard.nossum@gmail.com" , Valentin Rothberg , "rafael.j.wysocki" , Marek Szyprowski , Mauro Carvalho Chehab Subject: Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 08/01/2016 03:09 PM, Laurent Pinchart wrote: > On Friday 29 Jul 2016 12:13:03 Mark Brown wrote: >> On Fri, Jul 29, 2016 at 09:45:55AM +0200, Hans Verkuil wrote: >>> 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? >> >> ASoC does, it has an explicit card driver to join things together and >> that just defers probe until everything it needs is present. This was >> originally open coded in ASoC but once deferred probe was implemented we >> converted to that. > > Asynchronous bindings of components, as done in ASoC, DRM and V4L2, is a > problem largely solved (or rather hacked around), but I'm curious to know how > ASoC handles device unbinding (due to device removal or manual unbinding > through sysfs). With asynchronous binding we can more or less easily wait for > all components to be present before creating circular dependencies, but > breaking them to implement unbinding is an unsolved problem at least in V4L2. > ASoC does not handle it at the moment. It will just crash when you do that :( For a recent discussion on this see http://mailman.alsa-project.org/pipermail/alsa-devel/2016-July/110440.html