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.9 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 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 1EFF2C2D0E7 for ; Thu, 26 Mar 2020 00:08:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E125320714 for ; Thu, 26 Mar 2020 00:08:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="SBVg/zWs" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727647AbgCZAIE (ORCPT ); Wed, 25 Mar 2020 20:08:04 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:43814 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727498AbgCZAID (ORCPT ); Wed, 25 Mar 2020 20:08:03 -0400 Received: by mail-pf1-f194.google.com with SMTP id f206so1870734pfa.10 for ; Wed, 25 Mar 2020 17:08:01 -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; bh=D0CV0Uku18oFuW+TPNfaEyxgPkTMYFP8ObQ3tAgtOsc=; b=SBVg/zWsk52JKcc+nEzqXNzg7w+HdPM+lrL+HI2UtDuTis6PRGJW94M/+n13O7YFJ6 MkyiHnm+qz/wx068nDs7rRLD8Mxv0/d1wvd4ydeatxtcR8oeIo1jgdzPJWoBiWLOMy5D Sr7aD48oUo1BGco1e4RkKs/cV4d8PChb5tGcmIVWLw4+gCx6zjSNiIkgcushvn7efvzG 2NB35CZPdE1L9jj/4rXITMdF2rI03jjFSk5pQtNPgT9t6zFYfBB69DlnPNvdf0FaIVyh RdJT+9KPjhHtw68UyMFICMBQNtihr9TcRKOx34/0Fr0tHKLMzLfslUmpoZ/zH8vX9jx/ Av0w== 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; bh=D0CV0Uku18oFuW+TPNfaEyxgPkTMYFP8ObQ3tAgtOsc=; b=BWhblVWqBH2YWikQk/Ns5vpMHow1bgJ9juvtAXQY1UG9ucIanUgaJbpRUDhlqw0MMP kXB8MtjGqfa5NIVLNVrtYvxlL+3QvjOrh1RjRY1LevfPi/cdHPyaMJNzFQY7iWGKopet 5weqfr/TKbtZWXvpOCC36KCt+q6iLUPmhoy7LkfL0mYDsHV4X5NaRSzsu3I6q/AvFV6z GcrIOIxJhOXizZ/VYj7BmWg0UrFVR3fEo0HsKtetGyuuPeWgoHchThyFi2GvUnXcv2Jx 1GAqDTJ+F2nR33xckO2HcpzblLQvesLbHI6YT7na7ci5fQIbI2+MhCetJUEf/gpYaAXc 3PNA== X-Gm-Message-State: ANhLgQ0AI7tNtmC1MWWWwodK6juB7ba7VSSWYQvuvTzxte9uee64B4KM A6XLDbf4eK1FXJCPDRt+8EbOWA5uxQQ= X-Google-Smtp-Source: ADFU+vuIfUjtKDwe+/9IZoHaEyu52b65Fllav4Sg62s59kUgWWdWFkYrl4HvkTVxCVFhPIOx9IDLGA== X-Received: by 2002:a62:2e42:: with SMTP id u63mr6197087pfu.69.1585181280449; Wed, 25 Mar 2020 17:08:00 -0700 (PDT) Received: from minitux (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28]) by smtp.gmail.com with ESMTPSA id u12sm227537pfm.165.2020.03.25.17.07.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2020 17:07:59 -0700 (PDT) Date: Wed, 25 Mar 2020 17:07:57 -0700 From: Bjorn Andersson To: Arnd Bergmann Cc: Andy Gross , Rob Herring , linux-arm-msm , DTML , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] arm64: dts: qcom: sdm845-mtp: Relocate remoteproc firmware Message-ID: <20200326000757.GF119913@minitux> References: <20200302020757.551483-1-bjorn.andersson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed 25 Mar 14:13 PDT 2020, 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. > I remember this discussion and generally I share your view, but after postponing this problem for years we've not managed to come up with a solution for our problem. > 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. > There are three variables in play here: 1) Large feature differences, e.g. does your modem Hexagon have associated RF hardware, or is it WiFi only. Or other similar things, which does affect DeviceTree anyways (memory maps, audio routing etc) 2) Purely software versions of the firmware. Generally no impact on remoteproc level or the immediate layers above, bug fixes etc. 3) Vendor specific signatures. All these files are signed with vendor specific private keys. None of these affects how we describe the hardware, so we did choose to use a compatible per platform and remoteproc, e.g. qcom,sdm845-mss-pil will handle the modem core on all SDM845 devices, regardless of the firmware implementing WiFi only or it's a devboard or a product with strict signature validation. We could add another property in the DT node to denote if the modem RF hardware is present and have the sdm845-mss-pil compatible result in a selection of qcom/sdm845/modem.mbn vs qcom/sdm845/modem_nm.mbn. This would handle 1) above. But this doesn't solve 3) and my Lenovo Yoga C630 will refuse to load these files, as they are not signed by Lenovo. For years we've toyed with the idea of building the necessary firmware path based on e.g. information from DMI (which not all boards has) or somehow tokenizing the machine compatible. But nothing sane has come out of these attempts/ideas. So after years of not being able to send these files to linux-firmware, without breaking some other board we decided to just describe these variations using firmware-name. So this solves 1) and 3) in a straight forward way, and so far in all cases we've handled 2) by upgrading (until now, our fork of) linux-firmware. But I don't have any suggestions for how to solve the case where kernel version X and X+1 _needs_ different versions of the firmware. Lastly, most variations in firmware features are discoverable by the higher layers, but for the cases where the remoteproc driver itself is affected we're looking at changes to the memory map, clocks, regulators, power domains - problems that has to be resolved in DT anyways. Which is the reason why several companies are looking at passing dynamically loaded DT snippets with their remoteproc firmware. > I'm holding off on the pull request for today, maybe there is something we can > still do about it before the merge window. > The binding addition was merged in 5.1, with Rob's r-b, in 5.5 we used these properties for the Lenovo Yoga C630 and in 5.6 we merged the equivalent change for the Dragonboard 845c. If there is a solution that allow us to move away from firmware-name in DT I'm interested and would like to see us migrate towards it, but the only thing this particular change does is to make the SDM845 MTP find the right files in linux-firmware, using the already existing binding and implementation. Regards, Bjorn