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
| ||
|
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/
Powered by blists - more mailing lists