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

Date:	Thu, 28 Aug 2014 10:23:08 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Alexander Holler <holler@...oftware.de>
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)

On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote:
> Am 27.08.2014 18:37, schrieb Stephen Warren:
> > Of course, there are probably cases where we could/should add some more
> > phandles/... and likewise cases where we shouldn't. That's why detailed
> > research is needed.
> 
> Just because I'm curious, I wonder how this research does or shoud look 
> like.
> 
> Defered probes did come to light with 3.4, that was more than 2 years 
> ago. Ok, most people (like me) just noticed it during the last months 
> when they switched to DT and have run into a problem (the deferred probe 
> mechanism is an error-message killer), but some must have seen it 
> already 2 years ago.
> 
> 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).

-- 
Catalin
--
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/