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. Regards, Hans
