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