linux-kernel - Re: [PATCH] arm64: dts: qcom: sdm845-mtp: Relocate remoteproc firmware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a1QZbpYV8juTb31-CXQMVF==qFjJdRd064Md_rw5V7Vnw@mail.gmail.com>
Date:   Wed, 25 Mar 2020 22:13:02 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Andy Gross <agross@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: qcom: sdm845-mtp: Relocate remoteproc firmware

On Mon, Mar 2, 2020 at 3:09 AM Bjorn Andersson
<bjorn.andersson@...aro.org> wrote:
>
> Update the firmware-name of the remoteproc nodes to mimic the firmware
> structure on other 845 devices.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> ---
>  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.

I'm holding off on the pull request for today, maybe there is something we can
still do about it before the merge window.

        Arnd