| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 28 Apr 2016 16:44:27 -0700 From: Gaurav Minocha <gaurav.minocha.os@...il.com> To: Frank Rowand <frowand.list@...il.com> Cc: Rob Herring <robh+dt@...nel.org>, Grant Likely <grant.likely@...aro.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Linux Kernel list <linux-kernel@...r.kernel.org>, Geert Uytterhoeven <geert+renesas@...der.be>, Pavel Machek <pavel@....cz> Subject: Re: [PATCH] scripts/dtc: dt_to_config - report kernel config options for a devicetree On Thu, Apr 28, 2016 at 4:31 PM, Frank Rowand <frowand.list@...il.com> wrote: > On 4/28/2016 3:32 PM, Rob Herring wrote: >> On Thu, Apr 28, 2016 at 4:46 PM, Frank Rowand <frowand.list@...il.com> wrote: >>> From: Frank Rowand <frank.rowand@...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@...il.com> >>> Signed-off-by: Frank Rowand <frank.rowand@...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? > Yes, Of course. > >>> +# >>> +# 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@...50000 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. >>> + >>> +@...ver_black_list = ( >>> + 'virt/kvm/arm/.*', >>> +); >> >> A small number of exceptions like this I could stomach. >> >> The rest is just write-only language nonsense... >> >> Rob >> >
Powered by blists - more mailing lists