Received: by 10.223.185.116 with SMTP id b49csp5014731wrg; Tue, 27 Feb 2018 06:31:22 -0800 (PST) X-Google-Smtp-Source: AH8x224sk5W4IVnldsns8T0iTq5cNCmCCQOan1evYsb2k1QszCBSP8PamNMTz6TELqWLCoDpMzrU X-Received: by 2002:a17:902:2803:: with SMTP id e3-v6mr14348035plb.238.1519741882578; Tue, 27 Feb 2018 06:31:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519741882; cv=none; d=google.com; s=arc-20160816; b=osz1X5j8U3hG2TlWcg9BeKLWNoGYmNHK7yW5+JI9/F1KJ5gM2n2DUZBjKdY3MUaSe7 /YHAYam0iGrnDjq5p68LBlWQkHvsgDpXI/7AC5CxYtOulW7abkEFrDCkEtBAvc5sLk27 jKOZi/9FLUopHy0cnDhkcCDd1F7AxW3yK1nMPxBYm7ww7myhOfBsB7alL9Mcmgb2Jz2a mbR+z6LPnNVZciCewDanHbJ88MnW2WA+V5Fd9/Dv+Fp9yt9mdgNlrxMMpyCo6ax08yV5 py6E9RZYSNAFmyCsXQWMI1OQ8hMQYuyES1i2+Jxs2PmpJRa5GiL7l0MKtMQFKAi0HKx1 Nj9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject:reply-to :arc-authentication-results; bh=RKh9Tpn7p5h4glQZ+A+D1xskaKjLHg+9Eu6il/QZQfs=; b=VRuHLA+2qwr4mhneDb/gQI+YgNzhpl0X+TvVvb1fmxU6NlqPhLTTYkzy7F+Rv5MWFa O/udylGSafwKD2GkgXM082Pji+FJkmlo1k6ofTmr67rGDSd55r9XFCef14YTZtLQZpZH BFd4J3eC6bL1W28KoVRBeJmWmHIaethz4Wj2PWN1kpdQ6xQhBsIKv9zvp5WRNZp3lCb6 DiBtGCq5Sb5/CVTwvlmVswrRTr/eldn9GDlWjo4lqkV2BCFnO5ZC1iD6QQAQoEXhbjvo 2mBp/rVGxsW1K4MDIgOR/Eph5w9QeA4/RXqPwlPsQM05jaHcjQ46TYrk+y+43HbuQY5l hvEg== 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 d19-v6si8537960pls.822.2018.02.27.06.31.07; Tue, 27 Feb 2018 06:31:22 -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 S1753531AbeB0O24 (ORCPT + 99 others); Tue, 27 Feb 2018 09:28:56 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:43050 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752573AbeB0O2y (ORCPT ); Tue, 27 Feb 2018 09:28:54 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CAA64814DF58; Tue, 27 Feb 2018 14:28:53 +0000 (UTC) Received: from jtoppins.rdu.csb (dhcp137-178.rdu.redhat.com [10.13.137.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id 21B442026E04; Tue, 27 Feb 2018 14:28:53 +0000 (UTC) Reply-To: jtoppins@redhat.com Subject: Re: [PATCH] arm64/acpi: make ACPI boot preference configurable To: Ard Biesheuvel Cc: prarit@redhat.com, Jon Masters , Bhupesh Sharma , "Rafael J. Wysocki" , Will Deacon , Linux Kernel Mailing List , astone@redhat.com, James Morse , Catalin Marinas , Andy Shevchenko , Ingo Molnar , linux-arm-kernel References: <85047448dc1d2d3c725b6b78d5ef2a89fc81b83b.1519659254.git.jtoppins@redhat.com> From: Jonathan Toppins Organization: Red Hat Message-ID: <1454e833-e3b9-780b-c5db-a6f73e799352@redhat.com> Date: Tue, 27 Feb 2018 09:28:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 27 Feb 2018 14:28:53 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 27 Feb 2018 14:28:53 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'jtoppins@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/27/2018 02:22 AM, Ard Biesheuvel wrote: > Hi Jonathan, > > On 27 February 2018 at 06:05, Jonathan Toppins wrote: >> This patch allows a user to configure ACPI to be preferred over >> device-tree. >> > > This comes up once a year or so, and the consensus has been so far > that it is not up to the kernel to reason about whether DT or ACPI > should be preferred if both are supplied, Instead, it is up to the > firmware to ensure that only one of those is provided, and we added a > generic driver to EDK2 that implements this. I am assuming EDK2 is some sort of firmware code base, not that I have ever heard of it before. This logic compared with the implementation in the kernel seems divergent. The kernel is clearly making a choice about which boot table (DT vs ACPI) to configure with. So to claim it is not the kernel's job to reason about which to use is clearly incorrect. The only thing this patch is doing is making it easier for distributions to configure which preference the kernel has. > >> 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. > > Your firmware is terminally broken if it provides an incorrect DT, and > we should not be fixing it in the kernel. This logic would seem akin to me asking Bjorn to remove all PCI quirks from the kernel, because the systems that use them are "terminally broken" or "don't follow the standard". This doesn't seem like a valid reason to deny a change that would allow the kernel to boot on more hardware. Further it seems rather rigid to effectively say that we only run on perfect firmware. > >> 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. >> > > 'only intended to be booted via ACPI' is a property of the system, not > of the OS. If you need this functionality for development, you can > append 'acpi=on' to the kernel command line via kconfig. This is not for development this is for production rate shipping firmware.