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=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 A8F4DC5B57D for ; Wed, 3 Jul 2019 00:41:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 812F3218AD for ; Wed, 3 Jul 2019 00:41:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="SK3VY71b" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727212AbfGCAlV (ORCPT ); Tue, 2 Jul 2019 20:41:21 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:36343 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726963AbfGCAlV (ORCPT ); Tue, 2 Jul 2019 20:41:21 -0400 Received: by mail-wr1-f67.google.com with SMTP id n4so701532wrs.3 for ; Tue, 02 Jul 2019 17:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F9/H9RAoH6E0au9JZUxTVdK2VUAjq3U7v2tg4NjLm2E=; b=SK3VY71b9UfihRePdJGtKBSdbFrEGcoMgA1+oLMpx0UPe6Zi3uDRyGD2EMNmRcqIq+ l0yxeXPdzy0dawH3rtJ13sku4q+pHqx7YfCt0T/4f0C1De+u9h4Kz7vk989kCRBNZ824 mTFjAk2XxdC4yvnm3rbUtw188u5UCkTkf8iB9ychSLYnKHzkYHKzxWzg/0qF5Kfv/9Ig /GrTrehl6RSlBv6Ck2krL2WRej8+bAHwkMfScnrp4Eezc+lmMKJpg/mT/Sg9laJXC7bT NPJ2fF2dt1HcWXS/Ex0YgUuMz0yKlYeezBAJ9Kv3upJ4MbSyUkw1RN7KepizvqV+xWfx 5AhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F9/H9RAoH6E0au9JZUxTVdK2VUAjq3U7v2tg4NjLm2E=; b=BaZiqj40ayKWKqXsZal7XgFbZdLDh8RmrhhclQ5Qo8yb2v6rtzrueqC3/tsNol5lP2 NDJeDERJRI/WdogtA7FykwsKyXg/DVsXfSkXAxRMXWD3FjsrQjvLuuD66NmZGKtBNfou +UwAM6RUsemaBZOOYmCU8bF0MAB7q0c9HGMriEX34oEROb3s5K8ZYr5t9wdBIhjEx3Mj 7Pz+gA3cGU0UzHNkMkSkVd3yC910OzE59TF7l1nWmHouodifJmtTQyyzlxEdP1UI7Vug Dz1eb+ChjaYp4MktxdE3ouRMNfc3C4/JlHlti739k1tUvzYmejHb21egfCKRxbl3O9rY kNhw== X-Gm-Message-State: APjAAAUsaU1KY+ugOI6hVYBSwDWff5XSiVlk8aYHmj6/FEU18IJXMJhS YAav6QY9RMRNsRqf5MNByEVC6ZNDhY7ELPst/DcGzh0Rsd0= X-Google-Smtp-Source: APXvYqwncd3iUgHVxdaYlFV1ID7X2V0/XLGwEniTYBbvfKVWOvdTx6vknWmPXyn5a8WQ1T7hGJ+i80nMqSq/lFM6R0k= X-Received: by 2002:a5d:6743:: with SMTP id l3mr14273796wrw.241.1562104410996; Tue, 02 Jul 2019 14:53:30 -0700 (PDT) MIME-Version: 1.0 References: <20190630203614.5290-1-robdclark@gmail.com> <20190630203614.5290-3-robdclark@gmail.com> In-Reply-To: From: Ard Biesheuvel Date: Tue, 2 Jul 2019 23:53:16 +0200 Message-ID: Subject: Re: [PATCH 2/4] efi/libstub: detect panel-id To: Rob Clark Cc: dri-devel , linux-arm-msm , freedreno , aarch64-laptops@lists.linaro.org, Rob Clark , Ingo Molnar , Will Deacon , Leif Lindholm , Steve Capper , Lukas Wunner , Julien Thierry , linux-efi , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, 2 Jul 2019 at 23:02, Rob Clark wrote: > > On Tue, Jul 2, 2019 at 1:35 PM Ard Biesheuvel wrote: > > > > On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel wrote: > > > > > > On Sun, 30 Jun 2019 at 22:36, Rob Clark wrote: > > > > > > > > From: Rob Clark > > > > > > > > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided > > > > to communicate some information about the display. Crutially it has the > > > > panel-id, so the appropriate panel driver can be selected. Read this > > > > out and stash in /chosen/panel-id so that display driver can use it to > > > > pick the appropriate panel. > > > > > > > > Signed-off-by: Rob Clark > > > > > > Hi Rob, > > > > > > I understand why you are doing this, but this *really* belongs elsewhere. > > > > > > So we are dealing with a platform that violates the UEFI spec, since > > > it does not bother to implement variable services at runtime (because > > > MS let the vendor get away with this). > > > > > > > To clarify, the above remark applies to populating the DT from the OS > > rather than from the firmware. > > yeah, it isn't pretty, but there *are* some other similar cases where > efi-stub is populating DT.. (like update_fdt_memmap() and > kaslr-seed).. > True, but those don't describe the hardware. > it would be kinda nice to have an early-quirks mechanism where this > could fit, but I thought that might be equally unpopular ;-) > Very :-) > > > > > First of all, to pass data between the EFI stub and the OS proper, we > > > should use a configuration table rather than a DT property, since the > > > former is ACPI/DT agnostic. Also, I'd like the consumer of the data to > > > actually interpret it, i.e., just dump the whole opaque thing into a > > > config table in the stub, and do the parsing in the OS proper. > > > > > > However, I am not thrilled at adding code to the stub that > > > unconditionally looks for some variable with some magic name on all > > > ARM/arm64 EFI systems, so this will need to live under a Kconfig > > > option that depends on ARM64 (and does not default to y) > > I defn can add this under kconfig.. is it ok if that option is > select'd by ARCH_QCOM? > I guess some mobile SOC/snapdragon symbol would be more appropriate, but given that qcom left the server business, I guess it hardly matters, so default y if ARM64 && ARCH_QCOM is fine with me > (Just trying to minimize the things that can go wrong and the "I get a > blank screen at boot" bug reports I get ;-)) > Sure > > ... but saving variables at boot time for consumption at runtime is > > something that we will likely see more of in the future. > > I think this will be nice, but it also doesn't address the need for a > quirk to get this into /chosen.. I guess we *could* use a shim or > something that runs before the kernel to do this. But that just seems > like a logistical/support nightmare. 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. > I'd argue that this does not belong in /chosen in the first place, i.e., it doesn't belong in the DT at all if the OS can access the config table (and therefore the variable) directly.