Received: by 10.223.185.116 with SMTP id b49csp4900710wrg; Tue, 27 Feb 2018 04:41:45 -0800 (PST) X-Google-Smtp-Source: AH8x224D6ysStQCgTH8C1fSJPd+z72bGYkIczA6Bz2QZPJcrj7fv8furGJfBDZIvcQYWA5D3a2Pw X-Received: by 2002:a17:902:24c1:: with SMTP id l1-v6mr14166616plg.281.1519735305834; Tue, 27 Feb 2018 04:41:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519735305; cv=none; d=google.com; s=arc-20160816; b=GB6nXTNc363W/mLcJ8cmif71CUrGtiNOaQOaW5fN9Zzf8JewJU0o9R5pRlaYsYAaNg 8vj7SJM1CmNBSi/uD6SrnFhPGep/v1Rz1Kig8lJftykIL2e1ge20JWFWFESy1uPv0sWA 9KEDfg4rVzmBLK5iqRSuswl0VKCPl/yvGQddQnJCCK8XdE6KwXffN6qOqymEzTHEShUa HqRzQbJopdZO96K4UXKmhMS0cN0TCsQO8Dbas5GSJ29Dnv/gFK8ZdzgohjUx6Rp1cGvJ 2zClkZ4cva5yFzNYCY1QbZDyWxzcjA7Xqtje6+xWRFLu67HZ2wtTwDSKZYMQlcd+6Kcu nmlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=taEccusEiO7JsqpSTOScYSKYwCx1qptOIAsRW8bBFJ4=; b=seg727E+5TWKlCQDdPQRVtpqexS/PuJpRM9vLChJQrYjxyUmXIqtPhuN6STRrePbFn xxXNQz8q+RKOm3YLvpdfFTFJUwNA/XbA1/+Cg+vgFrsVnVA0AiAgRuIA2L9zFy6WSp5x j0hooivUzBtAo3wXwwdn1Hp/V1rlvIxof28UW7YI/UNfLpA+IWom11NPfZkO6Wxx3LiX ZKQBZ4VA26As10HgztW6Jd7oPBAdOCg4FXEFzimih2X25jPhHYIiSmJERJeib8/bnLUV MeVgghNn7eKjQufvWiq+oFQWamCfAneRB1uGMs16ovaQ+k6snQB4vdkoDsoCOj3I4J3z KJng== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v20-v6si8932278plo.199.2018.02.27.04.41.31; Tue, 27 Feb 2018 04:41:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932100AbeB0Mkd (ORCPT + 99 others); Tue, 27 Feb 2018 07:40:33 -0500 Received: from mail-lf0-f67.google.com ([209.85.215.67]:38142 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752107AbeB0Mkb (ORCPT ); Tue, 27 Feb 2018 07:40:31 -0500 Received: by mail-lf0-f67.google.com with SMTP id i80so7972987lfg.5 for ; Tue, 27 Feb 2018 04:40:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=taEccusEiO7JsqpSTOScYSKYwCx1qptOIAsRW8bBFJ4=; b=V1P0iQ6UaonUBAK0IAvzPGUotLK6yTeffpmBvY06yGmOjySqjV2t7C5w8JZ3NUUsfA bLmEW8D/LK5W856sQdFOIv/Hn4hll6iZHjEy2OE1BNMBpka3eFx11rGkHEZ2ZyVMUz7b SND5kd5iyRL8R8yRiubufxqNBk7aK/g19zWhcezeQjgvtVmDIoHGvHndhd0DNo0RFyxt rXcOFZ72wNPuTulj+xpPp7r/Z7QZ/ggcjW2O2EGDwPyoXK0Rub+na9C7toydzoRJLC1u hz1WG6e7XNzNRbTcNKajr8oh7kBmKwphhWS3yJjgaDFnJECvMIRzgda4qWwVeny/8TZb TECw== X-Gm-Message-State: APf1xPBmiMfy4YtpsxRT0/ZMWSFb7AbayskNR2LsCxXXmD4PvhxK9yWg oRY5rqBM/kDUdM3BrEoaq4SdAfdSZbt9GjIaWNtR+EuG X-Received: by 10.46.89.213 with SMTP id g82mr10413334ljf.105.1519735230332; Tue, 27 Feb 2018 04:40:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.43.149 with HTTP; Tue, 27 Feb 2018 04:40:29 -0800 (PST) In-Reply-To: <85047448dc1d2d3c725b6b78d5ef2a89fc81b83b.1519659254.git.jtoppins@redhat.com> References: <85047448dc1d2d3c725b6b78d5ef2a89fc81b83b.1519659254.git.jtoppins@redhat.com> From: Bhupesh Sharma Date: Tue, 27 Feb 2018 18:10:29 +0530 Message-ID: Subject: Re: [PATCH] arm64/acpi: make ACPI boot preference configurable To: Jonathan Toppins Cc: linux-arm-kernel , astone@redhat.com, Jonathan Masters , Catalin Marinas , Will Deacon , rafael.j.wysocki@intel.com, Ingo Molnar , Prarit Bhargava , James Morse , andriy.shevchenko@linux.intel.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins wrote: > This patch allows a user to configure ACPI to be preferred over > device-tree. > > Currently for ACPI to be used a user either has to set acpi=on on the > kernel command line or make sure any device tree passed to the kernel > is empty. If the dtb passed to the kernel is non-empty then device-tree > will be chosen as the boot method of choice even if it is not correct. Hmm. Not sure if I correctly understand what you mean here by the term 'incorrect device tree'. Do you mean a corrupted device tree blob (but normally we can catch those cases via the device tree header) or a deliberate (or a broken) firmware attempt to pass an incorrect device tree blob to the OS. If its the later, I think the onus should be on the firmware (u-boot or UEFI or others.. ) to fix the problems. I know we carry a lot of fixes in the kernel for x86 firmware quirks but then we have several broken x86 machines on which kernel has been running since several years now. IMO, if we have a known firmware quirk (to fix the broken DTB being passed from the firmware), we can look at adding it in the early arm64 kernel code (similar to the quirk handling we do in the x86 early kernel code for broken firmware), rather than forcing ACPI as the boot method. > To prevent this situation where a system is only intended to be booted > via ACPI a user can set this kernel configuration so it ignores > device-tree settings unless ACPI table checks fail. Or, if decide to depreciate DTB as the boot method for such boards, can we look at setting 'acpi=force' in the bootagrs always to make sure that ACPI (and no fallback on DTB) is forced as the boot method for such arm64 machines. Regards, Bhupesh > Signed-off-by: Jonathan Toppins > --- > > arch/arm64/Kconfig | 13 +++++++++++++ > arch/arm64/kernel/acpi.c | 2 +- > 2 files changed, 14 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 7381eeb7ef8e..da8d9ab62825 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1170,6 +1170,19 @@ config ARM64_ACPI_PARKING_PROTOCOL > protocol even if the corresponding data is present in the ACPI > MADT table. > > +config ARM64_PREFER_ACPI > + bool "Prefer usage of ACPI boot tables over device-tree" > + depends on ACPI > + help > + Normally device-tree is preferred over ACPI on arm64 unless > + explicitly preferred via kernel command line, something like: acpi=on > + This configuration changes this default behaviour by pretending > + the user set acpi=on on the command line. This configuration still > + allows the user to turn acpi table parsing off via acpi=off. If > + for some reason the table checks fail the system will still fall > + back to using device-tree unless the user explicitly sets acpi=force > + on the command line. > + > config CMDLINE > string "Default kernel command string" > default "" > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c > index 7b09487ff8fb..315b001c45f1 100644 > --- a/arch/arm64/kernel/acpi.c > +++ b/arch/arm64/kernel/acpi.c > @@ -44,7 +44,7 @@ int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */ > EXPORT_SYMBOL(acpi_pci_disabled); > > static bool param_acpi_off __initdata; > -static bool param_acpi_on __initdata; > +static bool param_acpi_on __initdata = IS_ENABLED(CONFIG_ARM64_PREFER_ACPI); > static bool param_acpi_force __initdata; > > static int __init parse_acpi(char *arg) > -- > 2.13.6 >