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
