diff options
author | 2018-02-03 11:25:20 +0100 | |
---|---|---|
committer | 2018-02-03 11:25:20 +0100 | |
commit | 7117794feb1602ea5efca1c7bfd5b78c3278d29d (patch) | |
tree | dc9e69e830c6ab064490d164ae4828ea9abacdd1 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | firmware: dmi: Optimize dmi_matches (diff) | |
download | linux-dev-7117794feb1602ea5efca1c7bfd5b78c3278d29d.tar.xz linux-dev-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 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions