... and __initconst if applicable.
Based on similar work for an older kernel in the Grsecurity patch.
[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Accidentally specified a smaller record size, bring it back
to the same size as we had when we used the config file.
Signed-off-by: Olof Johansson <olofj@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
In order to handle the firmware placing the ramoops buffer
in a different location than the kernel is configured to look
probe for an ACPI device specified by GOOG9999 acpi id. If
no device is found or the first memory resource is not defined
properly fall back to the configured base and length.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Ben Zhang <benzh@chromium.org>
Signed-off-by: Filipe Brandenburger <filbranden@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Turns out that DMI_SYSTEM_VENDOR is actually the native vendor of each
Chromebook/box. I tested the original patch on a Pixel that -- surprise,
has Google as vendor. *facepalm*.
The only other data I can think of to probe on is Google_* in the version
string. Checking with our firmware team, all systems should have this
and nothing else than Chrome hardware should have the coreboot + Google_*
combination to date.
So, we'll switch to this. For future platforms we are going to move to
using an ACPI device to configure this instead of a DMI table (yay!),
so longer-term that will sort itself out.
Signed-off-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Benson Leung <bleung@chromium.org>
