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
| ||
|
Message-ID: <20140814102723.GB9039@arm.com> Date: Thu, 14 Aug 2014 11:27:23 +0100 From: Catalin Marinas <catalin.marinas@....com> To: Hanjun Guo <hanjun.guo@...aro.org> Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, Olof Johansson <olof@...om.net>, Mark Rutland <Mark.Rutland@....com>, Arnd Bergmann <arnd@...db.de>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Mark Brown <broonie@...aro.org>, Will Deacon <Will.Deacon@....com>, Lv Zheng <lv.zheng@...el.com>, Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>, Daniel Lezcano <daniel.lezcano@...aro.org>, Robert Moore <robert.moore@...el.com>, "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, "grant.likely@...aro.org" <grant.likely@...aro.org>, Charles Garcia-Tobin <Charles.Garcia-Tobin@....com>, Robert Richter <rric@...nel.org>, Jason Cooper <jason@...edaemon.net>, Marc Zyngier <Marc.Zyngier@....com>, Liviu Dudau <Liviu.Dudau@....com>, Bjorn Helgaas <bhelgaas@...gle.com>, "graeme.gregory@...aro.org" <graeme.gregory@...aro.org>, Randy Dunlap <rdunlap@...radead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Sudeep Holla <Sudeep.Holla@....com> Subject: Re: [PATCH 19/19] Documentation: ACPI for ARM64 On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote: > On 2014-8-14 7:41, Rafael J. Wysocki wrote: > > On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote: > >> If we consider ACPI unusable on ARM but we still want to start merging > >> patches, we should rather make the config option depend on BROKEN > >> (though if it is that unusable that no real platform can use it, I would > >> rather not merge it at all at this stage). > > > > I agree here. > > > > I would recommend creating a separate branch for that living outside of the > > mainline kernel and merging it when there are real users. > > Real users will coming soon, we already tested this patch set on real hardware > (ARM64 Juno platform), I don't consider Juno a server platform ;) (but it's good enough for development). > and I think ARM64 server chips and platforms will show up before 3.18 > is released. That's what I've heard/seen. The questions I have are (a) whether current ACPI patchset is enough to successfully run Linux on such _hardware_ platform (maybe not fully optimised, for example just WFI cpuidle) and (b) whether we still want to mandate a DT in the kernel for such platforms. Given the answer to (a) and what other features are needed, we may or may not mandate (b). We were pretty clear few months ago that (b) is still required but at the time we were only openly talking about ACPI 5.0 which was lacking many features. I think we need to revisit that position based on how usable ACPI 5.1 for ARM (and current kernel implementation) is. Would you mind elaborating what an ACPI-only platform miss? I would expect a new server platform designed with ACPI in mind to require minimal SoC specific code, so we may only see a few patches under drivers/ for such platforms adding ACPI-specific probing (possibly new drivers as well if it's a new component). > For this patch set, DT is the first class citizen at now: > > a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only; Not just off but, based on maturity, depend on EXPERT. > b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal: > > - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now), > ACPI will disabled in the very early stage and FDT will still to be > unflattened, so will not break DT booting. > > - We can pass ACPI=off to disable ACPI and use DT even if we got valid > ACPI tables (in the v1 patch set); > > So it is safe for people who want to use DT, and didn't change any behavior > of DT booting except some extra test of if(acpi_disabled). But should we require SoC firmware to provide both valid DT and ACPI tables so that the user can decide which one to select at boot-time? -- 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/
Powered by blists - more mailing lists