From patchwork Mon Apr 23 09:16:56 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 10356479 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id AF1EA601D3 for ; Mon, 23 Apr 2018 09:17:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9F8E928A03 for ; Mon, 23 Apr 2018 09:17:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9366A28A05; Mon, 23 Apr 2018 09:17:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F16B028A03 for ; Mon, 23 Apr 2018 09:17:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754174AbeDWJRJ (ORCPT ); Mon, 23 Apr 2018 05:17:09 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:43308 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754481AbeDWJRE (ORCPT ); Mon, 23 Apr 2018 05:17:04 -0400 Received: by mail-wr0-f194.google.com with SMTP id v15-v6so21022407wrm.10 for ; Mon, 23 Apr 2018 02:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=IO542E+sIPZSo/jIRw9koDWoZgBmQql9TQ3+GTpd1Nc=; b=eCTocTS24KGhpLSsWXoH6Cs0eUy9hMU7Sl06LHbfqaHChLktSvhCH7geGEsZTdZema wgul1TloViERYUJx/efGZT+24ROEnA474foNt78j6jJ1g/MY1M9PgnrHBi8FeOyrCFWZ WMet6WKr8AYmaPuiRx2H8iVRVq3TH0Wnp5SDU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=IO542E+sIPZSo/jIRw9koDWoZgBmQql9TQ3+GTpd1Nc=; b=D+eO+nDPGONX7lKhKG3bwJZD52gq30cdUrLYWj8vrwbqJzW1aobIW3JSg2rRuYkCns OcKW+arTksKR7ua7VRhL7LyEFIMry1qkhePw6Vk5lGs1wC9U3teEMLUhK++IRiqY3+kG xhg4FG8GWbhc03NqXaVKKppaXbeWreNVc1XgkKWnYbUdLbxXf5wY1ehoSXtlNlCAITVb eBqbiwIatIBghUHmOMnu9IQhTZzX7av6ZlUfkjH3lPOyv53+5L56poRbAALQt2dQdlEO l3oHmjmRcIO7sRrkP7bXVmUo1/Zrk+RmJ0uVhNSzavUcLWrz3JiPl81paCOwc4lP5OBj qE3g== X-Gm-Message-State: ALQs6tAKd6lGyU8wBkHfbjxKRQ28n6tkSKC3hCG6NecTlVjN9yneyZhW PKwvM47jFFYNHCKMA59V8qVZnA== X-Google-Smtp-Source: AIpwx4+dcCmTPYdzA36FzqiT1o3iPLK22W3iZCjnE+6LyMEnfvbpZk8+3igS1uZnEPYxqimZ2Hht6Q== X-Received: by 2002:adf:e549:: with SMTP id z9-v6mr10411296wrm.186.1524475023488; Mon, 23 Apr 2018 02:17:03 -0700 (PDT) Received: from localhost.localdomain ([2a01:e35:3995:5470:200:1aff:fe1b:b328]) by smtp.gmail.com with ESMTPSA id 39-v6sm18567634wry.89.2018.04.23.02.17.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 02:17:02 -0700 (PDT) From: Ard Biesheuvel To: rjw@rjwysocki.net Cc: lenb@kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, arnd@arndb.de, broonie@kernel.org, lorenzo.pieralisi@arm.com, bill.fletcher@linaro.org, linux-arm-kernel@lists.infradead.org, graeme.gregory@linaro.org, Ard Biesheuvel Subject: [PATCH v2] ACPI / button: make module loadable when booted in non-ACPI mode Date: Mon, 23 Apr 2018 11:16:56 +0200 Message-Id: <20180423091656.26257-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.17.0 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 Modules such as nouveau.ko and i915.ko have a link time dependency on acpi_lid_open(), and due to its use of acpi_bus_register_driver(), the button.ko module that provides it is only loadable when booted in ACPI mode. However, the ACPI button driver can be built into the core kernel as well, in which case the dependency can always be satisfied, and the dependent modules can be loaded regardless of whether the system was booted in ACPI mode or not. So let's fix this asymmetry by making the ACPI button driver loadable as a module even if not booted in ACPI mode, so it can provide the acpi_lid_open() symbol in the same way as when built into the kernel. Signed-off-by: Ard Biesheuvel --- v2: invert acpi_disabled logic and move comment into __acpi_bus_register_driver Could we perhaps get this into -stable as well? It is not a classic regression, but it completely breaks, e.g., Fedora when booting in DT mode on an ARM system. drivers/acpi/button.c | 24 +++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c index e1eee7a60fad..f33242e4fe6c 100644 --- a/drivers/acpi/button.c +++ b/drivers/acpi/button.c @@ -635,4 +635,26 @@ module_param_call(lid_init_state, NULL, 0644); MODULE_PARM_DESC(lid_init_state, "Behavior for reporting LID initial state"); -module_acpi_driver(acpi_button_driver); +static int __acpi_bus_register_driver(struct acpi_driver *driver) +{ + /* + * Modules such as nouveau.ko and i915.ko have a link time dependency + * on acpi_lid_open(), and would therefore not be loadable on ACPI + * capable kernels booted in non-ACPI mode if we use the ordinary + * acpi_bus_[un]register_driver routines here (which only work when + * booted in ACPI mode) and build this driver as a module. So provide + * our own versions instead. + */ + if (acpi_disabled) + return 0; + return acpi_bus_register_driver(driver); +} + +static void __acpi_bus_unregister_driver(struct acpi_driver *driver) +{ + if (!acpi_disabled) + acpi_bus_unregister_driver(driver); +} + +module_driver(acpi_button_driver, __acpi_bus_register_driver, + __acpi_bus_unregister_driver);