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: <c3ed2b0a-3f59-4cd1-98e1-96494d15d172@linaro.org>
Date: Wed, 7 Aug 2024 15:58:11 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Krzysztof Kozlowski <krzk@...nel.org>,
 Depeng Shao <quic_depengs@...cinc.com>, andersson@...nel.org,
 robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.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 15:51, Krzysztof Kozlowski wrote:
> On 07/08/2024 16:17, Bryan O'Donoghue wrote:
>> 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
> 
> The binding should go with the driver. Also usually discussion about
> driver brings comments, thus changes, to the bindings.
> 
> Sorry, DTSI and DTS should wait till bindings got accepted to media
> subsystem.

Yes you're right

1. Yaml - bindings
2. dts + driver
3. dtsi

In this case @Depeng remember to

1. Link back to the older series in your cover letters
2. Suggested by recommended - publish a complete tree somewhere and
    link to that tree in your cover letters

Its fine IMO to restart the version number of your series when breaking 
up into smaller series, so long as you remember to link to the previous 
series and explain in the cover letter whats going on.

---
bod