* [PATCH v4 0/2] arm64: dts: socfpga: Enable SMMU and add DMA coherency for XGMAC
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-24 6:22 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
This series enables the SMMU and adds DMA coherency support for the
XGMAC nodes across the affected board device trees.
Patch 1 enables the SMMU for the SoCFPGA board device trees where it
was missing. The SoC uses a different memory-mapped base address for
its peripherals, which requires the SMMU to be active so that the
Secure Device Manager (SDM) can correctly access those regions through
address translation.
Patch 2 adds the dma-coherent property to the XGMAC nodes. The SMMU
is enabled and transactions going through it are cache coherent.
Adding dma-coherent prevents redundant cache flush/invalidate
operations and potential stale data issues.
Changes in v4:
- Remove status = "disabled" instead of setting status = "okay", as nodes
without a status property are enabled by default
Changes in v3:
- Fix commit header to follow subsystem naming convention (patches 1 and 2)
- Remove commit body line that restated the subject
- Clarify which file had the SMMU disabled
Changes in v2:
- Move SMMU enable into the base DTSI file instead of individual DTS files
- Move dma-coherent property into the base DTSI file instead of individual DTS files
- Improve commit messages and cover letter descriptions with more context on why the changes are needed
Nazim Amirul (2):
arm64: dts: socfpga: agilex5: Enable the SMMU
arm64: dts: socfpga: agilex5: Add dma-coherent to XGMAC nodes
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
2.43.7
^ permalink raw reply
* [PATCH v4 1/2] arm64: dts: socfpga: agilex5: Enable the SMMU
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-24 6:22 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260624062203.12221-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
The SMMU is disabled in socfpga_agilex5.dtsi. The SoC uses a different
memory-mapped base address for its peripherals, which requires the SMMU
to be active so that the Secure Device Manager (SDM) can correctly
access those regions through address translation.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v4:
- Remove status = "disabled" instead of setting status = "okay", as nodes
without a status property are enabled by default
Changes in v3:
- Fix commit header to follow subsystem naming convention
- Remove commit body line that restated the subject
- Clarify which file had the SMMU disabled
Changes in v2:
- Move SMMU enable into the base DTSI file instead of individual DTS files
---
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index b06c6d5d60ee..daa1f9e0d1f5 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -385,7 +385,6 @@ smmu: iommu@16000000 {
interrupt-names = "eventq", "gerror", "priq";
dma-coherent;
#iommu-cells = <1>;
- status = "disabled";
};
spi0: spi@10da4000 {
--
2.43.7
^ permalink raw reply related
* [PATCH v4 2/2] arm64: dts: socfpga: agilex5: Add dma-coherent to XGMAC nodes
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-24 6:22 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260624062203.12221-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
The SMMU is enabled and transactions going through it are cache
coherent. Add the dma-coherent property to the XGMAC nodes to prevent
redundant cache flush/invalidate operations and potential stale data
issues.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v3:
- Fix commit header to follow subsystem naming convention (add agilex5: prefix)
Changes in v2:
- Move dma-coherent property into the base DTSI file instead of individual DTS files
---
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index daa1f9e0d1f5..3822f06c2694 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -576,6 +576,7 @@ gmac0: ethernet@10810000 {
altr,sysmgr-syscon = <&sysmgr 0x44 0>;
snps,clk-csr = <0>;
iommus = <&smmu 1>;
+ dma-coherent;
status = "disabled";
stmmac_axi_emac0_setup: stmmac-axi-config {
@@ -689,6 +690,7 @@ gmac1: ethernet@10820000 {
altr,sysmgr-syscon = <&sysmgr 0x48 0>;
snps,clk-csr = <0>;
iommus = <&smmu 2>;
+ dma-coherent;
status = "disabled";
stmmac_axi_emac1_setup: stmmac-axi-config {
@@ -802,6 +804,7 @@ gmac2: ethernet@10830000 {
altr,sysmgr-syscon = <&sysmgr 0x4c 0>;
snps,clk-csr = <0>;
iommus = <&smmu 3>;
+ dma-coherent;
status = "disabled";
stmmac_axi_emac2_setup: stmmac-axi-config {
--
2.43.7
^ permalink raw reply related
* Re: [PATCH v5 3/3] MAINTAINERS: add entry for MAX86150 IIO health driver
From: Krzysztof Kozlowski @ 2026-06-24 6:22 UTC (permalink / raw)
To: Md Shofiqul Islam, linux-iio
Cc: jic23, lars, conor, conor+dt, robh, krzk+dt, devicetree,
linux-kernel
In-Reply-To: <20260623201124.18271-4-shofiqtest@gmail.com>
On 23/06/2026 22:11, Md Shofiqul Islam wrote:
> Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
> ---
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
You need to slow down, please. One version per 24h.
And the last one is not even correct anymore...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: iio: dac: Add DAC8163
From: Lukas Metz @ 2026-06-24 6:25 UTC (permalink / raw)
To: David Lechner
Cc: Lukas Metz, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
linux-iio, devicetree
In-Reply-To: <5a19c272-e8fc-4fa9-b137-842b6ed6649b@baylibre.com>
Thanks a lot for the review. This is my first time submitting a
patch so im grateful for the detailed comments and suggestions.
On Tue, Jun 23, 2026 at 02:17:04PM -0500, David Lechner wrote:
> It is more logical to put the dt-bindings patch first in the series
> before the driver that makes use of it.
I will reorder the commits in v2.
> There are a couple of more SPI properties needed since this is not a "normal"
> SPI device. We can only write and not read because there is no D_OUT pin. So
>
> spi-rx-bus-width:
> items:
> - const: 0
>
> will describe this.
I will the add the suggested changes to v2. Are there any other poperties
i have missed? Same for the other comments regarding vendor-prefix,
spi-max-frequency, avdd-supply and vref supply name.
> We also want the binding to be complete even if the driver doesn't all of it, so
> `clear-gpios` and `sync-gpios` probably make sense too.
SYNC pin is the chip select pin of the device as described below. In
that case i dont need to add it here right?
> Usually, we don't bother with a property like this since it is redundant.
> If an external reference supply is given, then it gets used, otherwise
> the internal reference is used.
That sounds logical. I will remove the property completly.
> These chips don't appear to have a chip select pin, so this comment
> doesn't make sense to me. More logical would be to just use dac@0
> and reg = <0>; since it should just be ignored.
The SYNC pin on the device acts like a chip select pin.
According to the datasheet: when the pin goes low it enables the input shift
register. At least that was my understanding. On my board i have tested the
driver with the chip select signal connected to the SYNC pin. The
example comes straight from my own device tree where i have two devices
on the bus. Thats why i used reg<1> here but i can change it to 0 and
remove the comment.
> The pin is marked active low in the datasheet, so I would expect
> this to be GPIO_ACTIVE_LOW.
I wasnt sure about that. The pin needs to be held low continuously. I
thought when the pin is marked active low and i initialize the pin with
GPIOD_OUT_LOW the result will be that the pin is held high. To match the
datasheet description seems logical though.
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDA 850
From: Krzysztof Kozlowski @ 2026-06-24 6:26 UTC (permalink / raw)
To: david, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260623-sda850-v1-1-ddd8e62c85d8@ixit.cz>
On 23/06/2026 20:41, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> Add SoC ID for Qualcomm Snapdragon SDA850.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> Will be used by Comma three.
Can you provide a link?
In general this must be send with the user.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/4] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support
From: Markus Elfring @ 2026-06-24 6:27 UTC (permalink / raw)
To: Amit Barzilai, dri-devel, devicetree, linux-fbdev, linux-staging
Cc: LKML, Adam Azuddin, Andy Shevchenko, Chintan Patel, Conor Dooley,
David Airlie, Greg Kroah-Hartman, Helge Deller,
Javier Martinez Canillas, Krzysztof Kozlowski, Maarten Lankhorst,
Maxime Ripard, Rob Herring, Simona Vetter, Thomas Zimmermann
In-Reply-To: <20260623213447.30196-1-amit.barzilai22@gmail.com>
>>> +++ b/drivers/gpu/drm/solomon/ssd130x.c
>>> @@ -146,6 +146,33 @@
>>> #define SSD133X_COLOR_DEPTH_256 0x0
>>> #define SSD133X_COLOR_DEPTH_65K 0x1
>>>
>>> +/* ssd135x commands */
>>> +#define SSD135X_SET_COL_RANGE 0x15
>>> +#define SSD135X_WRITE_RAM 0x5c
>>> +#define SSD135X_SET_ROW_RANGE 0x75
>> [...]
>>
>> How do you think about to use an enumeration for such data?
>> https://en.wikipedia.org/wiki/Enumerated_type#C_and_syntactically_similar_languages
>
> Thank you for the suggestion.
>
> I used #define to stay consistent with the rest of ssd130x.c, where the
> command constants for the other families are all defined the same way.
Will any further adjustments become more interesting?
> In my opinion an enum could be a readable solution for these values,
This is nice.
> but I don't think the switch should be included in this series.
What does hinder you to take another design option better into account?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v4 2/2] arm64: dts: socfpga: agilex5: Add dma-coherent to XGMAC nodes
From: sashiko-bot @ 2026-06-24 6:30 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260624062203.12221-3-muhammad.nazim.amirul.nazle.asmade@altera.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Omission of `dma-coherent` property on SMMU-routed DMA master nodes (`usb0`, `dmac0`, `dmac1`) causes potential data corruption.
--
commit d5421d52fec812147859d426e90e92990eb7c1b8
Author: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
arm64: dts: socfpga: agilex5: Add dma-coherent to XGMAC nodes
The SMMU is enabled and transactions going through it are cache
coherent. Add the dma-coherent property to the XGMAC nodes to prevent
redundant cache flush/invalidate operations and potential stale data
issues.
> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> index 654f94ded1e85..3de424ae3b8ba 100644
> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> @@ -576,6 +576,7 @@ gmac0: ethernet@10810000 {
> altr,sysmgr-syscon = <&sysmgr 0x44 0>;
> snps,clk-csr = <0>;
> iommus = <&smmu 1>;
> + dma-coherent;
> status = "disabled";
>
> stmmac_axi_emac0_setup: stmmac-axi-config {
[Severity: High]
This is a pre-existing issue, but since the commit message establishes that
transactions going through the SMMU are cache coherent, should the
dma-coherent property also be added to other SMMU-routed DMA master nodes?
Looking at arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi, the dmac0, dmac1,
and usb0 nodes also route through the SMMU but lack the dma-coherent property:
dmac0: dma-controller@0 {
...
iommus = <&smmu 8>;
};
If the kernel incorrectly treats these devices as non-coherent, allocating
a DMA buffer for reading (DMA_FROM_DEVICE) might result in a cache
invalidation (DC IVAC via dmac_inv_range()) discarding dirty cache lines
without writing them back to memory.
This would cause the CPU to subsequently read stale data, permanently losing
the data the device just wrote.
Could this incomplete fix leave usb0, dmac0, and dmac1 vulnerable to data
corruption and loss?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624062203.12221-1-muhammad.nazim.amirul.nazle.asmade@altera.com?part=2
^ permalink raw reply
* Re: [PATCH v7 2/6] dt-bindings: remoteproc: qcom: move interrupts and interrupt-names list out of pas-common
From: Krzysztof Kozlowski @ 2026-06-24 6:33 UTC (permalink / raw)
To: Jingyi Wang
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Bartosz Golaszewski, Kumar Patro, Komal Bajaj,
Konrad Dybcio, aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20260623-knp-soccp-v7-2-1ec7bb5c9fec@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 03:05:18AM -0700, Jingyi Wang wrote:
> Move interrupts and interrupt-names list out of pas-common since they
> will be redefined differently for Kaanapali SoCCP.
>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-24 6:33 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel
Fix probing of the traceNoC device by switching from the AMBA bus to
the platform itnoc driver.
Fixes: f73959d86c15 ("arm64: dts: qcom: kaanapali: add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7aa9653bd456..84561b5faf81 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -5003,12 +5003,12 @@ tpdm_pcie_rscc_out: endpoint {
};
};
- tn@111b8000 {
- compatible = "qcom,coresight-tnoc", "arm,primecell";
+ itnoc@111b8000 {
+ compatible = "qcom,coresight-itnoc";
reg = <0x0 0x111b8000 0x0 0x4200>;
clocks = <&aoss_qmp>;
- clock-names = "apb_pclk";
+ clock-names = "apb";
in-ports {
#address-cells = <1>;
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260624-fix-tracenoc-probe-issue-c6429da28df4
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v7 3/6] dt-bindings: remoteproc: qcom: Document pas for SoCCP on Kaanapali and Glymur platforms
From: Krzysztof Kozlowski @ 2026-06-24 6:35 UTC (permalink / raw)
To: Jingyi Wang
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Bartosz Golaszewski, Kumar Patro, Komal Bajaj,
Konrad Dybcio, aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20260623-knp-soccp-v7-3-1ec7bb5c9fec@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 03:05:19AM -0700, Jingyi Wang wrote:
> Document the component used to boot SoCCP on Kaanapali SoC and add
> compatible for Glymur SoCCP which could fallback to Kaanapali. Extend
> the "qcom,smem-states", "qcom,smem-state-names" in the pas-common
> and add maxItems constraints for SMEM properties in the documents
> that reference to pas-common.
>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v7 4/6] dt-bindings: remoteproc: qcom: Document pas for SoCCP on Hawi and Maili SoC
From: Krzysztof Kozlowski @ 2026-06-24 6:36 UTC (permalink / raw)
To: Jingyi Wang
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Bartosz Golaszewski, Kumar Patro, Komal Bajaj,
Konrad Dybcio, aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Mukesh Ojha
In-Reply-To: <20260623-knp-soccp-v7-4-1ec7bb5c9fec@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 03:05:20AM -0700, Jingyi Wang wrote:
> From: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>
> Document SoCCP remote processor used on Qualcomm Hawi and Maili SoC which
> is fully compatible with Kaanapali.
>
> Co-developed-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
> .../devicetree/bindings/remoteproc/qcom,kaanapali-soccp-pas.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v8] arm64: dts: qcom: kodiak: Add EL2 overlay
From: Mukesh Ojha @ 2026-06-24 6:39 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Mukesh Ojha, Sumit Garg
All the existing variants Kodiak boards are using Gunyah hypervisor
which means that, so far, Linux-based OS could only boot in EL1 on those
devices. However, it is possible for us to boot Linux at EL2 on these
devices [1].
When running under Gunyah, the remote processor firmware IOMMU
streams are controlled by Gunyah. However, without Gunyah, the IOMMU is
managed by the consumer of this DeviceTree. Therefore, describe the
firmware streams for each remote processor.
Add a EL2-specific DT overlay and apply it to Kodiak IOT variant
devices to create -el2.dtb for each of them alongside "normal" dtb.
Note that modem and media subsystems haven't been supported yet due
to missing dependencies. For GPU to work, zap shader is disabled and
in EL2 mode the kernel owns hardware watchdog which is enabled here.
And for wifi to work wpss copy engine memory need to be mapped for
WPSS firmware to work which is aligning with sc7280 chrome.
[1]
https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
Co-developed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
Changes in v8: https://lore.kernel.org/lkml/20260522115936.201208-2-sumit.garg@kernel.org/
- Added a wpss copy engine memory similar to chrome for Wifi to work.
- WPSS does not have firmware Stream, so that was removed.
- Added wifi streams similar to chrome for wifi to work.
- Removed this patch from Generic Pas patch series, can be followed
separately.
- Moved Sumit as co-author as part of modification done to the patch
in the past.
- Added some more kodiak's board variants in the makefile.
Changes in v1-v7:
- mpss was disabled and will be enabled once the dependencies patches
get merged.
arch/arm64/boot/dts/qcom/Makefile | 12 ++++++
arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 52 ++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
3 files changed, 65 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 6f33c4e2f09c..d2cee1190954 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -164,7 +164,11 @@ purwa-iot-evk-el2-dtbs := purwa-iot-evk.dtb x1-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += purwa-iot-evk-el2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcm6490-fairphone-fp5.dtb
+
dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp.dtb
+qcm6490-idp-el2-dtbs := qcm6490-idp.dtb kodiak-el2.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp-el2.dtb
+
dtb-$(CONFIG_ARCH_QCOM) += qcm6490-particle-tachyon.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcm6490-shift-otter.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb
@@ -176,12 +180,20 @@ qcs615-ride-el2-dtbs := qcs615-ride.dtb talos-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs615-ride-el2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-radxa-dragon-q6a.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
+qcs6490-rb3gen2-el2-dtbs := qcs6490-rb3gen2.dtb kodiak-el2.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-el2.dtb
qcs6490-rb3gen2-vision-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-vision-mezzanine.dtbo
qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-industrial-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine.dtb
+qcs6490-rb3gen2-industrial-mezzanine-el2-dtbs := qcs6490-rb3gen2-industrial-mezzanine.dtb kodiak-el2.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine-el2.dtb
+
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine.dtb
+qcs6490-rb3gen2-vision-mezzanine-el2-dtbs := qcs6490-rb3gen2-vision-mezzanine.dtb kodiak-el2.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine-el2.dtb
+
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-minipc-g1iot.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-rubikpi3.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
diff --git a/arch/arm64/boot/dts/qcom/kodiak-el2.dtso b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
new file mode 100644
index 000000000000..91e4cda45b49
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ *
+ * Kodiak specific modifications required to boot in EL2.
+ */
+
+/dts-v1/;
+/plugin/;
+
+&gpu_zap_shader {
+ status = "disabled";
+};
+
+&remoteproc_adsp {
+ iommus = <&apps_smmu 0x1800 0x0>;
+};
+
+&remoteproc_cdsp {
+ iommus = <&apps_smmu 0x11a0 0x0400>;
+};
+
+&remoteproc_mpss {
+ status = "disabled";
+};
+
+&reserved_memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ wlan_ce_mem: wlan-ce@4cd000 {
+ no-map;
+ reg = <0x0 0x004cd000 0x0 0x1000>;
+ };
+};
+
+&venus {
+ status = "disabled";
+};
+
+&watchdog {
+ status = "okay";
+};
+
+&wifi {
+ memory-region = <&wlan_fw_mem>, <&wlan_ce_mem>;
+ status = "okay";
+
+ wifi-firmware {
+ iommus = <&apps_smmu 0x1c02 0x1>;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index fa540d8c2615..2486d15fa2ba 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -91,7 +91,7 @@ sleep_clk: sleep-clk {
};
};
- reserved-memory {
+ reserved_memory: reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: sashiko-bot @ 2026-06-24 6:49 UTC (permalink / raw)
To: Jie Gan; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v1-1-bcc785198fc5@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] Switching traceNoC to the platform itnoc driver breaks trace enablement for connected sources.
Pre-existing issues:
- [High] Probe error path unconditionally invokes PM runtime suspend, causing a NULL pointer dereference.
- [Medium] Driver removal and unbind paths cause a clock enable count underflow warning.
--
commit 152b245041f20740bb96bedaa8fe0632753867d1
Author: Jie Gan <jie.gan@oss.qualcomm.com>
arm64: dts: qcom: kaanapali: fix traceNoC probe issue
This commit fixes probing of the traceNoC device by switching from the AMBA
bus to the platform itnoc driver.
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index 7aa9653bd456e..84561b5faf811 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> @@ -5003,12 +5003,12 @@ tpdm_pcie_rscc_out: endpoint {
> };
> };
>
> - tn@111b8000 {
> - compatible = "qcom,coresight-tnoc", "arm,primecell";
> + itnoc@111b8000 {
> + compatible = "qcom,coresight-itnoc";
[Severity: High]
This is a pre-existing issue, but does switching to the platform driver expose
a NULL pointer dereference if probing fails?
If _tnoc_probe() fails in itnoc_probe(), the code unconditionally calls
pm_runtime_put() before drvdata is fully initialized. This triggers:
drivers/hwtracing/coresight/coresight-tnoc.c:itnoc_runtime_suspend() {
struct trace_noc_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->pclk);
}
Could this dereference a NULL drvdata during the error path?
[Severity: Medium]
This isn't a bug introduced by this patch, but does using the itnoc driver
lead to a clock enable count underflow on unbind?
The clock is fetched with managed enablement in _tnoc_probe():
ret = coresight_get_enable_clocks(dev, &drvdata->pclk, NULL);
This registers a devres cleanup action. However, the driver also manages the
clock manually:
drivers/hwtracing/coresight/coresight-tnoc.c:itnoc_runtime_suspend() {
clk_disable_unprepare(drvdata->pclk);
}
If the driver is unbound while in a runtime-suspended state, will the devres
framework attempt to disable the already-disabled clock?
[Severity: High]
Will changing the compatible string without "arm,primecell" break trace
enablement for connected sources like TPDM?
When probed as a platform device, the driver initializes atid to unsupported:
drivers/hwtracing/coresight/coresight-tnoc.c:trace_noc_init_default_data() {
if (!dev_is_amba(drvdata->dev)) {
drvdata->atid = -EOPNOTSUPP;
return 0;
}
}
During trace enablement, coresight_path_assign_trace_id() could fail because
-EOPNOTSUPP is evaluated as an invalid trace ID:
drivers/hwtracing/coresight/coresight-core.c:coresight_path_assign_trace_id() {
if (!IS_VALID_CS_TRACE_ID(trace_id))
return -EINVAL;
}
Does this immediately abort trace enablement for any source relying on this
traceNoC?
> reg = <0x0 0x111b8000 0x0 0x4200>;
>
> clocks = <&aoss_qmp>;
> - clock-names = "apb_pclk";
> + clock-names = "apb";
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-fix-tracenoc-probe-issue-v1-1-bcc785198fc5@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH v6 1/4] dt-bindings: soc: cix: add sky1 audss cru controller
From: Krzysztof Kozlowski @ 2026-06-24 6:49 UTC (permalink / raw)
To: joakim.zhang
Cc: mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt, p.zabel,
gary.yang, cix-kernel-upstream, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260623070805.211019-2-joakim.zhang@cixtech.com>
On Tue, Jun 23, 2026 at 03:08:02PM +0800, joakim.zhang@cixtech.com wrote:
> From: Joakim Zhang <joakim.zhang@cixtech.com>
>
> The Cix Sky1 Audio Subsystem (AUDSS) Clock and Reset Unit (CRU)
> groups clock muxing, gating and block-level software reset control
> in a single register block.
>
> Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> ---
> .../bindings/soc/cix/cix,sky1-audss-cru.yaml | 92 +++++++++++++++++++
> .../dt-bindings/clock/cix,sky1-audss-cru.h | 60 ++++++++++++
> .../dt-bindings/reset/cix,sky1-audss-cru.h | 25 +++++
> 3 files changed, 177 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/cix/cix,sky1-audss-cru.yaml
> create mode 100644 include/dt-bindings/clock/cix,sky1-audss-cru.h
> create mode 100644 include/dt-bindings/reset/cix,sky1-audss-cru.h
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 4/6] dt-bindings: input: sun4i-lradc-keys: Add A100/A133 compatible
From: Krzysztof Kozlowski @ 2026-06-24 6:51 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-arm-kernel, linux-sunxi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans de Goede, Dmitry Torokhov, Andre Przywara, Jun Yan,
Lukas Schmid, J. Neuschäfer, Eric Biggers, Michal Simek,
Luca Weiss, Sven Peter, Maxime Ripard, devicetree, linux-kernel,
linux-input
In-Reply-To: <20260623204824.691832-5-alexander.sverdlin@gmail.com>
On Tue, Jun 23, 2026 at 10:48:16PM +0200, Alexander Sverdlin wrote:
> The Allwinner A100/A133 SoCs have an LRADC which is compatible with the
> versions in existing SoCs. Add a compatible string for A100, with the R329
> fallback.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 3/3] MAINTAINERS: add entry for MAX86150 IIO health driver
From: Joshua Crofts @ 2026-06-24 6:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Md Shofiqul Islam, linux-iio, jic23, lars, conor, conor+dt, robh,
krzk+dt, devicetree, linux-kernel
In-Reply-To: <25846cbb-8318-43d1-a57e-16734cdad6bd@kernel.org>
On Wed, 24 Jun 2026 08:22:48 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 23/06/2026 22:11, Md Shofiqul Islam wrote:
> > Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
> > ---
> > MAINTAINERS | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
>
>
> You need to slow down, please. One version per 24h.
>
> And the last one is not even correct anymore...
Additionally, refrain from sending a separate patch for MAINTAINERS,
fold the new addition into your dt-binding patch, and then add the
F: entry for the driver code in the actual driver patch.
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: display: bridge: Document Renesas RZ/G3L LVDS encoder
From: Krzysztof Kozlowski @ 2026-06-24 6:54 UTC (permalink / raw)
To: Biju
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Tommaso Merciai,
dri-devel, devicetree, linux-kernel, linux-renesas-soc,
Prabhakar Mahadev Lad
In-Reply-To: <20260619101026.323633-2-biju.das.jz@bp.renesas.com>
On Fri, Jun 19, 2026 at 11:10:16AM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document the LVDS encoder IP found on the RZ/G3L SoC. It supports
> single-link mode. LVDS and the DSI interface share a peripheral clock and
> the MIPI_DSI_PRESET_N reset signal. However, the LVDS module cannot be
> used at the same time as MIPI-DSI.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 04/21] RISC-V: Define indirect CSR access helpers
From: Atish Patra @ 2026-06-24 6:55 UTC (permalink / raw)
To: Charlie Jenkins
Cc: James Clark, Rob Herring, Arnaldo Carvalho de Melo, Jiri Olsa,
Will Deacon, Mark Rutland, Anup Patel, Namhyung Kim,
Paul Walmsley, Krzysztof Kozlowski, Ian Rogers, linux-riscv,
linux-kernel, linux-perf-users, Conor Dooley, devicetree,
linux-arm-kernel
In-Reply-To: <ajjZR-R11yPYWuDp@blinky>
On 6/21/26 11:42 PM, Charlie Jenkins wrote:
> On Mon, Jun 08, 2026 at 11:01:18PM -0700, Atish Patra wrote:
>> From: Atish Patra <atishp@rivosinc.com>
>>
>> The indriect CSR requires multiple instructions to read/write CSR.
> indirect
>
>> Add a few helper functions for ease of usage.
>>
>> Signed-off-by: Atish Patra <atishp@rivosinc.com>
>> ---
>> arch/riscv/include/asm/csr_ind.h | 44 ++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/arch/riscv/include/asm/csr_ind.h b/arch/riscv/include/asm/csr_ind.h
>> new file mode 100644
>> index 000000000000..6fd7d44dc640
>> --- /dev/null
>> +++ b/arch/riscv/include/asm/csr_ind.h
>> @@ -0,0 +1,44 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (C) 2024 Rivos Inc.
> I don't think it makes sense to introduce this copyright in new commits.
Yeah. I will update these.
> - Charlie
>
>> + */
>> +
>> +#ifndef _ASM_RISCV_CSR_IND_H
>> +#define _ASM_RISCV_CSR_IND_H
>> +
>> +#include <linux/irqflags.h>
>> +
>> +#include <asm/csr.h>
>> +
>> +#define csr_ind_read(iregcsr, iselbase, iseloff) ({ \
>> + unsigned long __value = 0; \
>> + unsigned long __flags; \
>> + local_irq_save(__flags); \
>> + csr_write(CSR_ISELECT, (iselbase) + (iseloff)); \
>> + __value = csr_read(iregcsr); \
>> + local_irq_restore(__flags); \
>> + __value; \
>> +})
>> +
>> +#define csr_ind_write(iregcsr, iselbase, iseloff, value) ({ \
>> + unsigned long __flags; \
>> + local_irq_save(__flags); \
>> + csr_write(CSR_ISELECT, (iselbase) + (iseloff)); \
>> + csr_write(iregcsr, (value)); \
>> + local_irq_restore(__flags); \
>> +})
>> +
>> +#define csr_ind_warl(iregcsr, iselbase, iseloff, warl_val) ({ \
>> + unsigned long __old_val = 0, __value = 0; \
>> + unsigned long __flags; \
>> + local_irq_save(__flags); \
>> + csr_write(CSR_ISELECT, (iselbase) + (iseloff)); \
>> + __old_val = csr_read(iregcsr); \
>> + csr_write(iregcsr, (warl_val)); \
>> + __value = csr_read(iregcsr); \
>> + csr_write(iregcsr, __old_val); \
>> + local_irq_restore(__flags); \
>> + __value; \
>> +})
>> +
>> +#endif
>>
>> --
>> 2.53.0-Meta
>>
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>
^ permalink raw reply
* Re: [PATCH v6 17/21] RISC-V: perf: Add Qemu virt machine events
From: Atish Patra @ 2026-06-24 7:00 UTC (permalink / raw)
To: Charlie Jenkins
Cc: James Clark, Rob Herring, Arnaldo Carvalho de Melo, Jiri Olsa,
Will Deacon, Mark Rutland, Anup Patel, Namhyung Kim,
Paul Walmsley, Krzysztof Kozlowski, Ian Rogers, linux-riscv,
linux-kernel, linux-perf-users, Conor Dooley, devicetree,
linux-arm-kernel
In-Reply-To: <ajjZ5NljehUXERN1@blinky>
On 6/21/26 11:44 PM, Charlie Jenkins wrote:
> On Mon, Jun 08, 2026 at 11:01:31PM -0700, Atish Patra wrote:
>> From: Atish Patra <atishp@rivosinc.com>
>>
>> Qemu virt machine supports a very minimal set of legacy perf events.
>> Add them to the vendor table so that users can use them when
>> counter delegation is enabled.
>>
>> Signed-off-by: Atish Patra <atishp@rivosinc.com>
>> ---
>> arch/riscv/include/asm/vendorid_list.h | 4 ++++
>> drivers/perf/riscv_pmu_sbi.c | 36 ++++++++++++++++++++++++++++++++++
>> 2 files changed, 40 insertions(+)
>>
>> diff --git a/arch/riscv/include/asm/vendorid_list.h b/arch/riscv/include/asm/vendorid_list.h
>> index 7f5030ee1fcf..603aa2b21c0b 100644
>> --- a/arch/riscv/include/asm/vendorid_list.h
>> +++ b/arch/riscv/include/asm/vendorid_list.h
>> @@ -11,4 +11,8 @@
>> #define SIFIVE_VENDOR_ID 0x489
>> #define THEAD_VENDOR_ID 0x5b7
>>
>> +#define QEMU_VIRT_VENDOR_ID 0x000
>> +#define QEMU_VIRT_IMPL_ID 0x000
>> +#define QEMU_VIRT_ARCH_ID 0x000
> Palmer proposed a change to this a while ago to set the archid for qemu
> as 42 but it looks like it was never merged in qemu, but it was merged
> into the riscv spec.
>
> Here is the spec PR: https://github.com/riscv/riscv-isa-manual/pull/1213
> Here is the current spec: https://github.com/riscv/riscv-isa-manual/blob/main/marchid.md
> Here is the QEMU patch: https://lore.kernel.org/all/20240131182430.20174-1-palmer@rivosinc.com/
>
> Should we follow up with this/maybe this should be accounted for here as
> an alternate id?
Ahh yes. I remember that thread now. Thanks for digging this.
Yes. We should resurrect that patch and use that archid as an alternate ID.
> - Charlie
>
>> +
>> #endif
>> diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
>> index 00b84b28117a..74acac54328e 100644
>> --- a/drivers/perf/riscv_pmu_sbi.c
>> +++ b/drivers/perf/riscv_pmu_sbi.c
>> @@ -26,6 +26,7 @@
>> #include <asm/sbi.h>
>> #include <asm/cpufeature.h>
>> #include <asm/vendor_extensions.h>
>> +#include <asm/vendorid_list.h>
>> #include <asm/vendor_extensions/andes.h>
>> #include <asm/hwcap.h>
>> #include <asm/csr_ind.h>
>> @@ -453,7 +454,42 @@ struct riscv_vendor_pmu_events {
>> .hw_event_map = _hw_event_map, .cache_event_map = _cache_event_map, \
>> .attrs_events = _attrs },
>>
>> +/* QEMU virt PMU events */
>> +static const struct riscv_pmu_event qemu_virt_hw_event_map[PERF_COUNT_HW_MAX] = {
>> + PERF_MAP_ALL_UNSUPPORTED,
>> + [PERF_COUNT_HW_CPU_CYCLES] = {0x01, 0xFFFFFFF8},
>> + [PERF_COUNT_HW_INSTRUCTIONS] = {0x02, 0xFFFFFFF8}
>> +};
>> +
>> +static const struct riscv_pmu_event qemu_virt_cache_event_map[PERF_COUNT_HW_CACHE_MAX]
>> + [PERF_COUNT_HW_CACHE_OP_MAX]
>> + [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
>> + PERF_CACHE_MAP_ALL_UNSUPPORTED,
>> + [C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = {0x10019, 0xFFFFFFF8},
>> + [C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)] = {0x1001B, 0xFFFFFFF8},
>> +
>> + [C(ITLB)][C(OP_READ)][C(RESULT_MISS)] = {0x10021, 0xFFFFFFF8},
>> +};
>> +
>> +RVPMU_EVENT_CMASK_ATTR(cycles, cycles, 0x01, 0xFFFFFFF8);
>> +RVPMU_EVENT_CMASK_ATTR(instructions, instructions, 0x02, 0xFFFFFFF8);
>> +RVPMU_EVENT_CMASK_ATTR(dTLB-load-misses, dTLB_load_miss, 0x10019, 0xFFFFFFF8);
>> +RVPMU_EVENT_CMASK_ATTR(dTLB-store-misses, dTLB_store_miss, 0x1001B, 0xFFFFFFF8);
>> +RVPMU_EVENT_CMASK_ATTR(iTLB-load-misses, iTLB_load_miss, 0x10021, 0xFFFFFFF8);
>> +
>> +static struct attribute *qemu_virt_event_group[] = {
>> + RVPMU_EVENT_ATTR_PTR(cycles),
>> + RVPMU_EVENT_ATTR_PTR(instructions),
>> + RVPMU_EVENT_ATTR_PTR(dTLB_load_miss),
>> + RVPMU_EVENT_ATTR_PTR(dTLB_store_miss),
>> + RVPMU_EVENT_ATTR_PTR(iTLB_load_miss),
>> + NULL,
>> +};
>> +
>> static struct riscv_vendor_pmu_events pmu_vendor_events_table[] = {
>> + RISCV_VENDOR_PMU_EVENTS(QEMU_VIRT_VENDOR_ID, QEMU_VIRT_ARCH_ID, QEMU_VIRT_IMPL_ID,
>> + qemu_virt_hw_event_map, qemu_virt_cache_event_map,
>> + qemu_virt_event_group)
>> };
>>
>> static const struct riscv_pmu_event *current_pmu_hw_event_map;
>>
>> --
>> 2.53.0-Meta
>>
>>
^ permalink raw reply
* Re: [PATCH 2/13] dt-bindings: sound: Add Qualcomm QAIF binding
From: Harendra Gautam @ 2026-06-24 6:59 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Srinivas Kandagatla, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <7948feb4-9eca-48f2-944e-ec982b6823dd@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 9:18 PM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 6/23/26 2:26 PM, Harendra Gautam wrote:
> > On Tue, Jun 9, 2026 at 3:27 PM Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> wrote:
> >>
> >> On 6/5/26 12:37 PM, Harendra Gautam wrote:
> >>> Add a Devicetree binding for the Qualcomm Audio Interface (QAIF) CPU DAI
> >>> controller used on the Shikra audio platform.
> >>>
> >>> QAIF moves PCM data between system memory and external serial audio
> >>> interfaces through the AIF path, and between memory and the internal Bolero
> >>> digital codec through the CIF path. The controller needs a binding so
> >>> platform Devicetree files can describe its MMIO region, DMA IOMMU stream,
> >>> clocks, interrupt, DAI cells and per-interface AIF configuration.
> >>>
> >>> Describe the single register region, one EE interrupt, the required GCC
> >>> LPASS and audio core clocks, the DMA IOMMU mapping, and 'aif-interface@N'
> >>> child nodes used for static PCM, TDM or MI2S configuration.
> >>>
> >>> Signed-off-by: Harendra Gautam <harendra.gautam@oss.qualcomm.com>
> >>> ---
> >>
> >> [...]
> >>
> >>> + clock-names:
> >>> + items:
> >>> + - const: lpass_config_clk
> >>> + - const: lpass_core_axim_clk
> >>> + - const: aud_dma_clk
> >>> + - const: aud_dma_mem_clk
> >>> + - const: bus_clk
> >>> + - const: aif_if0_ebit_clk
> >>> + - const: aif_if0_ibit_clk
> >>> + - const: aif_if1_ebit_clk
> >>> + - const: aif_if1_ibit_clk
> >>> + - const: aif_if2_ebit_clk
> >>> + - const: aif_if2_ibit_clk
> >>> + - const: aif_if3_ebit_clk
> >>> + - const: aif_if3_ibit_clk
> >>> + - const: ext_mclka_clk
> >>> + - const: ext_mclkb_clk
> >>
> >> Drop the _clk suffix, we already know they are clocks, as they are
> >> listed under the clocks property
> > Okay, will correct.
> >>
> >> [...]
> >>
> >>> + qcom,qaif-aif-sync-mode:
> >>> + $ref: /schemas/types.yaml#/definitions/uint32
> >>> + description:
> >>> + Sync mode. Use QAIF_AIF_SYNC_MODE_SHORT (0) for short (pulse)
> >>> + sync or QAIF_AIF_SYNC_MODE_LONG (1) for long (level) sync.
> >>> + qcom,qaif-aif-sync-src:
> >>> + $ref: /schemas/types.yaml#/definitions/uint32
> >>> + description:
> >>> + Sync source. Use QAIF_AIF_SYNC_SRC_SLAVE (0) for slave mode
> >>> + or QAIF_AIF_SYNC_SRC_MASTER (1) for master mode.
> >>
> >> Should these be boolean flags then?
> > It should not be, the intention is to define explicitly, for better
> > readability I can rename these flags as EXTERNAL/INTERNAL, Please
> > suggest.
>
> Are all 4 combinations of them being present/absent valid on shikra?
>
> Konrad
Sorry if I did not put details properly, I will be correcting in the
next patch. sync-src can be external clock or internal clock, where 0
means external and 1 means internal.
-Harendra
^ permalink raw reply
* Re: [PATCH 2/13] dt-bindings: sound: Add Qualcomm QAIF binding
From: Harendra Gautam @ 2026-06-24 7:02 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Srinivas Kandagatla, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <a7852d0b-10ee-42ec-b966-28d3f2066bb1@kernel.org>
On Fri, Jun 5, 2026 at 4:16 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 05/06/2026 12:37, Harendra Gautam wrote:
> > Add a Devicetree binding for the Qualcomm Audio Interface (QAIF) CPU DAI
> > controller used on the Shikra audio platform.
> >
> > QAIF moves PCM data between system memory and external serial audio
> > interfaces through the AIF path, and between memory and the internal Bolero
> > digital codec through the CIF path. The controller needs a binding so
> > platform Devicetree files can describe its MMIO region, DMA IOMMU stream,
> > clocks, interrupt, DAI cells and per-interface AIF configuration.
> >
> > Describe the single register region, one EE interrupt, the required GCC
> > LPASS and audio core clocks, the DMA IOMMU mapping, and 'aif-interface@N'
> > child nodes used for static PCM, TDM or MI2S configuration.
> >
>
> A nit, subject: drop second/last, redundant "bindings". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Please use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching. For bindings, the preferred subjects are
> explained here:
> https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
>
> > Signed-off-by: Harendra Gautam <harendra.gautam@oss.qualcomm.com>
> > ---
> > .../devicetree/bindings/sound/qcom,qaif.yaml | 353 ++++++++++++++++++
> > 1 file changed, 353 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/sound/qcom,qaif.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/sound/qcom,qaif.yaml b/Documentation/devicetree/bindings/sound/qcom,qaif.yaml
> > new file mode 100644
> > index 000000000000..5b385e05a650
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sound/qcom,qaif.yaml
>
> Filename must match compatible.
Sure, Will correct in next patch.
>
> > @@ -0,0 +1,361 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/sound/qcom,qaif.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Qualcomm Audio Interface (QAIF) CPU DAI Controller
> > +
> > +maintainers:
> > + - Harendra Gautam <harendra.gautam@oss.qualcomm.com>
> > +
> > +description:
> > + |
> > + The Qualcomm Audio Interface (QAIF) is a fully configurable DMA-based
> > + audio subsystem controller. It serialises and deserialises PCM audio
> > + between system memory and external serial audio peripherals (PCM, TDM,
> > + I2S, MI2S) through the AIF path, and transfers parallel audio between
> > + memory and an internal WCD codec through the CIF path.
> > +
> > + AIF (Audio Interface): up to 13 multi-lane Unified Audio Interfaces,
> > + each supporting up to 8 independent data lanes. Each lane is individually
> > + configurable as TX (output/speaker) or RX (input/mic). All lanes of an
> > + interface share a single bit clock and frame sync. Supported modes are
> > + PCM (short/long sync), TDM, and MI2S (stereo/mono). Per-interface
> > + configuration includes sync source (master/slave), sync mode, sync delay,
> > + sync inversion, slot width (8/16/24/32-bit), sample width, active slot
> > + masks (up to 32 slots), bits-per-lane frame size, lane enable/direction
> > + masks, loopback, output-enable control, and full-cycle path support for
> > + long chip-to-chip connections.
> > +
> > + CIF (Codec Interface): up to 32 RDDMA (playback) and 32 WRDMA (capture)
> > + channels connecting to an internal codec over a parallel bus. Each channel
> > + supports active-channel enable mask (up to 16 channels), frame-sync
> > + selection, frame-sync delay, frame-sync output gating, dynamic clock
> > + gating, and 16-bit packing/unpacking.
> > +
> > + Note on RX/TX naming convention: in QAIF, RX refers to the capture path
> > + (audio received from the interface into memory) and TX refers to the
> > + playback path (audio transmitted from memory to the interface). This
> > + applies to both AIF lane directions and CIF slot/mask properties.
> > +
> > + DMA engine: RDDMA fetches audio from DDR/TCM/LPM into a shared SRAM
> > + latency buffer (SHRAM) and drains it to the interface. WRDMA collects
> > + data from the interface into SHRAM and writes it to memory. Each DMA
> > + owns a private SHRAM region defined by start address and length registers.
> > + Burst sizes of 1/2/4/8/16 beats (64-bit) are supported with up to 4
> > + outstanding transactions per DMA. Two QSB master ports (QXM0 for TCM,
> > + QXM1 for DDR/LPM) provide the memory interface.
> > +
> > + Resources are partitioned among up to 5 Execution Engines (EEs) via
> > + EE map registers. Each EE owns a set of DMAs, audio interfaces, and
> > + interface groups, and receives its own independent interrupt output.
> > + The interrupt hierarchy has a two-level structure: a summary register
> > + identifies the event class (DMA period, underflow/overflow, error
> > + response, audio interface underflow/overflow, group done, rate detector,
> > + VFR), and per-resource status registers identify the specific channel.
> > +
> > + Interface grouping (bonding) allows up to 6 groups of audio and codec
> > + interfaces to start synchronously and align their DMA period interrupts
> > + within half a frame duration using the RDDMA padding feature.
> > +
> > + Two rate detector blocks measure the frequency of incoming frame sync or
> > + word select signals and generate interrupts on rate change, undetected
> > + rate, or sync timeout.
> > +
> > + Block diagram::
> > +
> > + System Memory (DDR / LPM / TCM)
> > + +---------------------------------+
> > + | Circular Buffers (ping-pong) |
> > + +----------+----------+-----------+
> > + | ^
> > + 64-bit AXI 64-bit AXI
> > + | |
> > + +----------v----------+-----------+
> > + | QSB Master Ports |
> > + | +----------+ +----------+ |
> > + | | QXM0 | | QXM1 | |
> > + | +----+-----+ +-----+----+ |
> > + +-------|--------------|----------+
> > + | |
> > + +-------v--------------v----------+
> > + | Shared RAM (SHRAM) |
> > + | +------------+ +------------+ |
> > + | | QXM0 Read | | QXM0 Write | |
> > + | | SHRAM | | SHRAM | |
> > + | +------------+ +------------+ |
> > + | +------------+ +------------+ |
> > + | | QXM1 Read | | QXM1 Write | |
> > + | | SHRAM | | SHRAM | |
> > + | +------------+ +------------+ |
> > + +---+--------+--------+-------+---+
> > + | | | |
> > + +---v--+ +--v---+ +--v---+ +-v----+
> > + |RDDMA | |RDDMA | |WRDMA | |WRDMA |
> > + | AIF | | CIF | | AIF | | CIF |
> > + |[0..n]| |[0..n]| |[0..n]| |[0..n]|
> > + +--+---+ +--+---+ +--+---+ +-+----+
> > + | | ^ ^
> > + | TX | TX | RX | RX
> > + v v | |
> > + +--+--------------------+ +----+----------+
> > + | Unified Audio Intf | | Codec DMA |
> > + | (AIF 0..12) | | Interface |
> > + | | | (CIF) |
> > + | AUD_INTFa block: | | |
> > + | - Serializer (TX) | | RDDMA: DDR -> |
> > + | - De-serializer (RX) | | internal |
> > + | - Sync gen/detect | | codec |
> > + | - Up to 8 data lanes | | WRDMA: codec |
> > + | - PCM / TDM / MI2S | | -> DDR |
> > + | - Near Pad Logic | | Up to 16 ch |
> > + +--+--------------------+ +----+----------+
> > + | Lane 0..7 (TX/RX) | Parallel bus
> > + | Bit clk + Frame sync | + Frame sync
> > + v v
> > + +--+--------+ +------+------+
> > + | External | | Internal |
> > + | Serial | | Digital |
> > + | Peripherals| | Codec |
> > + | (PCM/TDM/ | | (Bolero/ |
> > + | MI2S) | | WCD) |
> > + +-----------+ +-------------+
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - qcom,shikra-qaif-cpu
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + iommus:
> > + maxItems: 1
> > +
> > + clocks:
> > + minItems: 15
>
> Drop
Sure, Will correct in next patch.
>
> > + maxItems: 15
> > +
> > + clock-names:
> > + items:
> > + - const: lpass_config_clk
> > + - const: lpass_core_axim_clk
> > + - const: aud_dma_clk
> > + - const: aud_dma_mem_clk
> > + - const: bus_clk
> > + - const: aif_if0_ebit_clk
> > + - const: aif_if0_ibit_clk
> > + - const: aif_if1_ebit_clk
> > + - const: aif_if1_ibit_clk
> > + - const: aif_if2_ebit_clk
> > + - const: aif_if2_ibit_clk
> > + - const: aif_if3_ebit_clk
> > + - const: aif_if3_ibit_clk
> > + - const: ext_mclka_clk
> > + - const: ext_mclkb_clk
>
> Drop _clk everywhere
Sure, Will correct in next patch.
>
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + '#sound-dai-cells':
> > + const: 1
> > +
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 0
> > +
> > + status: true
>
> Please do not invent own style. Is there any binding with something like
> that?
>
> I finish here. Why? Because you sent DIFFERENT binding to internal
> review. Then you made completely confusing changes and never reviewed it
> internally again.
>
> The internal review which Qualcomm implemented is for purpose of not
> wasting community time on reviewing trivialities. You bypassing this and
> sending us the trivialities feels like that wasting time is okay?
>
> No, it is not okay.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDA 850
From: Mukesh Ojha @ 2026-06-24 7:02 UTC (permalink / raw)
To: david
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260623-sda850-v1-1-ddd8e62c85d8@ixit.cz>
On Tue, Jun 23, 2026 at 08:41:34PM +0200, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> Add SoC ID for Qualcomm Snapdragon SDA850.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
--
-Mukesh Ojha
^ permalink raw reply
* RE: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Sherry Sun @ 2026-06-24 7:09 UTC (permalink / raw)
To: Frank Li (OSS), Sherry Sun (OSS)
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, Amitkumar Karwar, Neeraj Sanjay Kale,
marcel@holtmann.org, luiz.dentz@gmail.com, Hongxing Zhu,
l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <ajqZBM6IkbDLiVu2@SMW015318>
> Subject: Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
>
> On Tue, Jun 23, 2026 at 11:07:28AM +0800, Sherry Sun (OSS) wrote:
> > From: Sherry Sun <sherry.sun@nxp.com>
> >
> > Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> > suspend to preserve wakeup capability of the devices and also not to
> > power on the devices in the init path.
> > This allows controller power-off to be skipped when some devices(e.g.
> > M.2 cards key E without auxiliary power) required to support PCIe L2
> > link state and wake-up mechanisms.
> >
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 36
> > +++++++++++++++++----------
> > 1 file changed, 23 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 0fa716d1ed75..ff5a9565dbbf 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -1382,16 +1382,20 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > }
> > }
> >
> > - ret = pci_pwrctrl_create_devices(dev);
> > - if (ret) {
> > - dev_err(dev, "failed to create pwrctrl devices\n");
> > - goto err_reg_disable;
> > + if (!pci->suspended) {
> > + ret = pci_pwrctrl_create_devices(dev);
>
> Is possible move pci_pwrctrl_create_devices() of pci_pwrctrl_create_devices
>
> and call it direct at probe() function, like other regulator_get function.
>
Hi Frank,
That makes sense. However, if we move pci_pwrctrl_create_devices () to
probe(), we may need to add the following goto err_pwrctrl_destroy path
in imx_pcie_probe() to properly handle errors from
pci_pwrctrl_power_on_devices(), is that acceptable?
@@ -1960,11 +1949,15 @@ static int imx_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = pci_pwrctrl_create_devices(dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to create pwrctrl devices\n");
+
pci->use_parent_dt_ranges = true;
if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
ret = imx_add_pcie_ep(imx_pcie, pdev);
if (ret < 0)
- return ret;
+ goto err_pwrctrl_destroy;
/*
* FIXME: Only single Device (EPF) is supported due to the
@@ -1979,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device *pdev)
pci->pp.use_atu_msg = true;
ret = dw_pcie_host_init(&pci->pp);
if (ret < 0)
- return ret;
+ goto err_pwrctrl_destroy;
if (pci_msi_enabled()) {
u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
@@ -1991,6 +1984,11 @@ static int imx_pcie_probe(struct platform_device *pdev)
}
return 0;
+
+err_pwrctrl_destroy:
+ if (ret != -EPROBE_DEFER)
+ pci_pwrctrl_destroy_devices(dev);
+ return ret;
}
Best Regards
Sherry
>
> > + if (ret) {
> > + dev_err(dev, "failed to create pwrctrl devices\n");
> > + goto err_reg_disable;
> > + }
> > }
> >
> > - ret = pci_pwrctrl_power_on_devices(dev);
> > - if (ret) {
> > - dev_err(dev, "failed to power on pwrctrl devices\n");
> > - goto err_pwrctrl_destroy;
> > + if (!pp->skip_pwrctrl_off) {
> > + ret = pci_pwrctrl_power_on_devices(dev);
> > + if (ret) {
> > + dev_err(dev, "failed to power on pwrctrl devices\n");
> > + goto err_pwrctrl_destroy;
> > + }
> > }
> >
> > ret = imx_pcie_clk_enable(imx_pcie); @@ -1460,9 +1464,10 @@
> static
> > int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > err_clk_disable:
> > imx_pcie_clk_disable(imx_pcie);
> > err_pwrctrl_power_off:
> > - pci_pwrctrl_power_off_devices(dev);
> > + if (!pp->skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(dev);
> > err_pwrctrl_destroy:
> > - if (ret != -EPROBE_DEFER)
> > + if (ret != -EPROBE_DEFER && !pci->suspended)
> > pci_pwrctrl_destroy_devices(dev);
> > err_reg_disable:
> > if (imx_pcie->vpcie)
> > @@ -1482,7 +1487,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp
> *pp)
> > }
> > imx_pcie_clk_disable(imx_pcie);
> >
> > - pci_pwrctrl_power_off_devices(pci->dev);
> > + if (!pci->pp.skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(pci->dev);
> > if (imx_pcie->vpcie)
> > regulator_disable(imx_pcie->vpcie);
> > }
> > @@ -1990,12 +1996,16 @@ static int imx_pcie_probe(struct
> > platform_device *pdev) static void imx_pcie_shutdown(struct
> > platform_device *pdev) {
> > struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> > + struct dw_pcie *pci = imx_pcie->pci;
> > + struct dw_pcie_rp *pp = &pci->pp;
> >
> > /* bring down link, so bootloader gets clean state in case of reboot */
> > imx_pcie_assert_core_reset(imx_pcie);
> > imx_pcie_assert_perst(imx_pcie, true);
> > - pci_pwrctrl_power_off_devices(&pdev->dev);
> > - pci_pwrctrl_destroy_devices(&pdev->dev);
> > + if (!pp->skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(&pdev->dev);
> > + if (!pci->suspended)
> > + pci_pwrctrl_destroy_devices(&pdev->dev);
> > }
> >
> > static const struct imx_pcie_drvdata drvdata[] = {
> > --
> > 2.50.1
> >
> >
^ permalink raw reply
* Re: [PATCH v7 6/6] remoteproc: qcom_q6v5_pas: Add SoCCP node on Kaanapali
From: Mukesh Ojha @ 2026-06-24 7:09 UTC (permalink / raw)
To: Jingyi Wang
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Bartosz Golaszewski, Kumar Patro, Komal Bajaj,
Konrad Dybcio, aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Dmitry Baryshkov, Bartosz Golaszewski
In-Reply-To: <20260623-knp-soccp-v7-6-1ec7bb5c9fec@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 03:05:22AM -0700, Jingyi Wang wrote:
> The SoC Control Processor (SoCCP) is small RISC-V MCU that controls
> USB Type-C, battery charging and various other functions on Qualcomm SoCs.
> It provides a solution for control-plane processing, reducing per-subsystem
> microcontroller reinvention. Add support for SoCCP PAS loader on Kaanapali
> platform.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_q6v5_pas.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index 8a0bb4b2e71c..60a4337d9e51 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -1640,8 +1640,26 @@ static const struct qcom_pas_data sm8750_mpss_resource = {
> .region_assign_vmid = QCOM_SCM_VMID_MSS_MSA,
> };
>
> +static const struct qcom_pas_data kaanapali_soccp_resource = {
> + .crash_reason_smem = 656,
> + .firmware_name = "soccp.mbn",
> + .dtb_firmware_name = "soccp_dtb.mbn",
> + .pas_id = 51,
> + .dtb_pas_id = 0x41,
> + .proxy_pd_names = (char*[]){
> + "cx",
> + "mx",
> + NULL
> + },
> + .ssr_name = "soccp",
> + .sysmon_name = "soccp",
> + .auto_boot = true,
> + .early_boot = true,
> +};
> +
> static const struct of_device_id qcom_pas_of_match[] = {
> { .compatible = "qcom,eliza-adsp-pas", .data = &sm8550_adsp_resource },
> + { .compatible = "qcom,kaanapali-soccp-pas", .data = &kaanapali_soccp_resource },
> { .compatible = "qcom,milos-adsp-pas", .data = &sm8550_adsp_resource },
> { .compatible = "qcom,milos-cdsp-pas", .data = &milos_cdsp_resource },
> { .compatible = "qcom,milos-mpss-pas", .data = &sm8450_mpss_resource },
>
Since, this is fully compatible with Hawi SoC, I tested it on Hawi SoC.
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Hawi SoC
--
-Mukesh Ojha
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox