linux-kernel - Re: [PATCH v2 0/3] Add NVIDIA Tegra114 support to video decoder driver

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] [day] [month] [year] [list]

Message-ID: <274daf12-ae6f-8a95-5cae-bb5b558e25e2@gmail.com>
Date:   Mon, 15 Nov 2021 18:12:59 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Hans Verkuil <hverkuil@...all.nl>,
        Nicolas Dufresne <nicolas@...fresne.ca>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Anton Bambura <jenneron@...tonmail.com>
Cc:     linux-media@...r.kernel.org, linux-staging@...ts.linux.dev,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/3] Add NVIDIA Tegra114 support to video decoder
 driver

15.11.2021 17:49, Hans Verkuil пишет:
> On 15/11/2021 15:43, Nicolas Dufresne wrote:
>> Hi Dmitry,
>>
>> Le lundi 15 novembre 2021 à 01:47 +0300, Dmitry Osipenko a écrit :
>>> Video decoder of Tegra114/124 SoCs uses additional memory buffer required
>>> for decoding of protected content. We won't support that content, but it
>>> is impossible to disable access to the buffer, hence a stub buffer needs
>>> to be provided. This series enables decoder driver only for Tegra114
>>> because Tegra124 support requires more non-trivial changes on both kernel
>>> and userspace sides.
>>
>> I believe the stateless API is quite in place now, but I only see maintenance on
>> this staging driver. I don't believe it really make sense to keep maintaining a
>> staging driver without any step forward de-staging it. I believe it gives the
>> wrong message on the Kernel staging purpose.
>>
>> I'm not criticizing your effort, I believe you are doing nice work for you
>> community, but would prefer to see this driver be ported to the official kernel
>> APIs rather then being maintain as staging till the end of time.
> 
> I agree with Nicolas here. This driver only support H264 and the stateless API
> for that is now in mainline. So there is no reason not to convert to the
> stateless codec API and move this driver to mainline.
> 
> It would be really nice to see that happen.
> 
> Without any progress on that I am inclined to remove this driver some time
> next year.

I'll prioritize the v4l patches of this driver. The reason it wasn't
done yet is because the current custom UAPI works perfectly fine and I
was busy with a bit more important patches so far.