On Wed, Dec 03, 2014 at 05:20:15PM +0100, Philipp Zabel wrote: > Hi Andy, > > It would be better if the bind function would not have to care about > platform resources, that should be handled in the probe function. I had > a patch to move them: > > http://lists.freedesktop.org/archives/dri-devel/2014-May/059630.html > > Maybe you could incorporate something like this?
Personally, I hate this idea. Having a two-layered setup means that the when the bind() method is called, the state of struct imx_hdmi is indeterminant. If it's called immediately from probe, most of the structure will be zeroed, and only those members initialised by the probe function will be set to non-zero values. However, if the HDMI interface has been previously bound, and is subsequently re-bound, then the structure will most definitely no longer be in a known state on the second bind() call. This is fragile. Now, people have tried to tell me that this isn't fragile, but, I now have proof that it is as fragile as I fear. The component helper doesn't yet have that many users, and already we have one user (okay, it's not part of the mainline kernel - it's etnaviv) which contained exactly this kind of bug: it expected its private structures to be zeroed on the bind() call. So, I /really/ hate this idea. If you really want to do this, then please ensure that the bind() call explicitly zeros the bits of the struct which aren't initialised by the probe() call, so we know that the driver will always start off with a known initial state. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
