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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx/

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@xxxxxxxxxxx/ 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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux