From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF7AFC46475 for ; Tue, 20 Nov 2018 22:08:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5D7512147A for ; Tue, 20 Nov 2018 22:08:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="zEB/rkfD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D7512147A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726168AbeKUIj5 (ORCPT ); Wed, 21 Nov 2018 03:39:57 -0500 Received: from mail.kernel.org ([198.145.29.99]:50950 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725940AbeKUIj5 (ORCPT ); Wed, 21 Nov 2018 03:39:57 -0500 Received: from [10.80.45.159] (unknown [71.69.156.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3294B20C01; Tue, 20 Nov 2018 22:08:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1542751717; bh=Nj6iELAkQQxYCZbhsXDSV8wHQH7XanhdNLzW76MFiZA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=zEB/rkfD7uhAxxwED87kSsx9KhTQrETujXmrg0Q/VtgiF29D7+AZkoBKUwMcKWNO2 fLlSb4fK3jyr8AH/SVpelihMXL7nR+gF2aMKy6x8QyHQtOkduj6mkeq/yx+Ff3ErnH ZpThzDvYwZSlbEVoTd595KlXohV8PCqoaoNwE/7s= Subject: Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER To: Alex_Gagniuc@Dellteam.com, mr.nuke.me@gmail.com, keith.busch@intel.com Cc: baicar.tyler@gmail.com, Austin.Bolen@dell.com, Shyam.Iyer@dell.com, lukas@wunner.de, bhelgaas@google.com, rjw@rjwysocki.net, lenb@kernel.org, ruscur@russell.cc, sbobroff@linux.ibm.com, oohall@gmail.com, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org References: <20181115231605.24352-1-mr.nuke.me@gmail.com> <20181119165318.GB26595@localhost.localdomain> <74f2c527-0890-5e14-5e2d-48934a42dae6@kernel.org> <20181119174127.GE26595@localhost.localdomain> <20181119181051.GA26707@localhost.localdomain> <3f923367-2cc1-c0d6-bca6-bf9a03d1b9ca@gmail.com> <84013a8a-287d-d700-6710-91cc35f507c8@kernel.org> <9c9531c7efb846438f03f744b9afc466@ausx13mps321.AMER.DELL.COM> <3b18a9fa-7bdd-0fb4-285d-4efb454be50a@kernel.org> <314e59da-48e1-545b-3ee9-6e5056b90fd9@kernel.org> <4728316eb84446358e0a07bbf1e42b57@ausx13mps321.AMER.DELL.COM> From: Sinan Kaya Message-ID: Date: Tue, 20 Nov 2018 17:08:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <4728316eb84446358e0a07bbf1e42b57@ausx13mps321.AMER.DELL.COM> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/20/2018 4:46 PM, Alex_Gagniuc@Dellteam.com wrote: > Now, let's assume, for the sake of argument, that the firmware on those > system's is broken, and it didn't intend to give the OS control of AER. > OSPM checking HEST instead of _OSC is still wrong, according to the > spec. Two wrongs don't make a right, they just don't crash. > > I think the correct way is to identify those broken systems, and add > quirks for them. Continuing to have inconsistent and over-complicated > logic that is not spec compliant is not any better. Remember that both _OSC and HEST are in the ACPI specification. I don't think there is a consensus on what is "wrong". There is certainly a need for spec clarification. One version is: "if HEST table is present, ignore _OSC" or Another version is: "if HEST table is present, make sure that FW sets _OSC bit for AER to false. Otherwise, warn like crazy that this BIOS is broken and needs an update and can cause all sorts of trouble" I can see both points of view. The second one can also be worked around by an SMBIOS quirk too as you suggested. Counting the number of quirks and random bug reports will be an interesting exercise / regression. I followed the ASWG thread yesterday. There will be a meeting next week to discuss this. My preference is not to introduce new behavior/regression to the kernel.