Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754691AbbDPRRk (ORCPT ); Thu, 16 Apr 2015 13:17:40 -0400 Received: from mail-qc0-f170.google.com ([209.85.216.170]:34098 "EHLO mail-qc0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753718AbbDPRRd (ORCPT ); Thu, 16 Apr 2015 13:17:33 -0400 MIME-Version: 1.0 In-Reply-To: <20150416152121.GE819@e104818-lin.cambridge.arm.com> References: <1428601031-5366-1-git-send-email-galak@codeaurora.org> <20150410100529.GA6854@e104818-lin.cambridge.arm.com> <20150414163613.GM28709@leverpostej> <07185B2C-3F37-4E70-9096-1EF5EA8D68CE@codeaurora.org> <20150414211720.GA56647@MBP> <20150415133403.GB26099@e104818-lin.cambridge.arm.com> <20150416152121.GE819@e104818-lin.cambridge.arm.com> Date: Thu, 16 Apr 2015 13:17:32 -0400 Message-ID: Subject: Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs From: Rob Clark To: Catalin Marinas Cc: Mark Rutland , "devicetree@vger.kernel.org" , "linux-arm-msm@vger.kernel.org" , Kumar Gala , Will Deacon , "linux-kernel@vger.kernel.org" , "arm@kernel.org" , "abhimany@codeaurora.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3742 Lines: 78 On Thu, Apr 16, 2015 at 11:21 AM, Catalin Marinas wrote: > On Wed, Apr 15, 2015 at 11:01:17AM -0400, Rob Clark wrote: >> On Wed, Apr 15, 2015 at 9:34 AM, Catalin Marinas >> wrote: >> > On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote: >> >> Just speaking as an outsider to this topic, but seems like most/all >> >> tablets/phones/etc ship with signed firmware. Which means for most of >> >> the population, upgrading the firmware to a new version which did >> >> support the standard (assuming it existed), isn't really an option on >> >> our devices, any more than fixing buggy acpi tables is on our >> >> laptops.. >> > >> > I wouldn't expect most population to build their own kernels on >> > tablets/phones. And even if you could install a custom kernel, mainline >> > rarely runs on such devices because of tons of out of tree patches (just >> > look at the Nexus 9 patches that Kumar pointed at; even ignoring the >> > booting protocol they are extremely far from an upstreamable form). >> >> my point being, that it happens some times.. for example John Stultz's >> work on nexus7: >> >> https://plus.google.com/111524780435806926688/posts/DzvpMLmzQiQ >> >> If this had been a year or two in the future and on some 64b >> snapdragon, and support for devices with non-PSCI fw is rejected, then >> he'd be stuck. >> >> There are folks who are working to get saner, more-upstream kernels >> working on devices.. and improving kernel infrastructure for >> device-needs (well, in my neck of the woods, there is drm/kms atomic >> and dsi/panel framework stuff.. I'm sure other similar things in other >> kernel domains). And it seems like that is a good thing to encourage, >> rather than stymie. > > I'm not looking to discourage individuals trying to get upstream support > for older boards. Should the need arise, we'll look at options which may > or may not include kernel changes (e.g. wrap the kernel in a shim). I had wondered about that, but afaiu psci is a smc interface, and I would assume bootloader drops you out of secure mode before entering the kernel or whatever comes after first stage bootloader if you are chain-loading? So wasn't sure even how that could work.. (ofc, well outside of my areas so I could be quite off base) If there is a workaround, then I am much less concerned, and would rather talk about that :-) > But I'm definitely going to discourage companies like Qualcomm > deliberately ignoring the existing booting protocols while trying to get > their code upstream. This patch series is posted by Qualcomm without > providing any technical reason on why they don't want to/couldn't use > PSCI (well, I guess there is no technical reason but they may not care > much about mainline either). Sure.. just trying to make sure the wrong people don't end up being the ones that suffer. I would assume/expect that it is at least possible for qcom to change firmware/bootloader for their dev boards and future devices and whatnot, whether they grumble about it or not. But I guess most of what the general public has are devices w/ signed fw, which is why "go fix your firmware" is an option that sets off alarm bells for me. I guess the first device where this will matter to me and a large group of community folks would be the dragonboard 410c.. *hopefully* it does not require signed firmware or at least qcom could make available signed firmware which supports psci.. BR, -R > -- > Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/