linux-kernel - Re: [PATCH v3 8/9] ACPI: arm64: use an arch-specific ACPI

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: <54F4B345.6020001@linaro.org>
Date:	Mon, 02 Mar 2015 12:00:21 -0700
From:	Al Stone <al.stone@...aro.org>
To:	Will Deacon <will.deacon@....com>
CC:	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"lenb@...nel.org" <lenb@...nel.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	"robert.moore@...el.com" <robert.moore@...el.com>,
	"tony.luck@...el.com" <tony.luck@...el.com>,
	"fenghua.yu@...el.com" <fenghua.yu@...el.com>,
	"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"devel@...ica.org" <devel@...ica.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	"patches@...aro.org" <patches@...aro.org>
Subject: Re: [PATCH v3 8/9] ACPI: arm64: use an arch-specific ACPI _OSI method
 and ACPI blacklist

On 03/02/2015 10:29 AM, Will Deacon wrote:
> Hi Al,
> 
> On Wed, Feb 25, 2015 at 12:36:24AM +0000, al.stone@...aro.org wrote:
>> diff --git a/arch/arm64/kernel/acpi-blacklist.c b/arch/arm64/kernel/acpi-blacklist.c
>> new file mode 100644
>> index 0000000..1be6a56
>> --- /dev/null
>> +++ b/arch/arm64/kernel/acpi-blacklist.c
>> @@ -0,0 +1,20 @@
>> +/*
>> + *  ARM64 Specific ACPI Blacklist Support
>> + *
>> + *  Copyright (C) 2015, Linaro Ltd.
>> + *	Author: Al Stone <al.stone@...aro.org>
>> + *
>> + *  This program is free software; you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License version 2 as
>> + *  published by the Free Software Foundation.
>> + */
>> +
>> +#define pr_fmt(fmt) "ACPI: " fmt
>> +
>> +#include <linux/acpi.h>
>> +
>> +/* The arm64 ACPI blacklist is currently empty.  */
>> +int __init acpi_blacklisted(void)
>> +{
>> +	return 0;
>> +}
>> diff --git a/arch/arm64/kernel/acpi-osi.c b/arch/arm64/kernel/acpi-osi.c
>> new file mode 100644
>> index 0000000..bb351f4
>> --- /dev/null
>> +++ b/arch/arm64/kernel/acpi-osi.c
>> @@ -0,0 +1,25 @@
>> +/*
>> + *  ARM64 Specific ACPI _OSI Support
>> + *
>> + *  Copyright (C) 2015, Linaro Ltd.
>> + *	Author: Al Stone <al.stone@...aro.org>
>> + *
>> + *  This program is free software; you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License version 2 as
>> + *  published by the Free Software Foundation.
>> + */
>> +
>> +#define pr_fmt(fmt) "ACPI: " fmt
>> +
>> +#include <linux/acpi.h>
>> +
>> +/*
>> + * Consensus is to deprecate _OSI for all new ACPI-supported architectures.
>> + * So, for arm64, reduce _OSI to a warning message, and tell the firmware
>> + * nothing of value.
>> + */
>> +u32 acpi_osi_handler(acpi_string interface, u32 supported)
>> +{
>> +	pr_warn("_OSI was called, but is deprecated for this architecture.\n");
>> +	return false;
>> +}
> 
> This kinda feels backwards to me. If _OSI is going away, then the default
> should be "the architecture doesn't need to do anything", rather than have
> new architectures defining a bunch of empty, useless stub code.
> 
> Anyway we could make this the default in core code and have architectures
> that *do* want _OSI override that behaviour, instead of the other way around?
> 
> Cheers,
> 
> Will
> 

We could do that; I personally don't have a strong preference either way,
so I'm inclined to make it whatever structure Rafael thinks is proper since
it affects ACPI code most.  That being said, the current patch structure
made sense to me since it wasn't distorting existing code much -- and given
the pure number of x86/ia64 machines vs ARM machines using ACPI, that seemed
the more cautious approach.

@Rafael: do you have an opinion/preference?

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone@...aro.org
-----------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/