From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Gaurav Minocha
<gaurav.minocha.os-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Kernel list
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Geert Uytterhoeven
<geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>,
Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Subject: Re: [PATCH] scripts/dtc: dt_to_config - report kernel config options for a devicetree
Date: Thu, 28 Apr 2016 16:31:19 -0700 [thread overview]
Message-ID: <57229D47.6070704@gmail.com> (raw)
In-Reply-To: <CAL_JsqKGcc_wXV2_-3ZVS7gzfo2ao9z+eATdnKVsyRnW2O5e4A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 4/28/2016 3:32 PM, Rob Herring wrote:
> On Thu, Apr 28, 2016 at 4:46 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Frank Rowand <frank.rowand-mEdOJwZ7QcZBDgjK7y7TUQ@public.gmane.org>
>>
>> Determining which kernel config options need to be enabled for a
>> given devicetree can be a painful process. Create a new tool to
>> find the drivers that may match a devicetree node compatible,
>> find the kernel config options that enable the driver, and
>> optionally report whether the kernel config option is enabled.
>
> I would find this more useful to output a config fragment with all the
> options enabled. The hard part there is enabling the options a given
> option is dependent on which I don't think kbuild takes care of.
>
>> Signed-off-by: Gaurav Minocha <gaurav.minocha.os-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Frank Rowand <frank.rowand-mEdOJwZ7QcZBDgjK7y7TUQ@public.gmane.org>
>>
>> ---
>> scripts/dtc/dt_to_config | 1061 +++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 1061 insertions(+)
>>
>> Index: b/scripts/dtc/dt_to_config
>> ===================================================================
>> --- /dev/null
>> +++ b/scripts/dtc/dt_to_config
>> @@ -0,0 +1,1061 @@
>> +#!/usr/bin/perl
>
> I don't do perl...
>
>> +
>> +# Copyright 2016 by Frank Rowand
>> +# Š Copyright 2016 by Gaurav Minocha
> ^
> Is this supposed to be a copyright symbol?
Yes. Gaurav, can we drop this symbol?
>> +#
>> +# This file is subject to the terms and conditions of the GNU General Public
>> +# License v2.
>
> [...]
>
>> +# ----- magic compatibles, do not have a driver
>> +#
>> +# Will not search for drivers for these compatibles.
>> +
>> +%compat_white_list = (
>> + 'fixed-partitions' => '1',
>
> Enabling CONFIG_MTD would be useful.
Thanks! I'll dig deeper, but it likes like maybe
CONFIG_MTD_OF_PARTS also.
>> + 'none' => '1',
>
> Is this an actual string used somewhere?
Yes. Looking at the output from running this against all .dts
files has led to some interesting information.
An example of compatible = "none" is node mct@10050000 from
arch/arm/boot/dts/exynos4210-universal_c210.dts
>
>> + 'pci' => '1',
>
> ditto?
arch/x86/platform/ce4100/falconfalls.dts, node pci@3fc
>> + 'simple-bus' => '1',
>> +);
>> +
>> +# magic compatibles, have a driver
>> +#
>> +# Will not search for drivers for these compatibles.
>> +# Will instead use the drivers and config options listed here.
>> +#
>> +# If you add an entry to this hash, add the corresponding entry
>> +# to %driver_config_hard_code_list.
>> +#
>> +# These compatibles have a very large number of false positives.
>
> What does this mean?
That means that a _lot_ of garbage, bogus matches are reported,
creating a lot of noise in the report.
>> +#
>> +# 'hardcoded_no_driver' is a magic value. Other code knows this
>> +# magic value. Do not use 'no_driver' here!
>> +#
>> +# TODO: Revisit each 'hardcoded_no_driver' to see how the compatible
>> +# is used. Are there drivers that can be provided?
>> +
>> +%driver_hard_code_list = (
>> + 'cache' => ['hardcoded_no_driver'],
>> + 'eeprom' => ['hardcoded_no_driver'],
>> + 'gpio' => ['hardcoded_no_driver'],
>> + 'gpios' => ['drivers/leds/leds-tca6507.c'],
>> + 'gpio-keys' => ['drivers/input/keyboard/gpio_keys.c'],
>> + 'i2c-gpio' => ['drivers/i2c/busses/i2c-gpio.c'],
>> + 'isa' => ['arch/mips/mti-malta/malta-dt.c',
>> + 'arch/x86/kernel/devicetree.c'],
>> + 'led' => ['hardcoded_no_driver'],
>> + 'm25p32' => ['hardcoded_no_driver'],
>> + 'm25p64' => ['hardcoded_no_driver'],
>> + 'm25p80' => ['hardcoded_no_driver'],
>> + 'mtd_ram' => ['drivers/mtd/maps/physmap_of.c'],
>> + 'pwm-backlight' => ['drivers/video/backlight/pwm_bl.c'],
>> + 'spidev' => ['hardcoded_no_driver'],
>> + 'syscon' => ['drivers/mfd/syscon.c'],
>> + 'tlv320aic23' => ['hardcoded_no_driver'],
>> + 'wm8731' => ['hardcoded_no_driver'],
>> +);
>> +
>> +%driver_config_hard_code_list = (
>> +
>> + # this one needed even if %driver_hard_code_list is empty
>> + 'no_driver' => ['no_config'],
>> + 'hardcoded_no_driver' => ['no_config'],
>> +
>> + 'drivers/leds/leds-tca6507.c' => ['CONFIG_LEDS_TCA6507'],
>> + 'drivers/input/keyboard/gpio_keys.c' => ['CONFIG_KEYBOARD_GPIO'],
>> + 'drivers/i2c/busses/i2c-gpio.c' => ['CONFIG_I2C_GPIO'],
>> + 'arch/mips/mti-malta/malta-dt.c' => ['obj-y'],
>> + 'arch/x86/kernel/devicetree.c' => ['CONFIG_OF'],
>> + 'drivers/mtd/maps/physmap_of.c' => ['CONFIG_MTD_PHYSMAP_OF'],
>> + 'drivers/video/backlight/pwm_bl.c' => ['CONFIG_BACKLIGHT_PWM'],
>> + 'drivers/mfd/syscon.c' => ['CONFIG_MFD_SYSCON'],
>
> I don't understand why some of these are not searchable by compatible strings.
I will have to get back to you later on this question.
>> +
>> + # drivers/usb/host/ehci-ppc-of.c
>> + # drivers/usb/host/ehci-xilinx-of.c
>> + # are included from:
>> + # drivers/usb/host/ehci-hcd.c
>> + # thus the search of Makefile for the included .c files is incorrect
>> + # ehci-hcd.c wraps the includes with ifdef CONFIG_USB_EHCI_HCD_..._OF
>> + #
>> + # similar model for ohci-hcd.c (but no ohci-xilinx-of.c)
>> + #
>> + # similarly, uhci-hcd.c includes uhci-platform.c
>> +
>> + 'drivers/usb/host/ehci-ppc-of.c' => ['CONFIG_USB_EHCI_HCD',
>> + 'CONFIG_USB_EHCI_HCD_PPC_OF'],
>> + 'drivers/usb/host/ohci-ppc-of.c' => ['CONFIG_USB_OHCI_HCD',
>> + 'CONFIG_USB_OHCI_HCD_PPC_OF'],
>> +
>> + 'drivers/usb/host/ehci-xilinx-of.c' => ['CONFIG_USB_EHCI_HCD',
>> + 'CONFIG_USB_EHCI_HCD_XILINX'],
>> +
>> + 'drivers/usb/host/uhci-platform.c' => ['CONFIG_USB_UHCI_HCD',
>> + 'CONFIG_USB_UHCI_PLATFORM'],
>> +
>> + # scan_makefile will find only one of these config options:
>> + # ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A),)
>> + 'arch/arm/mach-imx/platsmp.c' => ['CONFIG_SOC_IMX6 && CONFIG_SMP',
>> + 'CONFIG_SOC_LS1021A && CONFIG_SMP'],
>
> These will never get updated when the files or config options change.
> Conversely, how do I know if I need to add something here? Is this
> list complete or based on testing some set of dts files. IMO, this
> list has to go to merge this.
That is a concern that I have also. I added a warning flag in the
flags field to indicate when one of these hard-coded values was used.
The flag does not solve the issue, but does make it more visible.
The list is a result of running against every dts file in the kernel
tree and looking at the reports.
>> +);
>> +
>> +
>> +# 'virt/kvm/arm/.*' are controlled by makefiles in other directories,
>> +# using relative paths, such as 'KVM := ../../../virt/kvm'. Do not
>> +# add complexity to find_kconfig() to deal with this. There is a long
>> +# term intent to change the kvm related makefiles to the normal kernel
>> +# style. After that is done, this entry can be removed from the
>> +# driver_black_list.
>> +
>> +@driver_black_list = (
>> + 'virt/kvm/arm/.*',
>> +);
>
> A small number of exceptions like this I could stomach.
>
> The rest is just write-only language nonsense...
>
> Rob
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Frank Rowand <frowand.list@gmail.com>
To: Rob Herring <robh+dt@kernel.org>,
Gaurav Minocha <gaurav.minocha.os@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Pavel Machek <pavel@ucw.cz>
Subject: Re: [PATCH] scripts/dtc: dt_to_config - report kernel config options for a devicetree
Date: Thu, 28 Apr 2016 16:31:19 -0700 [thread overview]
Message-ID: <57229D47.6070704@gmail.com> (raw)
In-Reply-To: <CAL_JsqKGcc_wXV2_-3ZVS7gzfo2ao9z+eATdnKVsyRnW2O5e4A@mail.gmail.com>
On 4/28/2016 3:32 PM, Rob Herring wrote:
> On Thu, Apr 28, 2016 at 4:46 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> From: Frank Rowand <frank.rowand@am.sony.com>
>>
>> Determining which kernel config options need to be enabled for a
>> given devicetree can be a painful process. Create a new tool to
>> find the drivers that may match a devicetree node compatible,
>> find the kernel config options that enable the driver, and
>> optionally report whether the kernel config option is enabled.
>
> I would find this more useful to output a config fragment with all the
> options enabled. The hard part there is enabling the options a given
> option is dependent on which I don't think kbuild takes care of.
>
>> Signed-off-by: Gaurav Minocha <gaurav.minocha.os@gmail.com>
>> Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
>>
>> ---
>> scripts/dtc/dt_to_config | 1061 +++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 1061 insertions(+)
>>
>> Index: b/scripts/dtc/dt_to_config
>> ===================================================================
>> --- /dev/null
>> +++ b/scripts/dtc/dt_to_config
>> @@ -0,0 +1,1061 @@
>> +#!/usr/bin/perl
>
> I don't do perl...
>
>> +
>> +# Copyright 2016 by Frank Rowand
>> +# Š Copyright 2016 by Gaurav Minocha
> ^
> Is this supposed to be a copyright symbol?
Yes. Gaurav, can we drop this symbol?
>> +#
>> +# This file is subject to the terms and conditions of the GNU General Public
>> +# License v2.
>
> [...]
>
>> +# ----- magic compatibles, do not have a driver
>> +#
>> +# Will not search for drivers for these compatibles.
>> +
>> +%compat_white_list = (
>> + 'fixed-partitions' => '1',
>
> Enabling CONFIG_MTD would be useful.
Thanks! I'll dig deeper, but it likes like maybe
CONFIG_MTD_OF_PARTS also.
>> + 'none' => '1',
>
> Is this an actual string used somewhere?
Yes. Looking at the output from running this against all .dts
files has led to some interesting information.
An example of compatible = "none" is node mct@10050000 from
arch/arm/boot/dts/exynos4210-universal_c210.dts
>
>> + 'pci' => '1',
>
> ditto?
arch/x86/platform/ce4100/falconfalls.dts, node pci@3fc
>> + 'simple-bus' => '1',
>> +);
>> +
>> +# magic compatibles, have a driver
>> +#
>> +# Will not search for drivers for these compatibles.
>> +# Will instead use the drivers and config options listed here.
>> +#
>> +# If you add an entry to this hash, add the corresponding entry
>> +# to %driver_config_hard_code_list.
>> +#
>> +# These compatibles have a very large number of false positives.
>
> What does this mean?
That means that a _lot_ of garbage, bogus matches are reported,
creating a lot of noise in the report.
>> +#
>> +# 'hardcoded_no_driver' is a magic value. Other code knows this
>> +# magic value. Do not use 'no_driver' here!
>> +#
>> +# TODO: Revisit each 'hardcoded_no_driver' to see how the compatible
>> +# is used. Are there drivers that can be provided?
>> +
>> +%driver_hard_code_list = (
>> + 'cache' => ['hardcoded_no_driver'],
>> + 'eeprom' => ['hardcoded_no_driver'],
>> + 'gpio' => ['hardcoded_no_driver'],
>> + 'gpios' => ['drivers/leds/leds-tca6507.c'],
>> + 'gpio-keys' => ['drivers/input/keyboard/gpio_keys.c'],
>> + 'i2c-gpio' => ['drivers/i2c/busses/i2c-gpio.c'],
>> + 'isa' => ['arch/mips/mti-malta/malta-dt.c',
>> + 'arch/x86/kernel/devicetree.c'],
>> + 'led' => ['hardcoded_no_driver'],
>> + 'm25p32' => ['hardcoded_no_driver'],
>> + 'm25p64' => ['hardcoded_no_driver'],
>> + 'm25p80' => ['hardcoded_no_driver'],
>> + 'mtd_ram' => ['drivers/mtd/maps/physmap_of.c'],
>> + 'pwm-backlight' => ['drivers/video/backlight/pwm_bl.c'],
>> + 'spidev' => ['hardcoded_no_driver'],
>> + 'syscon' => ['drivers/mfd/syscon.c'],
>> + 'tlv320aic23' => ['hardcoded_no_driver'],
>> + 'wm8731' => ['hardcoded_no_driver'],
>> +);
>> +
>> +%driver_config_hard_code_list = (
>> +
>> + # this one needed even if %driver_hard_code_list is empty
>> + 'no_driver' => ['no_config'],
>> + 'hardcoded_no_driver' => ['no_config'],
>> +
>> + 'drivers/leds/leds-tca6507.c' => ['CONFIG_LEDS_TCA6507'],
>> + 'drivers/input/keyboard/gpio_keys.c' => ['CONFIG_KEYBOARD_GPIO'],
>> + 'drivers/i2c/busses/i2c-gpio.c' => ['CONFIG_I2C_GPIO'],
>> + 'arch/mips/mti-malta/malta-dt.c' => ['obj-y'],
>> + 'arch/x86/kernel/devicetree.c' => ['CONFIG_OF'],
>> + 'drivers/mtd/maps/physmap_of.c' => ['CONFIG_MTD_PHYSMAP_OF'],
>> + 'drivers/video/backlight/pwm_bl.c' => ['CONFIG_BACKLIGHT_PWM'],
>> + 'drivers/mfd/syscon.c' => ['CONFIG_MFD_SYSCON'],
>
> I don't understand why some of these are not searchable by compatible strings.
I will have to get back to you later on this question.
>> +
>> + # drivers/usb/host/ehci-ppc-of.c
>> + # drivers/usb/host/ehci-xilinx-of.c
>> + # are included from:
>> + # drivers/usb/host/ehci-hcd.c
>> + # thus the search of Makefile for the included .c files is incorrect
>> + # ehci-hcd.c wraps the includes with ifdef CONFIG_USB_EHCI_HCD_..._OF
>> + #
>> + # similar model for ohci-hcd.c (but no ohci-xilinx-of.c)
>> + #
>> + # similarly, uhci-hcd.c includes uhci-platform.c
>> +
>> + 'drivers/usb/host/ehci-ppc-of.c' => ['CONFIG_USB_EHCI_HCD',
>> + 'CONFIG_USB_EHCI_HCD_PPC_OF'],
>> + 'drivers/usb/host/ohci-ppc-of.c' => ['CONFIG_USB_OHCI_HCD',
>> + 'CONFIG_USB_OHCI_HCD_PPC_OF'],
>> +
>> + 'drivers/usb/host/ehci-xilinx-of.c' => ['CONFIG_USB_EHCI_HCD',
>> + 'CONFIG_USB_EHCI_HCD_XILINX'],
>> +
>> + 'drivers/usb/host/uhci-platform.c' => ['CONFIG_USB_UHCI_HCD',
>> + 'CONFIG_USB_UHCI_PLATFORM'],
>> +
>> + # scan_makefile will find only one of these config options:
>> + # ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A),)
>> + 'arch/arm/mach-imx/platsmp.c' => ['CONFIG_SOC_IMX6 && CONFIG_SMP',
>> + 'CONFIG_SOC_LS1021A && CONFIG_SMP'],
>
> These will never get updated when the files or config options change.
> Conversely, how do I know if I need to add something here? Is this
> list complete or based on testing some set of dts files. IMO, this
> list has to go to merge this.
That is a concern that I have also. I added a warning flag in the
flags field to indicate when one of these hard-coded values was used.
The flag does not solve the issue, but does make it more visible.
The list is a result of running against every dts file in the kernel
tree and looking at the reports.
>> +);
>> +
>> +
>> +# 'virt/kvm/arm/.*' are controlled by makefiles in other directories,
>> +# using relative paths, such as 'KVM := ../../../virt/kvm'. Do not
>> +# add complexity to find_kconfig() to deal with this. There is a long
>> +# term intent to change the kvm related makefiles to the normal kernel
>> +# style. After that is done, this entry can be removed from the
>> +# driver_black_list.
>> +
>> +@driver_black_list = (
>> + 'virt/kvm/arm/.*',
>> +);
>
> A small number of exceptions like this I could stomach.
>
> The rest is just write-only language nonsense...
>
> Rob
>
next prev parent reply other threads:[~2016-04-28 23:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 21:46 [PATCH] scripts/dtc: dt_to_config - report kernel config options for a devicetree Frank Rowand
2016-04-28 21:46 ` Frank Rowand
[not found] ` <572284AB.102-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-28 21:52 ` [PATCH] scripts/dtc: dt_to_config - example 1 Frank Rowand
2016-04-28 21:52 ` Frank Rowand
2016-04-28 21:53 ` [PATCH] scripts/dtc: dt_to_config - example 2 Frank Rowand
2016-04-28 21:53 ` Frank Rowand
2016-04-28 21:54 ` [PATCH] scripts/dtc: dt_to_config - report kernel config options for a devicetree Frank Rowand
2016-04-28 21:54 ` Frank Rowand
2016-04-28 21:55 ` [PATCH] scripts/dtc: dt_to_config - usage message Frank Rowand
2016-04-28 21:55 ` Frank Rowand
2016-04-28 22:32 ` [PATCH] scripts/dtc: dt_to_config - report kernel config options for a devicetree Rob Herring
2016-04-28 22:32 ` Rob Herring
[not found] ` <CAL_JsqKGcc_wXV2_-3ZVS7gzfo2ao9z+eATdnKVsyRnW2O5e4A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-28 23:31 ` Frank Rowand [this message]
2016-04-28 23:31 ` Frank Rowand
[not found] ` <57229D47.6070704-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-28 23:44 ` Gaurav Minocha
2016-04-28 23:44 ` Gaurav Minocha
2016-04-29 6:39 ` Gaurav Minocha
[not found] ` <CA+rpMbJkWM+bsvXT77eyLGewtKHjX1inc0vjsWxYQTCgzmpDGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-29 6:44 ` Geert Uytterhoeven
2016-04-29 6:44 ` Geert Uytterhoeven
2016-04-29 15:54 ` Frank Rowand
2016-04-30 20:38 ` Rob Herring
2016-04-30 20:38 ` Rob Herring
[not found] ` <CAL_Jsq+v3r1dNY1+CK=_Atyyysq=JAFfk0q7i6YVhKS1zTZMVg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-05-05 16:25 ` Gaurav Minocha
2016-05-05 16:25 ` Gaurav Minocha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57229D47.6070704@gmail.com \
--to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=gaurav.minocha.os-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pavel-+ZI9xUNit7I@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.