lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160223135731.GA24781@xora-haswell.xora.org.uk>
Date:	Tue, 23 Feb 2016 13:57:31 +0000
From:	Graeme Gregory <gg@...mlogic.co.uk>
To:	Matthias Brugger <matthias.bgg@...il.com>
Cc:	Aleksey Makarov <aleksey.makarov@...aro.org>,
	linux-acpi@...r.kernel.org, Russell King <linux@....linux.org.uk>,
	Graeme Gregory <graeme.gregory@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J . Wysocki" <rjw@...ysocki.net>,
	linux-kernel@...r.kernel.org,
	Leif Lindholm <leif.lindholm@...aro.org>,
	Christopher Covington <cov@...eaurora.org>,
	linux-serial@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>, Al Stone <ahs3@...hat.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/8] arm64: move acpi/dt decision earlier in boot process

On Mon, Feb 22, 2016 at 04:45:17PM +0100, Matthias Brugger wrote:
> 
> 
> On 22/02/16 14:46, Aleksey Makarov wrote:
> >From: Leif Lindholm <leif.lindholm@...aro.org>
> >
> >In order to support selecting earlycon via either ACPI or DT, move
> >the decision on whether to attempt ACPI configuration into the
> >early_param handling. Then make acpi_boot_table_init() bail out if
> >acpi_disabled.
> >
> >Signed-off-by: Leif Lindholm <leif.lindholm@...aro.org>
> >---
> >  arch/arm64/kernel/acpi.c | 54 ++++++++++++++++++++++++++----------------------
> >  1 file changed, 29 insertions(+), 25 deletions(-)
> >
> >diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >index d1ce8e2..7a944f7 100644
> >--- a/arch/arm64/kernel/acpi.c
> >+++ b/arch/arm64/kernel/acpi.c
> >@@ -44,6 +44,19 @@ EXPORT_SYMBOL(acpi_pci_disabled);
> >  static bool param_acpi_off __initdata;
> >  static bool param_acpi_force __initdata;
> >
> >+static int __init dt_scan_depth1_nodes(unsigned long node,
> >+				       const char *uname, int depth,
> >+				       void *data)
> >+{
> >+	/*
> >+	 * Return 1 as soon as we encounter a node at depth 1 that is
> >+	 * not the /chosen node.
> >+	 */
> >+	if (depth == 1 && (strcmp(uname, "chosen") != 0))
> >+		return 1;
> >+	return 0;
> >+}
> >+
> >  static int __init parse_acpi(char *arg)
> >  {
> >  	if (!arg)
> >@@ -57,23 +70,27 @@ static int __init parse_acpi(char *arg)
> >  	else
> >  		return -EINVAL;	/* Core will print when we return error */
> >
> >-	return 0;
> >-}
> >-early_param("acpi", parse_acpi);
> >+	/*
> >+	 * Enable ACPI instead of device tree unless
> >+	 * - ACPI has been disabled explicitly (acpi=off), or
> >+	 * - the device tree is not empty (it has more than just a /chosen node)
> >+	 *   and ACPI has not been force enabled (acpi=force)
> >+	 */
> >+	if (param_acpi_off ||
> >+	    (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
> >+		return 0;
> >
> >-static int __init dt_scan_depth1_nodes(unsigned long node,
> >-				       const char *uname, int depth,
> >-				       void *data)
> >-{
> >  	/*
> >-	 * Return 1 as soon as we encounter a node at depth 1 that is
> >-	 * not the /chosen node.
> >+	 * ACPI is disabled at this point. Enable it in order to parse
> >+	 * the ACPI tables and carry out sanity checks
> >  	 */
> >-	if (depth == 1 && (strcmp(uname, "chosen") != 0))
> >-		return 1;
> >+	enable_acpi();
> >+
> 
> So we only enable ACPI if we pass acpi=force as kernel parameter?
> I'm not sure if this is what you wanted to do.
> 

The current preference from ARM64 maintainers was that is both ACPI
tables and a DT were presented then DT should take precedence.

With no DT provided the code should use ACPI.

Graeme

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ