From patchwork Thu Mar 12 08:50:47 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Garrett X-Patchwork-Id: 5992151 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B62E89F380 for ; Thu, 12 Mar 2015 08:51:24 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id CDD5E20381 for ; Thu, 12 Mar 2015 08:51:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 75EF42037C for ; Thu, 12 Mar 2015 08:51:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752663AbbCLIvU (ORCPT ); Thu, 12 Mar 2015 04:51:20 -0400 Received: from cavan.codon.org.uk ([93.93.128.6]:34961 "EHLO cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751833AbbCLIvR (ORCPT ); Thu, 12 Mar 2015 04:51:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codon.org.uk; s=63138784; h=Subject:Message-Id:Date:Cc:To:From; bh=kGA7VH6jPzrNinLnygkLmuWWru026fT1KGFHv/BAHnU=; b=fEGJdSZN9GvVARTJ9xv90JTtxIaj7+TLIwgHGplOoINUDfE0MrcL5w/0vgYbr2apN2qaRhR7keb2BTYftfbAUBCu+A+FzbsYS1+0fiKZ4CZQJOSJU2TmevKkzD0723FL15qa2wcfSRNSAEG9u+OFMXkYEc4gMvci4L5PG/BzZlw=; Received: from [72.253.89.114] (helo=x230.localdomain) by cavan.codon.org.uk with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YVyph-0004V0-FM; Thu, 12 Mar 2015 08:51:13 +0000 From: Matthew Garrett To: linux-acpi@vger.kernel.org Cc: rjw@rjwysocki.net, lenb@kernel.org, linux-kernel@vger.kernel.org, Matthew Garrett , Matthew Garrett Date: Wed, 11 Mar 2015 22:50:47 -1000 Message-Id: <1426150247-18309-1-git-send-email-matthew.garrett@nebula.com> X-Mailer: git-send-email 2.1.0 X-SA-Do-Not-Run: Yes X-SA-Exim-Connect-IP: 72.253.89.114 X-SA-Exim-Mail-From: matthew.garrett@nebula.com X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-ASN: Subject: [PATCH] ACPI: Adjust the return value of _REV on x86 X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:54:46 +0000) X-SA-Exim-Scanned: Yes (on cavan.codon.org.uk) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The ACPI spec describes _REV as: "This predefined object evaluates to the revision of the ACPI Specification that the specified \_OS implements" We've been assuming that this should increment as ACPICA gains support for new versions of the spec. Unfortunately, Windows always reports "2" for this value and vendors are now using this as a means to tell whether a system is running Windows or Linux. From an HP Envy 15: If (LOr (LEqual (_REV, 0x03), LEqual (_REV, 0x05))) From a Dell XPS 13: If ((_REV == 0x05)) In both cases, the systems then alter hardware initialisation paths and device capability reporting. As written, this makes no sense - ACPI maintains backwards compatibility, so the appropriate test would be >= rather than ==. On closer examination, the HP code uses the same initialisation paths as would be used if the system responded to _OSI("Linux"), and as such the evidence is overwhelmingly that vendors are using this to alter system behaviour when Linux is detected. Since we aim to be compatible with Windows, this tends to break things. The ideal solution would be to wait for an _OSI() query matching Windows and then change behaviour, but Windows responds to _REV with 2 even before that and so vendors might simply change the order of queries in order to continue IDing Linux. The easiest thing for us to do is just to change the value on X86 and leave a comment describing why everything is so awful. Signed-off-by: Matthew Garrett --- include/acpi/acconfig.h | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index 03aacfb..cebb8a7 100644 --- a/include/acpi/acconfig.h +++ b/include/acpi/acconfig.h @@ -112,9 +112,19 @@ * *****************************************************************************/ -/* Version of ACPI supported */ - +/* + * Version of ACPI supported. This is a sad story. Windows reports a _REV of + * 2 regardless of the spec version implemented. Some vendors are using _REV + * as a way to distinguish between Windows and Linux, and are breaking systems + * in the process. We can't guarantee that they'll call _OSI before checking + * _REV, so hardcode this to 2 on x86 systems right now and leave it at the + * appropriate spec value for everybody else. + */ +#ifdef CONFIG_X86 +#define ACPI_CA_SUPPORT_LEVEL 2 +#else #define ACPI_CA_SUPPORT_LEVEL 5 +#endif /* Maximum count for a semaphore object */