linux-kernel - Re: [PATCH RFC/WIP 0/4] arm64: dts: qcom: sm8750: Enable display

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: <bfd59dc5-9503-4642-ba01-5f54c12c0175@kernel.org>
Date: Thu, 30 Oct 2025 17:30:51 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Mahadevan P <mahadevan.p@....qualcomm.com>,
 Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 jesszhan0024@...il.com, quic_rajeevny@...cinc.com,
 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>, Abhinav Kumar <abhinavk@...cinc.com>,
 Abel Vesa <abel.vesa@...aro.org>, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC/WIP 0/4] arm64: dts: qcom: sm8750: Enable display

On 30/10/2025 13:21, Mahadevan P wrote:
>>
>>>
>>> Also, I’m curious to understand more about the DSI PHY PLL VCO rate issue that Jessica had narrowed down—could you please share some details?
>>>
>>> Lastly, I’d appreciate it if you could share the plan for merging these changes upstream. We’re aiming to enable display support on this target as part of our program.
>>
>> Please see Documentation/process/, I think it describes the process of
>> merging patches pretty well.
> 
> Sorry for any confusion in my previous message. Could you please share 
> when we might expect the next non-RFC version of this series, 
> specifically for the DSI enablement patch? Alternatively, if there are 

When dependencies get merged. The patchset cannot be merged and posting
something unmergeable, different than RFC, only clutters maintainers
mailboxes. Ask owners of dependencies about their status (as I said, I
stopped pinging for that)

> no immediate plans to post an updated version, would it be acceptable 
> for us to take it forward and submit the subsequent non-RFC versions of 

No, because the patch is ready. It is waiting on dependencies, so you
taking it would mean work is done twice. Plus you would not solve any
problem - still cannot submit it.

Best regards,
Krzysztof