linux-kernel - Re: [PATCH 0/7] media: iris: add support for kaanapali platform

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: <df2d7dcc31c9a47752a1d58efdd7a416311e55ec.camel@ndufresne.ca>
Date: Tue, 27 Jan 2026 10:10:08 -0500
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, Vikash Garodia
	 <vikash.garodia@....qualcomm.com>
Cc: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>, Abhinav Kumar	
 <abhinav.kumar@...ux.dev>, Bryan O'Donoghue <bod@...nel.org>, Mauro
 Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski	 <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Saravana Kannan	 <saravanak@...nel.org>, Joerg
 Roedel <joro@...tes.org>, Will Deacon	 <will@...nel.org>, Robin Murphy
 <robin.murphy@....com>, Stefan Schmidt	 <stefan.schmidt@...aro.org>, Hans
 Verkuil <hverkuil@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
 Vishnu Reddy <busanna.reddy@....qualcomm.com>, Hans Verkuil	
 <hverkuil+cisco@...nel.org>, linux-arm-msm@...r.kernel.org, 
	linux-media@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, iommu@...ts.linux.dev, Bryan O'Donoghue	
 <bryan.odonoghue@...aro.org>, Charan Teja Kalla
 <charan.kalla@....qualcomm.com>,  Vijayanand Jitta
 <vijayanand.jitta@....qualcomm.com>
Subject: Re: [PATCH 0/7] media: iris: add support for kaanapali platform

Hi,

Le mardi 27 janvier 2026 à 13:52 +0200, Dmitry Baryshkov a écrit :
> On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
> 

[..]

> 
> >  - 4 testcase failed due to unsupported resolution
> 
> Can it be fixed?

Its nicer if you name the failing tests vectors. I can guess this is
PICSIZE_{A,B,C,D}_Bossen_1 by experience, but not everyone will guess. HEVC
level impose a limit on bandwidth, not on resolution. These files are either
very large and small height or the opposite. One of these is just 4K in portrait
mode (that is more concerning). Though, there is a V4L2 limitation for this
aspect, since we advertise the resolutions by range. Most hardware is designed
to support 4096x4096, in that casse that's what you should expose as limits.

Though, some hardware do have dynamic sizing capabilities (like RKVDEC HEVC), in
this case there is not much you can do, you have to find the right trade of. But
since you expose LEVELs, I think its fine to overshoot a little. Both
constraints should ensure it works with valid streams.

> 
> >  - 2 testcase failed due to CRC mismatch

These are clear example of "no one can guess".

> 
> Which means an error in the testsuite or somewhere on our side?

The testsuite fully pass if you run using Franhofer reference decoder. This is
logical since the MD5 has been generated with it.

> 
> >  - 2 test fails due to session error (under debug)
> >    - PICSIZE_C_Bossen_1

Hmm, see, I have no idea which fourth one could fail due to resolution, and that
forth one is likely a bug on your side.

> >    - WPP_E_ericsson_MAIN_2
> > 
> > VP9:
> > 235/305 testcases passed while testing VP9-TEST-VECTORS with
> >  GStreamer-VP9-V4L2-Gst1.0.
> >  The failing test case:
> >  - 64 testcases failed due to unsupported resolution
> 
> Can it be fixed?

Check if you aren't mixing up constraints between display, coded and allocated
resolutions. On most hardware, all 3 can differ. The OUTPUT queue should either
not care at all, or use it to allow optimistic pre-allocation. But check that
the low resolution constraints is not coming from the OUTPUT queue software.

VP9 coded resolution, it always at least 64x64.

> 
> >  - 2 testcases failed due to unsupported format
> 
> Hmm?

Clarify please, I suppose these are YUV444 (aka professional profiles).

> 
> >  - 1 testcase failed with CRC mismatch (fails with ref decoder as well)
> 
> Could you please raise an issue against fluster?

Check your setup, it fully pass with reference here. The MD5 has been generated
using the reference.

  ./fluster.py run -d libvpx-VP9 -ts  VP9-TEST-VECTORS

It also fully pass with the GStreamer wrapper, though it had been fixed in
recent GStreamer versions (I'm testing with 1.26.10).

> 
> >  - 2 testcase failed due to unsupported resolution after sequence change
> 
> Can it be fixed?

This one can't be fixed without adding an extension to the V4L2 Stateful Decoder
spec, like we did for the stateless decoder spec. In order to handle inter-frame
resolution changes (a resolution change on a non-keyframe), you have to notify
userspace with the new resolution, give it a way to read back this solution,
have CREATE_BUFS() support to allow allocating for that new resolution without
going through streamoff (to avoid looking reference data), and finally, a way to
remove buffers that are now too small (or too big if userspace wants to reduce
the amount of RAM used) through the new DELETE_BUFS ioctl. You also have to
track in your driver the reference buffer resolution/stride.

This is non-trivial with the existing stateful state-machine. You have to make
sure userspace won't be confused between normal DRC and inter-frame DRC (dynamic
resolution changes).

[...]

regards,
Nicolas

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)