linux-kernel - Re: [Linaro-acpi] [PATCH v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

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]

Date:	Tue, 03 Feb 2015 10:43:57 -0700
From:	Al Stone <al.stone@...aro.org>
To:	Mark Rutland <mark.rutland@....com>,
	Hanjun Guo <hanjun.guo@...aro.org>
CC:	Mark Langsdorf <mlangsdo@...hat.com>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	"wangyijing@...wei.com" <wangyijing@...wei.com>,
	Rob Herring <robh@...nel.org>,
	Timur Tabi <timur@...eaurora.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"phoenix.liyi@...wei.com" <phoenix.liyi@...wei.com>,
	Robert Richter <rric@...nel.org>,
	Jason Cooper <jason@...edaemon.net>,
	Arnd Bergmann <arnd@...db.de>,
	Marc Zyngier <Marc.Zyngier@....com>,
	"jcm@...hat.com" <jcm@...hat.com>, Mark Brown <broonie@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Ashwin Chaugule <ashwinc@...eaurora.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Olof Johansson <olof@...om.net>
Subject: Re: [Linaro-acpi] [PATCH v8 00/21] Introduce ACPI for ARM64 based
 on ACPI 5.1

On 02/03/2015 09:47 AM, Mark Rutland wrote:
> On Mon, Feb 02, 2015 at 12:45:28PM +0000, Hanjun Guo wrote:
>> Hi,
>>
>> This is the v8 of ACPI core patches for ARM64 based on ACPI 5.1, there are
>> some updates since v7:
>>
>>  - Add two more documantation to explain why we need ACPI in ARM64 servers
>>    by Grant, and recommendations and prohibitions on the use of the numerous
>>    ACPI tables and objects by Al Stone.
>>
>>  - Add two patches which is need to map acpi tables after acpi_gbl_permanent_mmap
>>    is set
>>
>>  - Add another patch "dt / chosen: Add linux,uefi-stub-generated-dtb property"
>>    to address that if firmware providing no dtb, we can try ACPI configuration data
>>    even if no "acpi=force" is passed in early parameters. (I think ACPI for XEN and
>>    kexec need consider sperately as disscussed, correct me if I'm wrong).
>>
>>  - Add CC in the patch to the subsystem maintainers and modify the subject
>>    of the patch to explicitly show the subsystem touched by this patch set,
>>    please help us to review and ack them if they make sense, thanks.
>>
>>  - Add Tested-by from Qualcomm and Redhat;
>>
>>  - Make ACPI depends on PCI suggested by Catalin;
>>
>>  - Clean up SMP init function as Lorenzo suggested, remove physical
>>    CPU hot-plug code in the patch;
>>
>>  - Address some comments from Marc and explicitly state that will
>>    implment statcked irqdomain and GIC init framework when GICv3 and
>>    ITS, GICv2m are implemented;
>>
>>  - Rebased on top of 3.19-rc7.
>>
>> previous version is here:
>> v7: https://lkml.org/lkml/2015/1/14/586
>> v6: https://lkml.org/lkml/2015/1/4/40
>>
>> Any comments are welcome :)
> 
> I note that for ACPI the PMU interrupt information is stored in the GICC
> (as "Performance Interrupt" and "Performance Interrupt Mode"), but I
> don't see any code for handling that as part of this series.
> 
> Is anyone currently looking into that?

Yes.  IIRC, it's a pretty small patch that I'll be including in the
Seattle patches that build on top of this core set.

> For those systems ACPI is being developed on do we know that the GICC
> information for the PMU interrupts is sane?

Yes.  We know this works for Seattle platforms, using their latest firmware.

> I'm slightly worried about the prospect of adding support later only to
> find that the performance interrupt data in contemporary GICC tables is
> invalid; it's going to be extremely painful to detect that being the
> case in order to perform any kind of workaround.

That will depend on the error, of course.  It was pretty straightforward
when the interrupt value was set to zero in some of the early tables we
used.

-- 
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/