linux-kernel - Re: [PATCH 1/2] media: venus: core: Add sdm660 DT compatible and resource struct

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: <YA7hVQVTXT554cKN@builder.lan>
Date:   Mon, 25 Jan 2021 09:18:45 -0600
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>
Cc:     Hans Verkuil <hverkuil@...all.nl>,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        agross@...nel.org, mchehab@...nel.org, robh+dt@...nel.org,
        devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        konrad.dybcio@...ainline.org, marijn.suijten@...ainline.org,
        phone-devel@...r.kernel.org
Subject: Re: [PATCH 1/2] media: venus: core: Add sdm660 DT compatible and
 resource struct

On Mon 25 Jan 08:51 CST 2021, AngeloGioacchino Del Regno wrote:

> Il 25/01/21 11:40, Hans Verkuil ha scritto:
> > On 18/01/2021 18:45, AngeloGioacchino Del Regno wrote:
> > > Il 18/01/21 18:21, Stanimir Varbanov ha scritto:
> > > > > diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
[..]
> > > > > +	.fwname = "qcom/venus-4.4/venus.mdt",
[..]
> > This patch can't be merged unless there is a corresponding firmware available
> > in linux-firmware. Is the current 4.2 firmware in linux-firmware signed by
> > Qualcomm? Can they provided 4.4 firmware as well?
> > 
> 
> If there is such issue, then maybe we should do "something" about it: I
> would then propose to remove all references to fwname and just get this
> done in DT, where every qcom board already specifies its own path for
> its own firmware.
> 

We have the same problem with production devices on e.g. SDM845, where
the firmware referenced by fw_name and present in linux-firmware won't
work on any real devices.

As such, providing means for specifying the firmware name in DT would be
a very reasonable thing, and in line with how we handle this in other
subsystems (using the firmware-name property, containing the full
relative path).

Regards,
Bjorn