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:	Wed, 04 Feb 2015 17:41:40 +0800
From:	Hanjun Guo <hanjun.guo@...aro.org>
To:	Al Stone <al.stone@...aro.org>, Mark Rutland <mark.rutland@....com>
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 2015年02月04日 01:43, Al Stone wrote:
> 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.

If we are not worrying about too much patch in this series, I can
cherry-pick Mark Salter's ACPI PMU patch for Seattle in next version.

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