Messages in this thread | | | From | Andy Shevchenko <> | Date | Mon, 20 Jan 2020 23:55:43 +0200 | Subject | Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel |
| |
On Mon, Jan 20, 2020 at 11:44 PM Jean Delvare <jdelvare@suse.de> wrote: > > On Mon, 20 Jan 2020 10:04:04 -0600, Eric W. Biederman wrote: > > Second. I looked at your test results and they don't directly make > > sense. dmidecode bypasses the kernel completely or it did last time > > I looked so I don't know why you would be using that to test if > > something in the kernel is working. > > That must have been long ago. A recent version of dmidecode (>= 3.0) > running on a recent kernel > (>= d7f96f97c4031fa4ffdb7801f9aae23e96170a6f, v4.2) will read the DMI > data from /sys/firmware/dmi/tables, so it is very much relying on the > kernel doing the right thing. If not, it will still try to fallback to > reading from /dev/mem directly on certain architectures. You can force > that old method with --no-sysfs. > > Hope that helps,
I don't understand how it possible can help for in-kernel code, like DMI quirks in a drivers.
-- With Best Regards, Andy Shevchenko
| |