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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham 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 3A540C43387 for ; Fri, 11 Jan 2019 17:45:50 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 12CA020874 for ; Fri, 11 Jan 2019 17:45:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YLn7tKNX"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=alien8.de header.i=@alien8.de header.b="ePBKL0gz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12CA020874 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=alien8.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=OMtsx/fko0qoDEYuFBsD7+hkjX0EVR9it5EAj0SD6L8=; b=YLn7tKNX127m7O cMSoA2yIqwcC9MLwFywr6ItTNLj9i9HOR1MyPfMGQEDrug/oxaJNC2rEqIxaStIX4YlG9sAKgSPiC /0EKnvwFGi5HyfCgF1wBhyRx1lXMeOQUd8kENwk3eW9uR7I4j4p1DDzry9sDpc0MMpPLa/Sj/5Jtg gZ+4kqVwIKShmNx9HOxZB59G7qaEgITDQn4ppRhG9MoqNaJZfSEhJAl+5cD7ZAyNypiMFlHfu2v25 u7kE22cWu8689F2UzFUl7IRYp5lJsGfik27B/3RI4pzt4wOAWK5FkK1Cnn2dLAlTKcykkw+p7k2Bw 3m1ChAIM/2EhfVKQpnCg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gi0sH-0006X8-78; Fri, 11 Jan 2019 17:45:41 +0000 Received: from mail.skyhub.de ([2a01:4f8:190:11c2::b:1457]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gi0sD-0006Wf-Bp for linux-arm-kernel@lists.infradead.org; Fri, 11 Jan 2019 17:45:38 +0000 Received: from zn.tnic (p200300EC2BCAC5003956DFF8679C923C.dip0.t-ipconnect.de [IPv6:2003:ec:2bca:c500:3956:dff8:679c:923c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 67C371EC0432; Fri, 11 Jan 2019 18:45:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1547228735; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=C6meGvLj7DPHaw89eAz4zx+tq65KJG8Kh2yHjsBMUUk=; b=ePBKL0gzEqNWczWz8s1xWOrIQp/J9lVBc1OrpDcwewQMBXdWm5pyGC2fBhhHRN4GPssu98 u4RGqjV2eNkMpLYTI1jjxgabZGGWXhsRHGBE+qHb8ZlIpElJC4x+8tWsBclSPn8PY3OMCh TwxpQDfPAFNA8c+O5RRMCdP46tcva8I= Date: Fri, 11 Jan 2019 18:45:32 +0100 From: Borislav Petkov To: Tyler Baicar Subject: Re: [PATCH v7 10/25] ACPI / APEI: Tell firmware the estatus queue consumed the records Message-ID: <20190111174532.GI4729@zn.tnic> References: <20181203180613.228133-1-james.morse@arm.com> <20181203180613.228133-11-james.morse@arm.com> <20181211183634.GO27375@zn.tnic> <56cfa16b-ece4-76e0-3799-58201f8a4ff1@arm.com> <20190111120322.GD4729@zn.tnic> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190111_094537_590783_392048BD X-CRM114-Status: GOOD ( 11.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rafael Wysocki , Tony Luck , Fan Wu , linux-mm@kvack.org, Marc Zyngier , Catalin Marinas , Xie XiuQi , Will Deacon , Christoffer Dall , Dongjiu Geng , Linux ACPI , James Morse , Naoya Horiguchi , kvmarm@lists.cs.columbia.edu, arm-mail-list , Len Brown Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jan 11, 2019 at 10:32:23AM -0500, Tyler Baicar wrote: > The kernel would have no way of knowing what to do here. What do you mean, there's no way of knowing what to do? It needs to clear registers so that the next error can get reported properly. Or of the status read failed and it doesn't need to do anything, then it shouldn't. Whatever it is, the kernel either needs to do something in the error case to clean up, or nothing if the firmware doesn't need anything done in the error case; *or* ack the error in the success case. This should all be written down somewhere in that GHES v2 spec/doc/writeup whatever, explaining what the OS is supposed to do to signal the error has been read by the OS. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel