On Wednesday 29 June 2011 17:24:42 Nicolas Ferre wrote:> > Here are a few questions:> > i) The drivers you're willing to send, are those for Atmel's IPs or are> > the IPs sourced from some other company ?> > ii) Even if they are Atmel-specific, do you see the possibility of Atmel> > licensing them ?> > iii) Does your driver current depend on asm/ or mach/ headers ?> > iv) Is there a generic header which you could use instead of asm/ mach/ ?> > I just want to hide drivers that are not relevant for others: I have the feeling> that it is a good practice. This tiny patch will ease this during my publication> flow. Do you seriously care?

I think Felipe is right on this one, but both views are common in the kerneltoday: Some people want dependencies to mean "you cannot build this driverunless the dependencies are fulfilled", others like them more broadly tomean "there is no point to ever enable this driver because I know you won'tneed it".

Both views are understandable, but I favor the first one because

* it's the more common view these days and we should be consistent

* it exposes drivers to more build testing. If something changes in the kernel that exposes new warnings in your driver or causes a build error, that is more likely to get fixed when more people find it by doing allyesconfig or randconfig builds.

* If there is an actual build dependency between the driver and the platform that causes you to need the explicit Kconfig depends, that is in many cases a hint that the driver author is doing something wrong, like hardcoding MMIO addresses or referencing custom symbols exported by the platform.

I don't think anyone really objects your patch to introduce the extraKconfig symbol, but I'd hope that we can eventually get a consensuson the idea that you shouldn't use Kconfig dependencies based onwhether a driver is relevant or not.