[Letux-kernel] found something interesting: dt_to_config

Andreas Kemnade andreas at kemnade.info
Mon Jan 7 19:41:43 CET 2019


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?

> 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.
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.

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20190107/78dabdb4/attachment-0001.asc>


More information about the Letux-kernel mailing list