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

[Greg KH]

On Mon, Aug 01, 2016 at 04:44:25PM +0200, Andrzej Hajda wrote:
> On 08/01/2016 03:55 PM, Mauro Carvalho Chehab wrote:
> > Em Mon, 1 Aug 2016 15:33:22 +0200
> > Lars-Peter Clausen <lars at metafoo.de> escreveu:
> >
> >> On 08/01/2016 03:21 PM, Hans Verkuil wrote:
> >>>
> >>> 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.
> >>>>  
> >>> We need to prevent subdevice drivers from being unbound. It's easy enough to
> >>> do that (set suppress_bind_attrs to true), we just never did that. It's been
> >>> on my TODO list for ages to make a patch adding that flag...
> >>>
> >>> You can only unbind bridge drivers. Unbinding subdevs is pointless in general
> >>> and should be prohibited. Perhaps in the future with dynamically reconfigurable
> >>> video pipelines (FPGA) you want that, but then you need to do a lot of
> >>> additional work. For everything we have today we should just set
> >>> suppress_bind_attrs to true.  
> >> suppress_bind_attrs is the lazy solution and as you pointed out does not
> >> work too well for all cases.
> > Agreed. 
> >
> > What we really need is a kind of "usage count" behavior to suppress
> > unbinds, e. g. a device driver can be unbound only if any other driver
> > using resources on it gets unbind first.
> >
> > That will solve most of unbind issues at the media subsystem.
> 
> When I was investigating issues with unbind sysfs attribute I have found
> claim by Greg KH that unbind should be rather unavoidable, like in case
> of hw removal - kernel is not able to prevent users from removing usb
> device, even if it is in use.
> 
> Assuming the claim is still valid, the only solution I see are callbacks
> notifying resource consumers about removal of the resources.

Yes, you have to do that as the hardware might now be gone, and you have
no control over that.

thanks,

greg k-h