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] [day] [month] [year] [list]

Message-ID: <13190683-1d69-401d-8c32-adb42e4386ed@quicinc.com>
Date: Wed, 7 Aug 2024 23:30:30 +0800
From: Depeng Shao <quic_depengs@...cinc.com>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Krzysztof Kozlowski
	<krzk@...nel.org>, <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

Hi Kryysztof, Bryan,

On 8/7/2024 10:58 PM, Bryan O'Donoghue wrote:
> 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@...cinc.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.
> 

Thanks for the guidance, I will follow them, and resend the DTS patch 
wait till bindings got accepted.

Thanks,
Depeng