[Letux-kernel] found something interesting: dt_to_config

H. Nikolaus Schaller hns at goldelico.com
Mon Jan 7 20:56:14 CET 2019

> Am 07.01.2019 um 19:41 schrieb Andreas Kemnade <andreas at kemnade.info>:
> On Mon, 7 Jan 2019 18:04:43 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> Hi,
>>> Am 07.01.2019 um 17:02 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> Hi,
>>> something I just stumbled upon:
>>> scripts/dtc/dt_to_config
>>> It can generate kernel config fragments to support devices with a given
>>> devicetree.  
>> Nice! It probably looks for the needed .compatible strings and drivers
>> that support it.
>>> That brings up the following idea:
>>> reduce letux_defconfig
>>> by using make savedefconfig
>>> generate for each device to be supported a config fragment using mentioned tool.
>>> concatenate that and filter duplicates ( cat configs | sort | uniq )
>>> combine that with the (probably reduced by hw-specific stuff) defconfig mentioned above.
>>> just some ideas. maybe these ideas might be helpful.  
>> Intersting. Yes, this process seems to be able to ensure that all required
>> device drivers are configured.
>> My compile driver would already has all required info: it knows the list of relevant .dts files for all supported devices.
>> The only thing we have to check how this process handles extra configs and CONFIG=y vs. CONFIG=m.
> That is an interesting point.
>> And there might be a problem if there are two alternative drivers that can support
>> the same chip. This process can't choose either one.
> Hmm, where do we have that situation is practice?

Sensors may have dedicated and iio drivers.
On the Pyra we have two different as5013 drivers.
For w2sg0004 we currently have two driver alternatives.
And AFAIK for w2cbw003 as well.

So it may happen more often.

>> So maybe it should not automatically generate a new letux_defconfig but could
>> be used every now and then for verification.
> I am not sure yet what can be practically done with that.
> Maybe it is a nice idea to put together the config from fragments:
> - some basic stuff,
> - the driversfor the current device you are developing for
> (or of course for all if doing an actual release)
> - additional debug options
> So you have a faster compile. Especially, if you want to bisect
> something.

Hm. Rarely. If CONFIG doesn't change or the source doesn't change
a make within bisect will not recompile files that are not influenced.

> Another idea would be to use the fragments to find out other hardware
> having the same driver, so if you develop something in such a
> common-used driver, you can easily spot other targets for narrowing
> down a bug or to warn/test if you have broken something.

Well, if any device is broken it is quite easy to find out the driver,
get the .compatible and scan all .dts for all devices.

So I currently see the main purpose to cover the case that a driver
is not configured but references by DTS. On the other hand, if it
is important, it is also quite simple to find out if a device expected
on some board is missing.


More information about the Letux-kernel mailing list