From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A64DEC0650E for ; Wed, 3 Jul 2019 16:33:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 738142187F for ; Wed, 3 Jul 2019 16:33:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="SqQC20u2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727200AbfGCQdP (ORCPT ); Wed, 3 Jul 2019 12:33:15 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:39011 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727074AbfGCQdP (ORCPT ); Wed, 3 Jul 2019 12:33:15 -0400 Received: by mail-wr1-f66.google.com with SMTP id x4so3542271wrt.6 for ; Wed, 03 Jul 2019 09:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=AWfKUBqVWZzAawswGY+ZSjKKRhaQkfyUJM16meMSkPo=; b=SqQC20u2dDoRyp5jcv3M6XGoifJsMIxnNea7QFL8/kVvb2UCAA8flUyKrqI9ejZsxZ kU2lTzUeRu2H0DRUt9A/+YcW0WKC5DXZvqhA47BbU1PJov63d4B7xFHu0rxghzEBubbZ fkMx1vyy/KTqcrRxJ+wHbzR2RcWI1bsuYQcvYx643PjJlTEsXtRRS7kMcAVARcFXauGR aiyn9SU9SWjPsZCxZay9+2jPSeswBVq0FudAScZpXG6CCQBNvCRRCMx6Rv+uQbeWlscd Okt/CDrAd7xyJqLMP7lTdjQCS5owlIquNQtdAenesffTZrDbAuwzfwfl/va0He7LjOa8 g+YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=AWfKUBqVWZzAawswGY+ZSjKKRhaQkfyUJM16meMSkPo=; b=UZ8lvowKarJqiq0y7ri9T/j1VRexPW6Buo88W++IM46oFt22G3yJXiX/SKhv9JCjhp lAyGSK/U3vUTprUprwn5xiW3g/qnIJDRB2l3/nP9Gry/uKDmEHcKFDBaqMdUfqHfEkMW 7xM2/8ELY+5oQlDCVqwbhLLxollcD2debX9nQsNuZYiG6bZNpGOcCbMzBESmpNp0KUNy ZxKRPgp12qVKhpLvjbtHY1NDVmgLBocRfF4ppox45WWRiFmA6TJUh0EWGmJhg5JHH+YZ wPBKH/OqWQCtkSVUD3WJ8NPCEih1GjZparSQ+tN6vvy8V/ajhAzidI41Uz2esSsDhtqN SBQg== X-Gm-Message-State: APjAAAW/d9mJmAExaGY7NcKCn41sdrzNPP1X1TylcSNMCUQa59R7Jqdu yg8y2v37pbN2PeF/FGd+ifeJLA== X-Google-Smtp-Source: APXvYqzyUKfEjD5zZwvYgn+6s0isuDDnar2rnm433earCTxIt7v2XJpN1VkPtyIJdyIZ37VlPS+lgw== X-Received: by 2002:a5d:438f:: with SMTP id i15mr24566996wrq.37.1562171594030; Wed, 03 Jul 2019 09:33:14 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id x11sm1849858wmi.26.2019.07.03.09.33.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Jul 2019 09:33:13 -0700 (PDT) Date: Wed, 3 Jul 2019 17:33:11 +0100 From: Leif Lindholm To: Rob Clark Cc: Ard Biesheuvel , dri-devel , linux-arm-msm , freedreno , aarch64-laptops@lists.linaro.org, Rob Clark , Ingo Molnar , Will Deacon , Steve Capper , Lukas Wunner , Julien Thierry , linux-efi , Linux Kernel Mailing List Subject: Re: [PATCH 2/4] efi/libstub: detect panel-id Message-ID: <20190703163311.gtbo72dzpkpjvpi5@bivouac.eciton.net> References: <20190630203614.5290-1-robdclark@gmail.com> <20190630203614.5290-3-robdclark@gmail.com> <20190702215953.wdqges66hx3ge4jr@bivouac.eciton.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, Jul 02, 2019 at 03:48:48PM -0700, Rob Clark wrote: > > > There is one kernel, and there > > > are N distro's, so debugging a users "I don't get a screen at boot" > > > problem because their distro missed some shim patch really just > > > doesn't seem like a headache I want to have. > > > > The distros should not need to be aware *at all* of the hacks required > > to disguise these platforms as DT platforms. > > > > If they do, they're already device-specific installers and have > > already accepted the logistical/support nightmare. > > I guess I'm not *against* a DT loader shim populating the panel-id > over into /chosen.. I had it in mind as a backup plan. Ofc still need > to get dt folks to buy into /chosen/panel-id but for DT boot I think > that is the best option. (At least the /chosen/panel-id approach > doesn't require the shim to be aware of how the panel is wired up to > dsi controller and whether their is a bridge in between, and that > short of thing, so the panel-id approach seems more maintainable that > other options.) I am leaning like Ard towards preferring a configuration table though. That removes the question of no runtime services (needing to manually cache things, at least until EBBR 1.2 (?) is out and in use), and means we don't have to use different paths for DT and ACPI. Now we have UEFI in U-Boot, do we really need to worry about the non-UEFI case? > I am a bit fearful of problems arising from different distros and > users using different versions of shim, and how to manage that. I > guess if somehow "shim thing" was part of the kernel, there would by > one less moving part... Sure, but that's insurance against bindings changing non-backwards-compatibly - which there are ways to prevent, and which streamlining the design for really isn't the way to discourage... Distros have no need to worry about the DT loader - the whole point of it is to remove the need for the distro to worry about anything other than getting the required drivers in. > I'd know if user had kernel vX.Y.Z they'd be > good to go vs not. But *also* depending on a new-enough version of a > shim, where the version # is probably not easily apparent to the end > user, sounds a bit scary from the "all the things that can go wrong" > point of view. Maybe I'm paranoid, but I'm a bit worried about how to > manage that. Until the hardware abstractions provided by the system firmware (ACPI) is supported, these platforms are not going to be appropriate for end users anyway. No matter how many not-quite-upstream hacks distros include, they won't be able to support the next minor spin that comes off the production line and is no longer compatible with existing DTs. / Leif