Hi,
On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote:
quoted
quoted
quoted
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