Hi, On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote: > >>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he > >>> doesn't want to extend the kconfig language for this purpose > >>> (which I support). That a config option is fine and sufficient > >>> in this case [1]. Except he called the config option > >>> "SHOW_ALL_DRIVERS". Adding the current maintainer to CCs ;). > >> > >> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite > >> self-explanatory. And even if it's not, you can look up the help > >> text for COMPILE_TEST. With "archdepends on" or "available on", > >> you need to know what to look for to override the dependency. > > > > you will still end up with: > > > > depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI || ARCH_PPC || > > ...) > > > > And every now and again that particular line will be updated to > > add another arch dependency. > > But that is perfectly fine *when* the driver is supported on those > archs only. > > And come on, how much often will this "every now and again" happen? We > don't have that much cases where a driver is augmented to work on > another arch or platform. It either works on all of them => doesn't > need COMPILE_TEST, or work on one or two arches at most. MUSB alone has 8 different arch choices. Before, it used to be that core driver was dependendent on all of them, so whenever someone wanted to build MUSB for another arch, they had to introdude their glue code and modify the dependency of the core driver. Also EHCI, it works on pretty much everything, so does DWC3. DWC3 already has three possibilities but I know of at least 3 others which could show up soonish. -- balbi
Attachment:
signature.asc
Description: Digital signature
