On Thu, Apr 16, 2015 at 11:21 AM, Catalin Marinas <catalin.marinas@xxxxxxx> 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 >> <catalin.marinas@xxxxxxx> 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
