From patchwork Mon Nov 23 17:28:17 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Amadeusz_S=C5=82awi=C5=84ski?= X-Patchwork-Id: 331614 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=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT 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 499BAC56202 for ; Mon, 23 Nov 2020 15:11:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 04EB620773 for ; Mon, 23 Nov 2020 15:11:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389414AbgKWPL4 (ORCPT ); Mon, 23 Nov 2020 10:11:56 -0500 Received: from mga01.intel.com ([192.55.52.88]:5778 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389411AbgKWPL4 (ORCPT ); Mon, 23 Nov 2020 10:11:56 -0500 IronPort-SDR: oeC1jl5ZbHWIU38pOofx89Yv38VAJuUqS4zFqoHI170uDteIcshxF+U2QtSopoqkqRotcYOZ2p vkt/4pVlrtRw== X-IronPort-AV: E=McAfee;i="6000,8403,9813"; a="189897423" X-IronPort-AV: E=Sophos;i="5.78,363,1599548400"; d="scan'208";a="189897423" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Nov 2020 07:11:56 -0800 IronPort-SDR: uyuIbRRmxDGAqSnrGrW5/VcM0s49NC+ICHKAZ/Zg2Cvt3Es6UlgrX8rqA87BqCMs/5HEu5DJ6C XPZynEcMuqeQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.78,363,1599548400"; d="scan'208";a="402628595" Received: from pi-desktop.igk.intel.com ([10.237.148.102]) by orsmga001.jf.intel.com with ESMTP; 23 Nov 2020 07:11:54 -0800 From: =?utf-8?q?Amadeusz_S=C5=82awi=C5=84ski?= To: Ard Biesheuvel , linux-efi@vger.kernel.org Cc: Cezary Rojewski , =?utf-8?q?Amadeusz_S?= =?utf-8?b?xYJhd2nFhHNraQ==?= Subject: [PATCH] efi/efivars: Set generic ops before loading SSDT Date: Mon, 23 Nov 2020 12:28:17 -0500 Message-Id: <20201123172817.124146-1-amadeuszx.slawinski@linux.intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org Efivar allows for overriding of SSDT tables, however starting with commit bf67fad19e493b ("efi: Use more granular check for availability for variable services") this use case is broken. When loading SSDT generic ops should be set first, however mentioned commit reversed order of operations. Fix this by restoring original order of operations. Fixes: bf67fad19e493b ("efi: Use more granular check for availability for variable services") Signed-off-by: Amadeusz Sławiński Tested-by: Cezary Rojewski --- drivers/firmware/efi/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 5e5480a0a32d..6c6eec044a97 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -390,10 +390,10 @@ static int __init efisubsys_init(void) if (efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE | EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME)) { - efivar_ssdt_load(); error = generic_ops_register(); if (error) goto err_put; + efivar_ssdt_load(); platform_device_register_simple("efivars", 0, NULL, 0); }