On 13.02.2018 15:19, Rob Herring wrote:
Doubling the number of driver config options is not going to fly.
These options would be in their own submenu (which could be disabled
completely) and use their own prefix. IMHO, even if they grow into big
numbers, the impact should be minimal.
How would you handle multiple compatible strings per driver?
Multiple entries in the submenu, each selecting the same driver.
We have all the data, so we should be able to generate this which
dt_to_config tries to do.
I guess there're lots of corner cases that would need special magic.
I think part of the problem is dt_to_config
works at the source level for everything. Really we need a more robust
way to map source files to config options and extracting match tables
from drivers. Perhaps doing the latter with coccinelle which can match
struct types, using the object files instead, or using module aliases
(though that doesn't work for built-in drivers).
Configure by already compiled binaries ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
