linux-kernel - Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

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: <0a17dc61-a8eb-443c-9f4a-4f7851e07c5a@kernel.org>
Date: Thu, 5 Jun 2025 19:12:30 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...ndries.io>,
 Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
 Renjiang Han <quic_renjiang@...cinc.com>,
 Vikash Garodia <quic_vgarodia@...cinc.com>,
 Dikshita Agarwal <quic_dikshita@...cinc.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-media@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, Nicolas Dufresne <nicolas.dufresne@...labora.com>
Subject: Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

On 05/06/2025 18:02, Dmitry Baryshkov wrote:
> On Thu, Jun 05, 2025 at 01:40:03PM +0100, Bryan O'Donoghue wrote:
>> On 05/06/2025 13:33, Krzysztof Kozlowski wrote:
>>> On 05/06/2025 14:30, Dmitry Baryshkov wrote:
>>>> On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>>>>
>>>>> On 02/06/2025 08:16, Dmitry Baryshkov wrote:
>>>>>> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
>>>>>>>
>>>>>>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
>>>>>>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
>>>>>>>>> QCS615 uses the same video core as SC7180, so reuse the same resource
>>>>>>>>> data of SC7180 for QCS615 to enable video functionality.
>>>>>>>>>
>>>>>>>>> There are no resources for the video-decoder and video-encoder nodes
>>>>>>>>> in the device tree, so remove these two nodes from the device tree. In
>>>>>>>>> addition, to ensure that the video codec functions properly, use [3]
>>>>>>>>> to add encoder and decoder node entries in the venus driver.
>>>>>>>>>
>>>>>>>>> Validated this series on QCS615 and SC7180.
>>>>>>>>>
>>>>>>>>> Note:
>>>>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>>>>> DT patches, still depend on [1].
>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
>>>>>>>> on QCS615 over(?)clocked.
>>>>>>> Agree, so we need to make sure that the driver patch is not picked after the
>>>>>>> DT patch.
>>>>>>
>>>>>> Worse: we need to make sure that the driver patch is present in the
>>>>>> branch which picks up DT patches. Otherwise building & testing that
>>>>>
>>>>>
>>>>> Well, that's a NAK then (although depends what you mean by DT).
>>>>
>>>> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver
>>>
>>> Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into
>>> one branch.
> 
> Surely it can... Like any other cross-subsystem dependency.

Sure it cannot, because this breaks the basic rule of not mixing drivers
into DTS. Arm soc maintainers are not merging drivers back to DTS and
the DTS must not go via drivers tree. These are basic assumptions around
DTS, see subsystem profile for more explanations.


Best regards,
Krzysztof