[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fcaefa19-defc-f09d-fa55-06384e2a545d@metux.net>
Date: Tue, 13 Feb 2018 16:21:52 +0000
From: Enrico Weigelt <lkml@...ux.net>
To: Rob Herring <robh@...nel.org>,
Frank Rowand <frowand.list@...il.com>
Cc: "Enrico Weigelt, metux IT consult" <metux@....de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: RFC: build config via DT names
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@...ux.net -- +49-151-27565287
Powered by blists - more mailing lists