linux-kernel - Re: [PATCH v5 18/18] Documentation: ACPI for ARM64

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:	Thu, 18 Dec 2014 14:04:02 -0600
From:	Timur Tabi <timur@...eaurora.org>
To:	Hanjun Guo <hanjun.guo@...aro.org>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Mark Rutland <mark.rutland@....com>,
	Olof Johansson <olof@...om.net>,
	Grant Likely <grant.likely@...aro.org>,
	Will Deacon <will.deacon@....com>,
	Graeme Gregory <graeme.gregory@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Sudeep Holla <Sudeep.Holla@....com>,
	Jon Masters <jcm@...hat.com>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <marc.zyngier@....com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
	Robert Richter <rric@...nel.org>,
	Lv Zheng <lv.zheng@...el.com>,
	Robert Moore <robert.moore@...el.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Liviu Dudau <Liviu.Dudau@....com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Charles.Garcia-Tobin@....com, Kangkang.Shen@...wei.com,
	linux-acpi@...r.kernel.org,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linaro-acpi@...ts.linaro.org, Al Stone <al.stone@...aro.org>
Subject: Re: [PATCH v5 18/18] Documentation: ACPI for ARM64

On Fri, Oct 17, 2014 at 8:37 AM, Hanjun Guo <hanjun.guo@...aro.org> wrote:

> If acpi=force is used, the kernel
> +will ONLY use device configuration information contained in the ACPI tables.

Based on this statement, ...

> +In order for the kernel to load and use ACPI tables, the UEFI implementation
> +MUST set the ACPI_20_TABLE_GUID to point to the RSDP table (the table with
> +the ACPI signature "RSD PTR ").  If this pointer is incorrect and acpi=force
> +is used, the kernel will disable ACPI and try to use DT to boot.

wouldn't it be more correct to say "If this pointer is incorrect OR
acpi=force is used"?

> +Forum provides a mechanism for registering such bindings [URL TBD by ASWG]

Did you intend to replace the text in []?

> +so that they may be used on any operating system supporting ACPI.  Device
> +properties that have not been registered with the UEFI Forum should not be
> +used.

Blech.  I guess it's necessary, but the information needs to be documented here.

> +Drivers should look for device properties in the _DSD object ONLY; the _DSD
> +object is described in the ACPI specification section 6.2.5, but more
> +specifically, use the _DSD Device Properties UUID:
> +
> +   -- UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
> +
> +   -- http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf)

Extra ) here.

> +The kernel has an interface for looking up device properties in a manner
> +independent of whether DT or ACPI is being used and that interface should
> +be used; it can eliminate some duplication of code paths in driver probing
> +functions and discourage divergence between DT bindings and ACPI device
> +properties.

How about a pointer to the documentation for this method?

> +Such code in _PS? methods will of course be very platform specific.  But,

I would use _PSx instead of _PS? here.

> +this allows the driver to abstract out the interface for operating the device
> +and avoid having to read special non-standard values from ACPI tables. Further,
> +abstracting the use of these resources allows the hardware to change over time
> +without requiring updates to the driver.
> +
> +
> +Clocks
> +------
> +ACPI makes the assumption that clocks are initialized by the firmware --
> +UEFI, in this case -- to some working value before control is handed over
> +to the kernel.  This has implications for devices such as UARTs, or SoC
> +driven LCD displays, for example.

SOC-driven should be hyphenated.

> +When the kernel boots, the clock is assumed to be set to reasonable

to A reasonable

> +working value.  If for some reason the frequency needs to change -- e.g.,
> +throttling for power management -- the device driver should expect that
> +process to be abstracted out into some ACPI method that can be invoked
> +(please see the ACPI specification for further recommendations on standard
> +methods to be expected).  If is not, there is no direct way for ACPI to

If IT is not

> +control the clocks.
> +
> +
> +Driver Recommendations
> +----------------------
> +DO NOT remove any DT handling when adding ACPI support for a driver.  The
> +same device may be used on many different systems.
> +
> +DO try to structure the driver so that it is data driven.  That is, set up

data-driven


-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
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/