summaryrefslogtreecommitdiff
path: root/drivers/gpio/gpiolib-devprop.c
diff options
context:
space:
mode:
authorJean Delvare <jdelvare@suse.de>2018-02-03 13:25:20 +0300
committerJean Delvare <jdelvare@suse.de>2018-02-03 13:25:20 +0300
commit7117794feb1602ea5efca1c7bfd5b78c3278d29d (patch)
treedc9e69e830c6ab064490d164ae4828ea9abacdd1 /drivers/gpio/gpiolib-devprop.c
parent8cf4e6a04f734e831c2ac7f405071d1cde690ba8 (diff)
downloadlinux-7117794feb1602ea5efca1c7bfd5b78c3278d29d.tar.xz
firmware: dmi_scan: Drop dmi_initialized
I don't think it makes sense to check for a possible bad initialization order at run time on every system when it is all decided at build time. A more efficient way to make sure developers do not introduce new calls to dmi_check_system() too early in the initialization sequence is to simply document the expected call order. That way, developers have a chance to get it right immediately, without having to test-boot their kernel, wonder why it does not work, and parse the kernel logs for a warning message. And we get rid of the run-time performance penalty as a nice side effect. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'drivers/gpio/gpiolib-devprop.c')
0 files changed, 0 insertions, 0 deletions