linux-kernel - Re: [Linaro-acpi] [RFC PATCH for Juno 1/2] net: smsc911x add support for probing from 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: <20140902162606.GX29327@sirena.org.uk>
Date:	Tue, 2 Sep 2014 17:26:06 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linaro-acpi@...ts.linaro.org,
	Catalin Marinas <catalin.marinas@....com>,
	Graeme Gregory <gg@...mlogic.co.uk>,
	Liviu Dudau <Liviu.Dudau@....com>,
	Lv Zheng <lv.zheng@...el.com>, Rob Herring <robh@...nel.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Robert Moore <robert.moore@...el.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Robert Richter <rric@...nel.org>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Will Deacon <Will.Deacon@....com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.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] [RFC PATCH for Juno 1/2] net: smsc911x add support
 for probing from ACPI

On Tue, Sep 02, 2014 at 03:42:53PM +0200, Arnd Bergmann wrote:

> The way I recall the discussion, most people were on one extreme
> side of the discussion or the other:

> a) We should use _DSD for ARM64 servers to maximize code reuse with
> DT-enabled drivers, work around the slow UEFI standardization process,
> remain in control of the actual bindings, and avoid the need for
> endless per-ID platform-data definitions in drivers.

> b) We should never use _DSD at all, since doing that would have no
> advantage over using DT directly, and we should force every device
> manufacturer to specify their bindings in an official ACPI document
> to prevent random incompatible bindings from being established.
> Any device that shows up in servers should not need arbitrary detailed
> properties anyway, as the details are supposed to be hidden in AML.

> I can understand the reasons for both approaches, and I find it hard
> to say either one is invalid. However, the worst possible outcome in
> my opinion would be having to support a mix of the two.

Right, and the x86 embedded folks are going full steam ahead with _DSD
regardless so it seems there will be some systems out there using it
even if they're not ARM servers.

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)