linux-kernel - Re: [PATCH 1/3] media: venus: Add support for static video encoder/decoder declarations

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: <f88dbe6d-ceac-4fb3-83ad-f202a4703003@linaro.org>
Date: Thu, 28 Nov 2024 22:34:43 +0000
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
 Vikash Garodia <quic_vgarodia@...cinc.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>
Cc: quic_renjiang@...cinc.com, quic_vnagar@...cinc.com,
 quic_dikshita@...cinc.com, konradybcio@...nel.org,
 linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 Stanimir Varbanov <stanimir.varbanov@...aro.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH 1/3] media: venus: Add support for static video
 encoder/decoder declarations

On 28/11/2024 22:14, Bryan O'Donoghue wrote:
> On 28/11/2024 20:02, Konrad Dybcio wrote:
>> Bryan,
>>
>> I'm still not sure if keeping the logic behind this makes sense at all.
>>
>> Could we not just call platform_device_register_data() with a static
>> configuration of 1 core being enc and the other dec?
> 
> That's another way to do this. One reason I wrote this series to 
> continue to rely on the existing compat= method though is it stuck in my 
> mind that we have some dependency ordering logic in at the moment.
> 
> For example:
> 
> commit 08b1cf474b7f72750adebe0f0a35f8e9a3eb75f6
> Author: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
> Date:   Fri Feb 5 19:11:49 2021 +0100
> 
> And the other reason is the prototype platform_device_register_* looks 
> like more surgery and ultimately more validation / potential for bugs.
> 
> Since this driver is supposed to be moving to maintenance mode, I didn't 
> want to do a more major rewrite of the probe() and remove() paths.
> 
> ---
> bod
> 

and.. I wanted to continue support sdm630/sdm660/msm8996/msm8998 without 
any additional effort to go finding power-domains and clocks which in 
those cases the existing compat= method actually does something useful.

Also potentially other/new additions to venus which have xcoder specific 
PDs and clocks would logically want to specify those as we do for the 
above listed SoCs.

---
bod