Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 16 Oct 2015 12:21:55 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH] input: i8042: add quirk to implement i8042 detect for AMD |
| |
On Fri, Oct 16, 2015 at 05:35:40PM +0800, Wan ZongShun wrote: > 2015-10-16 16:58 GMT+08:00 Borislav Petkov <bp@alien8.de>: > > On Fri, Oct 16, 2015 at 09:27:00AM -0400, Vincent Wan wrote: > >> Detecting platform supports i8042 or not, AMD resorted to > >> BIOS's FADT i8042 flag. > >> > >> Signed-off-by: Vincent Wan <Vincent.Wan@amd.com> > >> --- > >> drivers/input/serio/i8042-x86ia64io.h | 6 ++++++ > >> 1 file changed, 6 insertions(+) > > >> /* > >> @@ -1047,6 +1048,11 @@ static int __init i8042_platform_init(void) > >> /* Just return if pre-detection shows no i8042 controller exist */ > >> if (!x86_platform.i8042_detect()) > >> return -ENODEV; > >> + > >> + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) { > > > > Why the vendor check if you're accessing a bit defined in the ACPI spec? > > From intel's 'x86_platform.i8042_detect' implementation, I doubt if > their BIOS is providing this i8024 flag.
Why would you doubt that - it is at least in ACPI v4, if not earlier. If you still doubt that, go and check it or ask Intel people.
> So I have to implement my codes carefully.
What are you people talking about?!
It is in the ACPI spec - this bit is either set or not. If it is not set, then that's a problem. But then it is the problem of this one BIOS. Vendor checks have nothing to do in vendor-agnostic code.
Besides, there's intel_mid_i8042_detect() which is platform-specific and Intel can supply a specific ->detect() function if, in the very distant chance, they don't implement that bit.
Still no need for a vendor check!
-- Regards/Gruss, Boris.
ECO tip #101: Trim your mails when you reply.
| ![\](/images/icornerr.gif) |