Hans Verkuil wrote: > On Monday 14 December 2009 21:41:20 Guennadi Liakhovetski wrote: >> On Mon, 14 Dec 2009, Jonathan Cameron wrote: >> > Having bridge-specific code in a sub-device driver will be a disaster in the > long run. Well, we've seen what happens when you do it that way. True. > As far as I know the only soc-dependency left now is for bus configuration. > Proposals were made some time ago and we should pick that up again and remove > that last dependency. We should really go on that direction. V4L i2c drivers shouldn't depend on platform_data. I've experienced some very bad time fixing conflicts and waiting for arch merges in order to try to avoid conflicts related to platform_data changes that should be reflected into V4L drivers. Even after migrating to -git, this problem won't solve, since the header files that holds platform_data are highly volatile: on all kernel versions, they had several changes, and the platform_data patch made while changing the V4L code needs to be changed during the next merge window. Due to that, I don't doubt that some earlier merges had broke git bisect capabilities on those drivers that rely on the highly volatile platform_data header files applied on arch tree and a separate patch applied on v4l tree. It seems that we'll need to have some code that will be responsible to handle arch/platform_data glue, to be merged in the same subsystem that holds the *.h files, taking care on the required differences for drivers that need platform_data to work, and a separate code to handle the V4L functionalities. In other words, drivers like soc_camera and omap core should be broken internally into two separate files (or modules), one with V4L bits and the other with arch/platform_data glue, where the second one should be be maintained together with the corresponding arch code. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html