linux-kernel - Re: [PATCH v8 5/7] media: venus: core: Add qcm2290 DT compatible and resource data

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: <oi7juewvfcgvjm6tedcq246rzyqvx4eambqo36w6byynmbl7sm@i2nztugnzxo5>
Date: Sat, 9 Aug 2025 12:22:39 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Jorge Ramirez <jorge.ramirez@....qualcomm.com>
Cc: Vikash Garodia <quic_vgarodia@...cinc.com>,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        bryan.odonoghue@...aro.org, quic_dikshita@...cinc.com,
        konradybcio@...nel.org, krzk+dt@...nel.org, mchehab@...nel.org,
        conor+dt@...nel.org, andersson@...nel.org, linux-media@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 5/7] media: venus: core: Add qcm2290 DT compatible and
 resource data

On Sat, Aug 09, 2025 at 11:09:24AM +0200, Jorge Ramirez wrote:
> On 09/08/25 11:18:21, Dmitry Baryshkov wrote:
> > On Thu, Aug 07, 2025 at 10:05:10PM +0530, Vikash Garodia wrote:
> > > 
> > > 
> > > On 8/7/2025 7:22 PM, Jorge Ramirez wrote:
> > > > On 07/08/25 16:36:41, Vikash Garodia wrote:
> > > >>
> > > >>> It was agreed that this complexity was not necessary and that we should
> > > >>> just drop <6.0.55 firmware support (which would in any case only include
> > > >>> video decode).
> > > >>>
> > > >>> And so on v8, I removed the above.
> > > >>>
> > > >>> Now I have v9 ready to post it, but Dmitry is asking why cant we have
> > > >>> the v7 functionality so I am waiting for direction.
> > > >>
> > > >> the issue is in firmware for both encoder and decoder. Didn't like the idea of
> > > >> driver carrying the hack for a firmware issue. Just because, for encoder, we are
> > > >> unable to hack it in driver, we are ok to have it enabled in a newer version of
> > > >> the firmware, we can follow the same for decoders as well.
> > > > 
> > > > if that is the only reason please do explain what do you mean by hack.
> > > 
> > > I meant that the EOS handling was not needed in driver after fixing it in
> > > firmware, isn't it ? Was trying to avoid carrying this in driver.
> > > 
> > > I tend to agree with the comment made by Dmitry in another thread to have decode
> > > enabled with existing firmware, no option but to support the *already* published
> > > bins.
> > > 
> > > Having said that, these limitation of having a separate EOS dummy buffer is well
> > > sorted out in gen2 HFI which have an explicit DRAIN cmd for it. Hope this
> > > motivates you to migrate to iris soon for AR50LITE variants :)
> > 
> > Migrating to Iris won't bring gen2 HFI. Think about users which have
> > OEM-fused hardware. For them it's not possible to switch firmware from
> > gen1 to gen2. Thus, if the SoC has been released using gen1 HFI, we
> > should think twice before upgrading it to gen2.
> >
> 
> As I understand it now after the thread, any driver developer working on
> new features should not be constrained by users with OEM-fused hardware.
> 
> Since only the OEM can provide signed firmware updates, it is their
> responsibility—not ours—to figure out how to deliver those updates if
> they want their users to benefit from new features (or new fixes).

The OEMs might go bankrupt, might stop supporting hardware, might not be
bound by EU laws, etc. If the platform was shipped with gen1 HFI and we
suddently provide gen2 HFI, the driver must support both firmware
interfaces for that platform.

> The EU Cyber Resilience Act supports this view by placing the update
> obligation on manufacturers (at least that is what I understand it, let
> me know if you understand it differently)
> 
> Breaking backward compatibility is something we must avoid of
> course. However, guaranteeing compatibility between old firmwares
> (whether signed or not) and _new_ features is a separate matter...

Anyway, the kernel is provided separately from the firmware. If we
supported a particular firmware set, we can not break that.

AR50_LITE is a corner case, as we have been shipping the firmware, but
there was no corresponding open-source driver for that platform.

-- 
With best wishes
Dmitry