linux-kernel - Re: [PATCH] arm64: dts: qcom: sm8550: camss: Add CAMSS block definition

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: <336e5679-f04e-47aa-9655-df88fde9de21@linaro.org>
Date: Wed, 7 Aug 2024 15:17:03 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Depeng Shao <quic_depengs@...cinc.com>,
 Krzysztof Kozlowski <krzk@...nel.org>, andersson@...nel.org,
 robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 bryan.odonoghue@...aro.org
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, kernel@...cinc.com,
 Yongsheng Li <quic_yon@...cinc.com>
Subject: Re: [PATCH] arm64: dts: qcom: sm8550: camss: Add CAMSS block
 definition

On 07/08/2024 13:53, Depeng Shao wrote:
> Hi Krzysztof,
> 
> On 8/7/2024 8:43 PM, Krzysztof Kozlowski wrote:
>> On 07/08/2024 14:39, Krzysztof Kozlowski wrote:
>>> On 07/08/2024 14:33, Depeng Shao wrote:
>>>> Add CAMSS block definition for sm8550.
>>>>
>>>> This drop contains definitions for the following components on sm8550:
>>>
>>> 1. Subject: there is no prefix camss. There is no such file, directory
>>> or module.
>>>
> 
> Thanks for the comment, will remove this.
> 
>>> 2. You already sent this, so this should be v2 or v3 or vX. Provide
>>> changelog under ---.
>>>
>>> If there is going to be resend, please fix above.
>>>
> 
> Sure, I thought it might be a new series, so I didn't add v*, will add 
> v1, and v2 change log in new version series.
> 
>>> 3. If this was tested on aim300, I am surprised this being not enabled
>>> on aim300.
>>
> 
> It was tested long times ago, but the patches wasn't sent out for 
> reviewing early due to the team's internal schedule.
> 
>> One more thing, bindings were not accepted, thus this patch should not
>> go in. There were no new bindings, so I assume patchset is using
>> rejected ones.
>>
>> It's fine to send it to get some comments, although would be nice to
>> mention to maintainer that this cannot be picked up as is. :(
>>
> 
> Sure, I will resend the dtsi patch until the bindings are accepted, send 
> this patches because you posted the comments in other series.
> 
> https://lore.kernel.org/all/0324e8e8-2ad4-4ce6-9616-3038b8e02ff9@quicinc.com/
> 
> Thanks,
> Depeng
> 
> 

Recommend

1. Send out your yaml and dts in one series

2. Driver series can be posted in parallel

3. Once #1 and #2 get merged send our your platform dtsi

Make clear in the cover letter with links to previous series such as 
https://lore.kernel.org/all/0324e8e8-2ad4-4ce6-9616-3038b8e02ff9@quicinc.com/ 
that you are breaking the series up for easier/better merging and ensure 
in the cover letters you explain what you've done to address previous 
comments.

One nice way to give someone like Krzysztof an overview is to post a 
complete series to codelinaro or github showing all of your patches 
stacked on top of each other.

The merge order then would be 1 -> 2 -> 3, yaml/dts -> driver -> dtsi

That way you never have missing compat/dts/yaml splats, your driver code 
gets reviewed/tested/merged and only after all of that you "switch it 
on" for your target platform.

The point of making a public tree containing everything is you can 
reasonably point to and endpoint that lets people know whats coming and 
that indeed a target platform intends to be brought in so that we don't 
end up doing a bunch of review/merge work for a platform/dtsi that just 
lives in downstream tree forever.

The ordering of patches is 100% up to you but, I find the 1 -> 2 -> 3 
sequencing easiest.

---
bod