This series depends on q6 clock removal series [1].

- Secure PIL is signed, split firmware images which only TrustZone (TZ) can
  authenticate and load. Linux kernel will send a request to TZ to
  authenticate and load the PIL images.

- When secure PIL support was added to the existing wcss PIL driver
  earlier in [2], Bjorn suggested not to overload the existing WCSS
  rproc driver [2], instead post a new driver for secure PIL alone.
  This series adds a new secure PIL driver for the same. 

[1] https://patchwork.kernel.org/project/linux-arm-msm/cover/20240820055618.267554-1-quic_gokulsri@quicinc.com/

[2] https://patchwork.kernel.org/project/linux-arm-msm/patch/1611984013-10201-3-git-send-email-gokulsri@codeaurora.org/

Manikanta Mylavarapu (3):
  dt-bindings: remoteproc: qcom: document hexagon based WCSS secure PIL
  arm64: dts: qcom: ipq5332: add nodes to bringup q6
  arm64: dts: qcom: ipq9574: add nodes to bring up q6

Vignesh Viswanathan (1):
  remoteproc: qcom: add hexagon based WCSS secure PIL driver

 .../remoteproc/qcom,wcss-sec-pil.yaml         | 125 ++++++
 arch/arm64/boot/dts/qcom/ipq5332.dtsi         |  62 +++
 arch/arm64/boot/dts/qcom/ipq9574.dtsi         |  58 +++
 drivers/remoteproc/Kconfig                    |  22 ++
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/qcom_q6v5_wcss_sec.c       | 360 ++++++++++++++++++
 6 files changed, 628 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,wcss-sec-pil.yaml
 create mode 100644 drivers/remoteproc/qcom_q6v5_wcss_sec.c

-- 
2.34.1

On 20/08/2024 10:55, Gokul Sriram Palanisamy wrote:
> This series depends on q6 clock removal series [1].

How? So this cannot be tested and merged?

That's second patchset to day with some totally bogus dependencies.
People, stop it.


Best regards,
Krzysztof

On 8/20/2024 4:42 PM, Krzysztof Kozlowski wrote:
> On 20/08/2024 10:55, Gokul Sriram Palanisamy wrote:
>> This series depends on q6 clock removal series [1].
> How? So this cannot be tested and merged?

Yes. Though TrustZone enables these clocks, since Linux Kernel will 
consider these clock as unused.
These clock will be disabled so we cannot bring Q6 out of reset. So we 
have the dependency set.
I posted this as a separate series because [1] 'remove unnecessary q6 
clocks' series was already reviewed for some
versions.

[1] 
https://patchwork.kernel.org/project/linux-arm-msm/cover/20240820055618.267554-1-quic_gokulsri@quicinc.com/

Regards,

Gokul

> That's second patchset to day with some totally bogus dependencies.
> People, stop it.
>
>
> Best regards,
> Krzysztof
>

On 22/08/2024 12:43, Gokul Sriram P wrote:
> 
> On 8/20/2024 4:42 PM, Krzysztof Kozlowski wrote:
>> On 20/08/2024 10:55, Gokul Sriram Palanisamy wrote:
>>> This series depends on q6 clock removal series [1].
>> How? So this cannot be tested and merged?
> 
> Yes. Though TrustZone enables these clocks, since Linux Kernel will 
> consider these clock as unused.
> These clock will be disabled so we cannot bring Q6 out of reset. So we 
> have the dependency set.
> I posted this as a separate series because [1] 'remove unnecessary q6 
> clocks' series was already reviewed for some
> versions.

This is not a dependency in the kernel workflow. Nothing gets broken,
nothing stops this patch from merging. Your remark is confusing and will
either start questions or prevent applying the patchset.

Best regards,
Krzysztof

On 8/22/2024 4:58 PM, Krzysztof Kozlowski wrote:
> On 22/08/2024 12:43, Gokul Sriram P wrote:
>> On 8/20/2024 4:42 PM, Krzysztof Kozlowski wrote:
>>> On 20/08/2024 10:55, Gokul Sriram Palanisamy wrote:
>>>> This series depends on q6 clock removal series [1].
>>> How? So this cannot be tested and merged?
>> Yes. Though TrustZone enables these clocks, since Linux Kernel will
>> consider these clock as unused.
>> These clock will be disabled so we cannot bring Q6 out of reset. So we
>> have the dependency set.
>> I posted this as a separate series because [1] 'remove unnecessary q6
>> clocks' series was already reviewed for some
>> versions.
> This is not a dependency in the kernel workflow. Nothing gets broken,
> nothing stops this patch from merging. Your remark is confusing and will
> either start questions or prevent applying the patchset.
>
Ok, got it. It will not break anything. Will post this series as 
independent series in v2.

thanks,

Gokul