Em Mon, 9 Oct 2017 16:20:08 +0200 Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > On 09/10/17 16:18, Sakari Ailus wrote: > > Hi Hans, > > > > On Mon, Oct 09, 2017 at 04:08:47PM +0200, Hans Verkuil wrote: > >> On 09/10/17 16:06, Sakari Ailus wrote: > >>> Hi Mauro, > >>> > >>> On Mon, Oct 09, 2017 at 08:22:39AM -0300, Mauro Carvalho Chehab wrote: > >>>> Em Thu, 5 Oct 2017 00:50:20 +0300 > >>>> Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> escreveu: > >>>> > >>>>> Remove V4L2 async re-probing support. The re-probing support has been > >>>>> there to support cases where the sub-devices require resources provided by > >>>>> the main driver's hardware to function, such as clocks. > >>>>> > >>>>> Reprobing has allowed unbinding and again binding the main driver without > >>>>> explicilty unbinding the sub-device drivers. This is certainly not a > >>>>> common need, and the responsibility will be the user's going forward. > >>>>> > >>>>> An alternative could have been to introduce notifier specific locks. > >>>>> Considering the complexity of the re-probing and that it isn't really a > >>>>> solution to a problem but a workaround, remove re-probing instead. > >>>> > >>>> If the re-probing isn't using anywhere, that sounds a nice cleanup. > >>>> Did you check if this won't break any driver (like soc_camera)? > >>> > >>> That was discussed earlier in the review; Laurent asked the same question. > >>> > >>> Re-probing never was a proper solution to any problem; it was just a hack > >>> to avoid unbinding the sensor if the bridge driver was unbound, no more: it > >>> can't be generalised to support more complex use cases. Mind you, this is > >>> on devices that aren't actually removable. > >>> > >>> I've briefly discussed this with Laurent; the proper solution would need to > >>> be implemented in the clock framework instead. There, the existing clocks > >>> obtained by drivers could be re-activated when the driver for them comes > >>> back. > >>> > >>> My proposal is that if there's real a need to address this, then it could > >>> be solved in the clock framework. > >> > >> Can you add this information to the commit log? > >> > >> I think that would be very helpful in the future. > > > > Sure, how about this at the end of the current commit message: > > > > If there is a need to support removing the clock provider in the future, > > this should be implemented in the clock framework instead, not in V4L2. > > Yes, that sounds good. Works for me too. Regards, Mauro
