Hi Krzysztof,

On 9/4/2024 6:19 PM, Krzysztof Kozlowski wrote:

On 04/09/2024 11:34, Krzysztof Kozlowski wrote:

quoted

On 04/09/2024 10:33, Jingyi Wang wrote:

quoted

Add initial support for QCS8300 SoC and QCS8300 RIDE board.

This revision brings support for:
- CPUs with cpu idle
- interrupt-controller with PDC wakeup support
- gcc
- TLMM
- interconnect
- qup with uart
- smmu
- pmic
- ufs
- ipcc
- sram
- remoteprocs including ADSP,CDSP and GPDSP

Signed-off-by: Jingyi Wang <redacted>
---
patch series organized as:
- 1-2: remoteproc binding and driver
- 3-5: ufs binding and driver
- 6-7: rpmhpd binding and driver
- 8-15: bindings for other components found on the SoC

Limit your CC list. I found like 8 unnecessary addresses for already
huge Cc list. Or organize your patches per subsystem, as we usually expect.

quoted

- 16-19: changes to support the device tree

dependencies:
tlmm: https://lore.kernel.org/linux-arm-msm/20240819064933.1778204-1-quic_jingyw@quicinc.com/ (local)
gcc: https://lore.kernel.org/all/20240820-qcs8300-gcc-v1-0-d81720517a82@quicinc.com/ (local)
interconnect: https://lore.kernel.org/linux-arm-msm/20240827151622.305-1-quic_rlaggysh@quicinc.com/ (local)

Why? UFS cannot depend on pinctrl for example.

This blocks testing and merging.

Please organize properly (so decouple) your patches, so that there is no
fake dependency.

Let me also add here one more thought. That's like fourth or fifth
QCS/SA patchset last two weeks from Qualcomm and they repeat the same
mistakes. Not correctly organized, huge cc list, same problems with
bindings or drivers.

I am giving much more comments to fix than review/ack tags.

I am not going to review this. I will also slow down with reviewing
other Qualcomm patches. Why? Because you post simultaneously, apparently
you do not learn from other review, so I have to keep repeating the same.

I am overwhelmed with this, so please expect two week review time from me.

Best regards,
Krzysztof

The CC list is generated from B4 tool, however, thanks for your advice and we
will decouple the changes to avoid this. And could you please help us to confirm
the better way to handle binding changes which just add one compatible, should
it be submitted as a single patch or submmitted together with dts patch series?

Thanks,
Jingyi