linux-kernel - Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)

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] [day] [month] [year] [list]

Message-ID: <53FFDABE.3000507@ahsoftware.de>
Date:	Fri, 29 Aug 2014 03:43:26 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Catalin Marinas <catalin.marinas@....com>
CC:	Stephen Warren <swarren@...dotorg.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Mark Rutland <Mark.Rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Jon Loeliger <jdl@....com>,
	Russell King <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Thierry Reding <thierry.reding@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization
 order based on the DT)

Am 28.08.2014 11:23, schrieb Catalin Marinas:
> On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote:

>> And I wonder how the ACPI world solves that problem. My guess would be
>> hardcoded stuff in the firmware-blob (BIOS), just like it happened with
>> board files, but I've never seen BIOS code and my knowledge about ACPI
>> is almost zero. ;)
>
> ACPI doesn't even attempt to solve such problems at the OS level. SoCs
> aimed at ACPI should have simple hardware configuration (from a Linux
> perspective) initialised by firmware (e.g. clocks) and devices living on
> a standard bus like PCIe. If a SoC requires specific low-level code to
> initialise the hardware in a specific order (other than architected
> peripherals like GIC, timers; e.g. MFD devices), we should deem it
> unsuitable for ACPI.
>
> ACPI should only be used by vendors who know exactly why they need and
> how to implement it properly and not just because the marketing
> department told them to (it would also be nice if the Linux kernel
> community was informed about such reasons).

Hmm, Jon Masters from Red Hat sounds too like UEFI/ACPI is the way to go.

But maybe he's right and hiding ugly code in proprietary/binary firmware 
blobs where no one can see and criticize it is really the way to go.

Personally I think it's a way back to the past ("when everything was 
better", at least that is what most human brains do like to suggest) and 
just a dream. And I don't believe that the stuff which was and is hidden 
away always just works and doesn't need fixes (one can't do themself). 
In my humble opinion that's a nice but wrong myth and doesn't take into 
consideration that HW (and SW) gets more and more complicated too (and 
thus more faulty).

And even the biggest companies already have problems to produce stuff
which just works (they just employ humans too), not to speak from 
smaller board vendors. So it's much better to keep the source as visible 
as possible to as much people as possible (in the OS) and not to rely on 
some binary blob as most BIOSes are.

Regards,

Alexander Holler
--
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/