linux-kernel - Re: [PATCH 00/36] AArch64 Linux kernel port

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:	Mon, 9 Jul 2012 16:46:33 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	grant.likely@...retlab.ca
Subject: Re: [PATCH 00/36] AArch64 Linux kernel port

On Mon, Jul 09, 2012 at 03:02:22PM +0100, Matthew Garrett wrote:
> On Mon, Jul 09, 2012 at 02:56:26PM +0100, Mark Brown wrote:

> > Where is this discussion?

> My part of it has pretty much been in-person discussion with Grant 
> Likely, but there was some on ksummit-discuss last month.

Oh, I saw some of the ksummit-discuss traffic but didn't register it as
a serious proposal to do something.

> > Right, but there's lots of bolierplate code with this stuff anyway and
> > it's not fundamentally hard.  Last time I looked at ACPI it had a rather
> > different model for how all this stuff would work than DT did which
> > isn't terribly helpful here.

> ACPI 5 lets devices expose their GPIO resources directly, so in some 
> cases a driver will just be able to request that and handle things as it 

Assuming the naming standard is the same and so on...  my understanding
was that it's difficult to get any sort of standardisation on ACPI
bindings for device drivers.

> would in ftd. But the more traditional ACPI method is to use ACPI 
> notifications, and those happen in process context. It seems unlikely 
> that everyone's going to get it right unless there's existing in-kernel 
> infrastructure for handling this.

Oh dear, that sounds awesome.

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