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=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 BE6ECC2D0E7 for ; Wed, 25 Mar 2020 21:54:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 930AF20658 for ; Wed, 25 Mar 2020 21:54:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mKFgJFE4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727452AbgCYVyi (ORCPT ); Wed, 25 Mar 2020 17:54:38 -0400 Received: from mail-il1-f193.google.com ([209.85.166.193]:35410 "EHLO mail-il1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727357AbgCYVyi (ORCPT ); Wed, 25 Mar 2020 17:54:38 -0400 Received: by mail-il1-f193.google.com with SMTP id 7so3473908ill.2; Wed, 25 Mar 2020 14:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VIiYOE3oW3daBE6BLhIhLcjzmOFraPbTpEHLXt6kzBg=; b=mKFgJFE4ToVuPC46SoR2yVv6yR7yJw9vZst20tYWm7bnMdJR7JJoLwfjuf3AVcnp1t PQ2UIWWVzBy5uXt98cEm9u5klaglbb0Mq69HVhOrCMhm6RVrEWBF2guw5deZOlB/WbHm 0QXdBL5Qck2EwPHaG27MkHc8b8TzpBqMdwiJmpY5Q6ouGjU6Cg9eKgEq3Phr0/WC+bdI rHX6W5OyQbjE6bI7Nll3Rsi4sUJyZkZhextwTktFkrIkWmNjM+uO8wG1Em/Y5yvj9YGf YuyPu+3RSksL6ViYJ3boBWwcHGissVHA0rVL39CJVswsSxXgpuJXbL5rQMNb4mMvm7KU kUog== 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=VIiYOE3oW3daBE6BLhIhLcjzmOFraPbTpEHLXt6kzBg=; b=da1P1djQpFwZNMRxc3olieFoeVWwzuc/oDFbdGJ7UpgJjOXZTsFySYwy6eisooWciH Awqv9EXMxzBDGCDf0iAMJ8r2ZxPGa/jfkUgbuA3Z29kQUNW7hjbmJYryvMAWDrBdb8dr GbCo0r2I4bc3NEjMJsGlLSsvWqii8vwgnufcAFal26ISYxH/mU+5XQ++Vg1bgGRjS60w Umn0mBk044405ehQAVKf7T3YstRsiuo8st2n1RN/y7fT2qP7pi+hdIfQ0yYuBAVFXNdi EkC1Wnn+u6po2OKv5aAiWg9+2Akh6ahwCQE7XiQ+W3L4rO/ZlyBKOzQDYl9oWGWPs29k wa6A== X-Gm-Message-State: ANhLgQ0M3AsKkit2RshgtSZfdzlV5Emlt69qncQFBtb0MZt1PXTXY8Q3 +EmRzsYGfLUPEOfO1BAIgV+C9rD6s1Cbujw72MnqnQ== X-Google-Smtp-Source: ADFU+vvNX/Ir5Q4Of+TQ74ktMmPGivB3tdbs8dqgVQo2v3SDb+bnd7Kgc9bAoSm76mhL40G0rK0I9goh/p8wbOf6O1w= X-Received: by 2002:a05:6e02:589:: with SMTP id c9mr4549187ils.33.1585173277416; Wed, 25 Mar 2020 14:54:37 -0700 (PDT) MIME-Version: 1.0 References: <20200302020757.551483-1-bjorn.andersson@linaro.org> In-Reply-To: From: Jeffrey Hugo Date: Wed, 25 Mar 2020 15:54:26 -0600 Message-ID: Subject: Re: [PATCH] arm64: dts: qcom: sdm845-mtp: Relocate remoteproc firmware To: Arnd Bergmann Cc: Bjorn Andersson , Andy Gross , Rob Herring , linux-arm-msm , DTML , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 25, 2020 at 3:13 PM Arnd Bergmann wrote: > > On Mon, Mar 2, 2020 at 3:09 AM Bjorn Andersson > wrote: > > > > Update the firmware-name of the remoteproc nodes to mimic the firmware > > structure on other 845 devices. > > > > Signed-off-by: Bjorn Andersson > > --- > > arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 7 +++++++ > > 1 file changed, 7 insertions(+) > > Hi Bjorn, > > Sorry for the late reply, I only came across this one while going > through the pull requests > that we had failed to pick up earlier. > > I really dislike the idea of hardcoding a firmware name in the > devicetree, we had long > discussions about this a few years ago and basically concluded that the firmware > name needs to be generated by the driver after identifying the hardware itself. > > The problem is that the firmware generally needs to match both the device driver > and the hardware, so when there is a firmware update that changes the behavior > (intentionally or not) in a way the driver needs to know about, then > the driver should > be able to request a particular firmware file based on information > that the owner > of the dtb may not have. Interesting, this intersects some work I plan on doing. What level information did this discussion assume that the device driver had? Do you have a reference to the discussion handy? Please correct me if I am wrong, but this seems to assume that for device X, there is one firmware at a specific version that the driver is then knowledgeable about, and the driver can query the device hardware in some way to determine what is appropriate. It seems like this assumption is believed to hold true, no matter what system X is included in. I think we have the problem where likely impossible that the driver will know what firmware is valid. Qualcomm, for better or worse, has a signing process for their images. This establishes a root a trust which is enforced by hardware. For example, the Modem subsystem (the part of the SoC that talks to cell towers and such) will not run an image which is not properly signed. The valid signature is burned into the chip. "Surely there is one signed image for a particular modem on a specific SoC?" Sadly, no. The OEM is allowed to provide their own key. This may be a key which is specific to the device (Ie the Brand XYZ Model 123 phone). Therefore, that device will only run the firmware that contains that OEM's signature, even if the actual code happens to be identical to what every other OEM has. For some SoCs which go into multiple products, there seem to be several OEMs which are willing to allow the firmware to be included in the linux-firmware project. Therefore, it is likely that there will be multiple copies of the Modem image for the 845 SoC (for example) in /lib/firmware. In this case, it seems like your recommendation is that the driver should somehow detect that it is running on device 123 and not device 456, and therefore be able to request the device 123 specific firmware. I don't know how the device driver is supposed to make that determination, and its my opinion that the driver shouldn't be. Other than the need to have the correct firmware, which is tied to the specific device, I'm not aware of an instance where a driver cares about anything more than the hardware revision of the block it drives.