diff options
author | Jean Delvare <jdelvare@suse.de> | 2018-02-03 11:25:20 +0100 |
---|---|---|
committer | Jean Delvare <jdelvare@suse.de> | 2018-02-03 11:25:20 +0100 |
commit | 7117794feb1602ea5efca1c7bfd5b78c3278d29d (patch) | |
tree | dc9e69e830c6ab064490d164ae4828ea9abacdd1 /drivers/firmware/Kconfig | |
parent | 8cf4e6a04f734e831c2ac7f405071d1cde690ba8 (diff) | |
download | talos-obmc-linux-7117794feb1602ea5efca1c7bfd5b78c3278d29d.tar.gz talos-obmc-linux-7117794feb1602ea5efca1c7bfd5b78c3278d29d.zip |
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/firmware/Kconfig')
0 files changed, 0 insertions, 0 deletions