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, 17 May 2016 10:30:34 -0600
From:	Al Stone <>
To:	Alexey Klimov <>, Al Stone <>
Subject: Re: [PATCH v5 0/1] ARM64: ACPI: Update documentation for latest
 specification version

On 05/16/2016 05:44 PM, Alexey Klimov wrote:
> On Mon, May 2, 2016 at 09:19 PM, Al Stone wrote:
>> On 04/25/2016 03:21 PM, Al Stone wrote:
>>> The ACPI 6.1 specification was recently released at the end of January
>>> 2016, but the arm64 kernel documentation for the use of ACPI was written
>>> for the 5.1 version of the spec.  There were significant additions to the
>>> spec that had not yet been mentioned -- for example, the 6.0 mechanisms
>>> added to make it easier to define processors and low power idle states,
>>> as well as the 6.1 addition allowing regular interrupts (not just from
>>> GPIO) be used to signal ACPI general purpose events.
>>> This patch reflects going back through and examining the specs in detail
>>> and updating content appropriately.  Whilst there, a few odds and ends of
>>> typos were caught as well.  This brings the documentation up to date with
>>> ACPI 6.1 for arm64.
>>> Changes for v5:
>>>    -- Miscellaneous typos and corrections (Lorenzo Pieralisi)
>>>    -- Add linux-acpi@ ML to the distribution list (Alexey Klimov)
>>>    -- Corrections to CPPC information (Alexey Klimov)
>>>    -- ACK from Lorenzo Pieralisi
>>>    -- Updated bibliographic info (Al Stone)
>>> Changes for v4:
>>>    -- Clarify that IORT can sometimes be optional (Jon Masters).
>>>    -- Remove "Use as needed" descriptions of ACPI objects; they provide
>>>       no substantive information and doing so simplifies maintenance of
>>>       this document over time.  These have been replaced with a simpler
>>>       notice that states that unless otherwise noted, do what the ACPI
>>>       specification says is needed.
>>>    -- Corrected the _OSI object usage recommendation; it described kernel
>>>       behavior that does not exist (Al Stone).
>>> Changes for v3:
>>>    -- Clarify use of _LPI/_RDI (Vikas Sajjan)
>>>    -- Whitespace cleanup as pointed out by checkpatch
>>> Changes for v2:
>>>    -- Clean up white space (Harb Abdulhahmid)
>>>    -- Clarification on _CCA usage (Harb Abdulhamid)
>>>    -- IORT moved to required from recommended (Hanjun Guo)
>>>    -- Clarify IORT description (Hanjun Guo)
>>> Al Stone (1):
>>>   ARM64: ACPI: Update documentation for latest specification version
>>>  Documentation/arm64/acpi_object_usage.txt | 343 ++++++++++++++++--------------
>>>  Documentation/arm64/arm-acpi.txt          |  40 ++--
>>>  2 files changed, 213 insertions(+), 170 deletions(-)
>> Ping?  If there are no further comments, can this be pulled in through
>> either the documentation or arm64 tree?
>> Thanks.
> Hi Al,
> sorry for delay.
> CPPC and PCC corrections look fine. Thanks.
> This comment is not to block your patch (maybe some to-do):
> I greped sources and your patch and I don't see description of _PSD object.
> This P-state dependancy object is optional but it's presense and correct data
> are extremely useful for CPPC and can potentially descrease number of performance
> changing requests.
> ACPI spec in section about CPPC tells that it may use _PSD (page 503 if I remember
> correctly) to specify domain belongings of CPUs.
> You may consider to add description of _PSD object later.
> Best regards,
> Alexey.

Hrm.  Thanks, Alexey.  I'll take a look.  _PSD may be in one of
the gray areas where we expect people to read the spec and follow
it properly, but it may make sense to be very explicit about what
they need to do to use it properly.  Perhaps this would make a good
FWTS test, too.

Al Stone
Software Engineer
Linaro Enterprise Group

Powered by blists - more mailing lists