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. -- Regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx
