* [PATCH v3 4/4] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: add Function key support
From: Nick Xie @ 2026-03-25 7:06 UTC (permalink / raw)
To: neil.armstrong, khilman, martin.blumenstingl, jbrunet, jic23,
dlechner, andy
Cc: krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel, Nick Xie
In-Reply-To: <20260325070618.81955-1-nick@khadas.com>
Enable the SARADC controller and add the adc-keys node to support
the Function key found on the Khadas VIM1S board.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Nick Xie <nick@khadas.com>
---
.../amlogic/meson-s4-s905y4-khadas-vim1s.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
index 664d64a267f2d..792ab45c4c944 100644
--- a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
@@ -40,6 +40,20 @@ secmon_reserved: secmon@5000000 {
};
};
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1710000>;
+ poll-interval = <100>;
+
+ button-function {
+ label = "Function";
+ linux,code = <KEY_FN>;
+ press-threshold-microvolt = <10000>;
+ };
+ };
+
emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
@@ -278,6 +292,11 @@ brcmf: wifi@1 {
};
};
+&saradc {
+ status = "okay";
+ vref-supply = <&vddio_ao1v8>;
+};
+
&spicc0 {
status = "okay";
pinctrl-names = "default";
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/4] arm64: dts: amlogic: meson-s4: add internal SARADC controller
From: Nick Xie @ 2026-03-25 7:06 UTC (permalink / raw)
To: neil.armstrong, khilman, martin.blumenstingl, jbrunet, jic23,
dlechner, andy
Cc: krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel, Nick Xie
In-Reply-To: <20260325070618.81955-1-nick@khadas.com>
Add the SARADC (Successive Approximation Register ADC) controller
node to the Meson S4 SoC dtsi.
It uses the S4-specific compatible string with a fallback to the
G12A generation, as there are no known hardware differences.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Nick Xie <nick@khadas.com>
---
arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
index 4a3e9ad82d280..936a5c1353d15 100644
--- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
@@ -77,6 +77,20 @@ pwrc: power-controller {
};
};
+ saradc: adc@fe026000 {
+ compatible = "amlogic,meson-s4-saradc",
+ "amlogic,meson-g12a-saradc";
+ reg = <0x0 0xfe026000 0x0 0x48>;
+ #io-channel-cells = <1>;
+ interrupts = <GIC_SPI 181 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>,
+ <&clkc_periphs CLKID_SAR_ADC>,
+ <&clkc_periphs CLKID_SARADC>,
+ <&clkc_periphs CLKID_SARADC_SEL>;
+ clock-names = "clkin", "core", "adc_clk", "adc_sel";
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/4] iio: adc: meson-saradc: add support for Meson S4
From: Nick Xie @ 2026-03-25 7:06 UTC (permalink / raw)
To: neil.armstrong, khilman, martin.blumenstingl, jbrunet, jic23,
dlechner, andy
Cc: krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel, Nick Xie
In-Reply-To: <20260325070618.81955-1-nick@khadas.com>
Add support for the SARADC found on the Amlogic Meson S4 SoC.
According to the documentation and current testing, it is fully
compatible with the G12A parameter set, so we reuse
`meson_sar_adc_g12a_data` for this new compatible string.
Although the device tree fallback mechanism could handle the match,
a dedicated entry is added to ensure the userspace ABI correctly
reports the specific part name ("meson-s4-saradc"). This allows
userspace to accurately identify the exact device and maintains
consistency across different firmware types where automatic fallback
parsing might be problematic.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Nick Xie <nick@khadas.com>
---
drivers/iio/adc/meson_saradc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 47cd350498a0d..3ac48b7842c4f 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -1313,6 +1313,11 @@ static const struct meson_sar_adc_data meson_sar_adc_g12a_data = {
.name = "meson-g12a-saradc",
};
+static const struct meson_sar_adc_data meson_sar_adc_s4_data = {
+ .param = &meson_sar_adc_g12a_param,
+ .name = "meson-s4-saradc",
+};
+
static const struct of_device_id meson_sar_adc_of_match[] = {
{
.compatible = "amlogic,meson8-saradc",
@@ -1341,6 +1346,9 @@ static const struct of_device_id meson_sar_adc_of_match[] = {
}, {
.compatible = "amlogic,meson-g12a-saradc",
.data = &meson_sar_adc_g12a_data,
+ }, {
+ .compatible = "amlogic,meson-s4-saradc",
+ .data = &meson_sar_adc_s4_data,
},
{ }
};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: iio: adc: amlogic,meson-saradc: add S4 compatible
From: Nick Xie @ 2026-03-25 7:06 UTC (permalink / raw)
To: neil.armstrong, khilman, martin.blumenstingl, jbrunet, jic23,
dlechner, andy
Cc: krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel, Nick Xie
In-Reply-To: <20260325070618.81955-1-nick@khadas.com>
Add the compatible string for the SARADC (Successive Approximation
Register ADC) IP block found in the Amlogic Meson S4 SoC.
There are no known differences between the SARADC on S4 and the one
on G12A. Therefore, it uses "amlogic,meson-g12a-saradc" as a proper
specific fallback.
Also add a comment indicating that "amlogic,meson-saradc" must not be
used for new devices. It's a made up compatible string that does not
correspond to a specific hardware generation and is not used to match
any driver. For old devices we keep it as it's part of the ABI.
Signed-off-by: Nick Xie <nick@khadas.com>
---
.../devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml
index bb9825e7346dd..70ab4e140e71b 100644
--- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml
@@ -27,7 +27,11 @@ properties:
- amlogic,meson-gxm-saradc
- amlogic,meson-axg-saradc
- amlogic,meson-g12a-saradc
+ # Usage of this generic fallback is not allowed for new devices
- const: amlogic,meson-saradc
+ - items:
+ - const: amlogic,meson-s4-saradc
+ - const: amlogic,meson-g12a-saradc
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/4] iio: adc: meson-saradc: add support for Meson S4
From: Nick Xie @ 2026-03-25 7:06 UTC (permalink / raw)
To: neil.armstrong, khilman, martin.blumenstingl, jbrunet, jic23,
dlechner, andy
Cc: krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel, Nick Xie
This series adds support for the SARADC IP block found in the Amlogic
Meson S4 (S905Y4) SoC and enables it for the Khadas VIM1S board to
support the onboard ADC 'Function' key.
There are no known hardware differences between the SARADC on the S4
and the previous G12A generation. The S4 bindings utilize a fallback
to G12A, but a dedicated driver match entry is included to ensure the
correct part name is exposed to the userspace ABI.
Changes in v3:
- Patch 1: Updated the commit message to explicitly explain why the
comment regarding the generic fallback was added.
- Patch 2: Retained the driver patch and updated the commit message to
clarify that the dedicated match entry is kept specifically for
userspace ABI naming purposes.
- Link to v2: https://lore.kernel.org/all/20260323013408.429701-1-nick@khadas.com/
Changes in v2:
- Addressed feedback from Krzysztof Kozlowski:
- Updated dt-bindings commit message to explain the hardware compatibility.
- Separated the S4 compatible string in the YAML bindings to ensure it
correctly falls back to the specific "amlogic,meson-g12a-saradc" rather
than the generic "amlogic,meson-saradc".
- Updated the S4 SoC dtsi to use the correct G12A fallback.
- Added Martin's Reviewed-by tags where appropriate.
- Link to v1: https://lore.kernel.org/all/20260228065840.702651-1-nick@khadas.com/
Nick Xie (4):
dt-bindings: iio: adc: amlogic,meson-saradc: add S4 compatible
iio: adc: meson-saradc: add support for Meson S4
arm64: dts: amlogic: meson-s4: add internal SARADC controller
arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: add Function key
support
.../iio/adc/amlogic,meson-saradc.yaml | 4 ++++
.../amlogic/meson-s4-s905y4-khadas-vim1s.dts | 19 +++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 14 ++++++++++++++
drivers/iio/adc/meson_saradc.c | 8 ++++++++
4 files changed, 45 insertions(+)
--
2.34.1
^ permalink raw reply
* RE: [PATCH v2 0/7] iommu/arm-smmu-v3: Quarantine device upon ATC invalidation timeout
From: Tian, Kevin @ 2026-03-25 6:55 UTC (permalink / raw)
To: Jason Gunthorpe, Nicolin Chen
Cc: will@kernel.org, robin.murphy@arm.com, joro@8bytes.org,
bhelgaas@google.com, rafael@kernel.org, lenb@kernel.org,
praan@google.com, baolu.lu@linux.intel.com,
xueshuai@linux.alibaba.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
Vikram Sethi
In-Reply-To: <20260324000321.GX7340@nvidia.com>
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Tuesday, March 24, 2026 8:03 AM
>
> On Wed, Mar 18, 2026 at 08:10:01PM -0700, Nicolin Chen wrote:
> > On Thu, Mar 19, 2026 at 02:29:38AM +0000, Tian, Kevin wrote:
> > > > > > This series addresses a critical vulnerability and stability issue where
> an
> > > > > > unresponsive PCIe device failing to process ATC (Address Translation
> > > > Cache)
> > > > > > invalidation requests leads to silent data corruption and continuous
> > > > SMMU
> > > > > > CMDQ error spam.
> > > > > >
> > > > >
> > > > > None of the patches in this series contains a Fixed tag and cc stable.
> > > >
> > > > Hmm, I guess AI overly polished the cover letter so it sounds too
> > > > strong?
> > > >
> > > > This is essentially a vulnerability (potential memory corruption).
> > > > And none of these patches actually fixes any regression. The PATCH
> > > > 7 even requires the arm_smmu_invs series which has not been merged
> > > > yet :-/
> > > >
> > >
> > > Fixes tag and backporting are not just for regression. People certainly
> > > want to see reported vulnerabilities fixed in stable kernels...
> >
> > Well, maybe I'll just leave additional line telling people that this
> > can't be a bug "fix" because it's written on another unmerged series?
>
> I think this is more of a feature (RAS support for SMMUv3) than a
> specific fix.
>
Not a RAS guy, but below is what I got from AI:
"
RAS improvements typically involve better error reporting, graceful
degradation, or improved recovery - but they usually don't involve
scenarios where the system continues operating with compromised
security assumptions."
^ permalink raw reply
* Re: [PATCH v3] PCI: dw-rockchip: Enable async probe by default
From: Lukas Wunner @ 2026-03-25 6:36 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Danilo Krummrich, Robin Murphy, Manivannan Sadhasivam,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Heiko Stuebner, Niklas Cassel, Shawn Lin, Hans Zhang,
Nicolas Frattaroli, Wilfred Mallawa, linux-pci, linux-arm-kernel,
linux-rockchip, linux-kernel, Anand Moon, Grimmauld,
Greg Kroah-Hartman, Rafael J. Wysocki, driver-core
In-Reply-To: <acNYJ2dyPaEzabYL@google.com>
On Tue, Mar 24, 2026 at 08:44:22PM -0700, Dmitry Torokhov wrote:
> I think the bigger question is why PCI does something different from
> every other bus? Why doesn't it rely on driver core to bind devices to
> driver?
This was introduced in 2013 with commit 4f535093cf8f ("PCI: Put pci_dev
in device tree as early as possible"). Corresponding patch submission:
https://lore.kernel.org/all/1358803252-20639-12-git-send-email-yinghai@kernel.org/
The rationale in the commit message for performing device registration
earlier is that devices would otherwise not be found by for_each_pci_dev().
I don't know why that was a problem at the time. The patch is the last
one in the series, so there's no other patch succeeding and thus
depending on it, which could provide a clue why this was necessary.
Needless to say, changing the behavior now risks regressions.
The author of the patch is apparently no longer around. Last activity
on the mailing list was in October 2017. Access to kernel.org infra
persists though, so maybe he's still reachable:
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/plain/keys/A7C92F7A39BD11DA.asc
I'm not defending the patch, merely trying to explain the history
as far as it is possible.
Thanks,
Lukas
^ permalink raw reply
* Re: [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: Zhiyong Tao (陶志勇) @ 2026-03-25 6:39 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: Project_Global_Digits_Upstream_Group, fred2599@gmail.com,
Yenchia Chen (陳彥嘉),
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
Liguo Zhang (张立国), jirislaby@kernel.org,
linux-serial@vger.kernel.org, Vasanth Reddy,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <2026031837-slimness-playset-a62b@gregkh>
On Wed, 2026-03-18 at 15:19 +0100, gregkh@linuxfoundation.org wrote:
> On Wed, Mar 18, 2026 at 12:12:36PM +0000, Zhiyong Tao (陶志勇) wrote:
> > On Wed, 2026-01-21 at 14:23 +0800, Zhiyong Tao wrote:
> > > On Tue, 2026-01-06 at 11:02 +0100, Greg KH wrote:
> > > > On Mon, Jan 05, 2026 at 10:39:55AM +0800, Zhiyong Tao wrote:
> > > > > From: "Zhiyong.Tao" <zhiyong.tao@mediatek.com>
> > > > >
> > > > > Add ACPI support to 8250_mtk driver. This makes it possible
> > > > > to
> > > > > use UART on ARM-based desktops with EDK2 UEFI firmware.
> > > > >
> > > > > Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com>
> > > > > Signed-off-by: Zhiyong.Tao <zhiyong.tao@mediatek.com>
> > > > > ---
> > > > > drivers/tty/serial/8250/8250_mtk.c | 23 +++++++++++++++++++-
> > > > > ---
> > > > > 1 file changed, 19 insertions(+), 4 deletions(-)
==>Hi Greg,
Yes, it is a resend of the previous version to rebase to tip for
friendly ping. it is based on the latest linux-next version.
Thanks
> > > >
> > > > This is a resend of the previous version, right? Or did
> > > > something
> > > > change?
> > > >
> > > > confused,
> > > >
> > > > greg k-h
> > >
> > > ==> Hi Greg,
> > > Yes, previously Yenchia Chen helped to send out a version.
> > > Currently,
> > > this solution is specifically for the GB10 project and was made
> > > to
> > > support Windows ACPI settings.
> > >
> > > In actual application scenarios, the apdma clk will not be turned
> > > off
> > > in normal mode. It is only turned off in the SSPM microprocessor
> > > after
> > > entering standby, and when resuming, the apdma clk is re-enabled
> > > by
> > > SSPM.
> > >
> > > As for other Linux projects, apdma still uses the DTS node.
> > >
> > > Thanks
> > >
> >
> > Hi Greg,
> > Do you have other suggestion for this?
>
> You can't just resend something and not say why you are resending it.
> Also, the authorship information seems to be backwards.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH v13 00/48] arm64: Support for Arm CCA in KVM
From: Gavin Shan @ 2026-03-25 6:37 UTC (permalink / raw)
To: Steven Price, Mathieu Poirier
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Suzuki K Poulose, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <37bc1222-6fc7-48f0-94d3-6eaac420aa55@arm.com>
Hi Steven,
On 3/21/26 2:45 AM, Steven Price wrote:
> On 19/03/2026 23:02, Mathieu Poirier wrote:
[...]
>>>
>>> The TF-RMM has not yet merged the RMMv2.0 support, so you will need to
>>> use the following branch:
>>>
>>> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc
>>
>> This RMM version is expecting a RMM EL3 interface version of at least 2.0. Do
>> you have a TF-A to use with it?
>
> You should be able to use the 'master' branch of the TF-A repository.
> For now you need to set RMM_V1_COMPAT=0 to enable 2.0 support.
>
In upstream TF-A repository [1], I don't see the config option 'RMM_V1_COMPAT'.
would it be something else?
[1] git@github.com:ARM-software/arm-trusted-firmware.git (branch: master)
I use the following command to build TF-A image. The RMM-EL3 compatible issue is
still seen.
TFA_PATH=$PWD
EDK2_IMAGE=${TFA_PATH}/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC5/FV/QEMU_EFI.fd
RMM_IMAGE=${TFA_PATH}/../tf-rmm/build-qemu/Debug/rmm.img
make CROSS_COMPILE=aarch64-none-elf- \
PLAT=qemu ENABLE_RME=1 RMM_V1_COMPAT=0 DEBUG=1 LOG_LEVEL=40 \
QEMU_USE_GIC_DRIVER=QEMU_GICV3 \
BL33=${EDK2_IMAGE} RMM=${RMM_IMAGE} \
-j 8 all fip
Booting messages
================
INFO: BL31: Initializing runtime services
INFO: RMM setup done.
INFO: BL31: Initializing RMM
INFO: RMM init start.
ERROR: RMM init failed: -2
WARNING: BL31: RMM initialization failed
Thanks,
Gavin
^ permalink raw reply
* [PATCH v3] nvme: Add nvme_setup_cmd to host_path_error
From: 전민식 @ 2026-03-25 6:33 UTC (permalink / raw)
To: Justin Tee, kbusch@kernel.org, axboe@kernel.dk
Cc: sven@kernel.org, j@jannau.net, neal@gompa.dev, hch@lst.de,
sagi@grimberg.me, justin.tee@broadcom.com,
nareshgottumukkala83@gmail.com, paul.ely@broadcom.com,
kch@nvidia.com, linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, asahi@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <945a3e98-ee75-453c-ae80-f3c9e3e57e58@gmail.com>
Hi Justin,
After your feedback, I found a simpler approach.
I've modified the patch to add nvme_setup_cmd() inside
host_path_error(). I think this patch won't cause side effect.
Please leave a review. Thank you.
- Before
nvme_complete_rq: \
nvme0: qid=0, cmdid=0, res=0x0, retries=0, flags=0x2, status=0x370
- After
nvme_setup_cmd: \
nvme0: qid=0, cmdid=32777, nsid=0, flags=0x0, meta=0x0, \
cmd=(nvme_admin_identify cns=1, ctrlid=0)
nvme_complete_rq: \
nvme0: qid=0, cmdid=32777, res=0x0, retries=0, flags=0x2, status=0x370
Regards,
Minsik Jeon
From 98af885be8314dc9093983c531fc36b454b78e81 Mon Sep 17 00:00:00 2001
From: Minsik Jeon <hmi.jeon@samsung.com>
Date: Wed, 25 Mar 2026 15:58:20 +0900
Subject: [PATCH v3] nvme: Add nvme_setup_cmd to host_path_error
we were checking host_pathing_error before calling nvme_setup_cmd().
This is caused the command setup to be skipped entirely when a pathing
error occurred, making it impossible to trace the nvme command via
trace_cmd nvme_complete_rq().
As a result, when nvme_complete_rq() logged a completion with cmdid=0,
it was impossible to correlate the completion with the nvme command
request.
This patch add nvme_setup_cmd() to nvme_host_path_error().
- Before
nvme_complete_rq: \
nvme0: qid=0, cmdid=0, res=0x0, retries=0, flags=0x2, status=0x370
- After
nvme_setup_cmd: \
nvme0: qid=0, cmdid=32777, nsid=0, flags=0x0, meta=0x0, \
cmd=(nvme_admin_identify cns=1, ctrlid=0)
nvme_complete_rq: \
nvme0: qid=0, cmdid=32777, res=0x0, retries=0, flags=0x2, status=0x370
Co-authored-by: Beomsoo Kim <beomsooo.kim@samsung.com>
Co-authored-by: Eunsoo Lee <euns212.lee@samsung.com>
Co-authored-by: Steven Seungcheol Lee <sc108.lee@samsung.com>
Signed-off-by: Minsik Jeon <hmi.jeon@samsung.com>
---
drivers/nvme/host/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 766e9cc4ffca..378d28b2c971 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -512,6 +512,7 @@ EXPORT_SYMBOL_GPL(nvme_complete_batch_req);
blk_status_t nvme_host_path_error(struct request *req)
{
nvme_req(req)->status = NVME_SC_HOST_PATH_ERROR;
+ nvme_setup_cmd(req->q->queuedata, req);
blk_mq_set_request_complete(req);
nvme_complete_rq(req);
return BLK_STS_OK;
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 3/3] KVM: arm64: selftests: Enable stage-2 in NV preparation functions
From: Itaru Kitayama @ 2026-03-25 6:23 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel,
Paolo Bonzini, Shuah Khan, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <20260325003620.2214766-4-weilin.chang@arm.com>
Hi Wei Lin,
On Wed, Mar 25, 2026 at 12:36:20AM +0000, Wei-Lin Chang wrote:
> Introduce library functions for setting up guest stage-2 page tables,
> then use that to give L2 an identity mapped stage-2 and enable it.
>
> The translation and stage-2 page table built is simple, start level 0,
> 4 levels, 4KB granules, normal cachable, 48-bit IA, 40-bit OA.
>
> The nested page table code is adapted from lib/x86/vmx.c.
>
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> .../selftests/kvm/include/arm64/nested.h | 7 ++
> .../selftests/kvm/include/arm64/processor.h | 9 ++
> .../testing/selftests/kvm/lib/arm64/nested.c | 97 ++++++++++++++++++-
> 3 files changed, 111 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
> index 739ff2ee0161..0be10a775e48 100644
> --- a/tools/testing/selftests/kvm/include/arm64/nested.h
> +++ b/tools/testing/selftests/kvm/include/arm64/nested.h
> @@ -6,6 +6,13 @@
> #ifndef SELFTEST_KVM_NESTED_H
> #define SELFTEST_KVM_NESTED_H
>
> +uint64_t get_l1_vtcr(void);
Using a type u64 is simpler? And I think you configure guest
hypervisor's stage 2 translation table, I felt this gives us
an impression somewhere the configuration IA and OA sizes etc
are stored.
> +
> +void nested_map(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> + uint64_t nested_paddr, uint64_t paddr, uint64_t size);
> +void nested_map_memslot(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> + uint32_t memslot);
> +
> void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc);
> diff --git a/tools/testing/selftests/kvm/include/arm64/processor.h b/tools/testing/selftests/kvm/include/arm64/processor.h
> index ac97a1c436fc..5de2e932d95a 100644
> --- a/tools/testing/selftests/kvm/include/arm64/processor.h
> +++ b/tools/testing/selftests/kvm/include/arm64/processor.h
> @@ -104,6 +104,15 @@
> #define TCR_HA (UL(1) << 39)
> #define TCR_DS (UL(1) << 59)
>
> +/* VTCR_EL2 specific flags */
> +#define VTCR_EL2_T0SZ_BITS(x) ((UL(64) - (x)) << VTCR_EL2_T0SZ_SHIFT)
> +
> +#define VTCR_EL2_SL0_LV0_4K (UL(2) << VTCR_EL2_SL0_SHIFT)
> +#define VTCR_EL2_SL0_LV1_4K (UL(1) << VTCR_EL2_SL0_SHIFT)
> +#define VTCR_EL2_SL0_LV2_4K (UL(0) << VTCR_EL2_SL0_SHIFT)
> +
> +#define VTCR_EL2_PS_40_BITS (UL(2) << VTCR_EL2_PS_SHIFT)
> +
> /*
> * AttrIndx[2:0] encoding (mapping attributes defined in the MAIR* registers).
> */
> diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
> index 111d02f44cfe..910f8cd30f96 100644
> --- a/tools/testing/selftests/kvm/lib/arm64/nested.c
> +++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
> @@ -1,8 +1,11 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * ARM64 Nested virtualization helpers
> + * ARM64 Nested virtualization helpers, nested page table code adapted from
> + * ../x86/vmx.c.
> */
>
> +#include <linux/sizes.h>
> +
> #include "kvm_util.h"
> #include "nested.h"
> #include "processor.h"
> @@ -18,6 +21,87 @@ static void hvc_handler(struct ex_regs *regs)
> regs->pc = (u64)after_hvc;
> }
>
> +uint64_t get_l1_vtcr(void)
> +{
> + return VTCR_EL2_PS_40_BITS | VTCR_EL2_TG0_4K | VTCR_EL2_ORGN0_WBWA |
> + VTCR_EL2_IRGN0_WBWA | VTCR_EL2_SL0_LV0_4K | VTCR_EL2_T0SZ_BITS(48);
> +}
> +
> +static void __nested_pg_map(struct kvm_vm *vm, uint64_t guest_pgd,
> + uint64_t nested_paddr, uint64_t paddr, uint64_t flags)
> +{
> + uint8_t attr_idx = flags & (PTE_ATTRINDX_MASK >> PTE_ATTRINDX_SHIFT);
> + uint64_t pg_attr;
> + uint64_t *ptep;
> +
> + TEST_ASSERT((nested_paddr % vm->page_size) == 0,
> + "L2 IPA not on page boundary,\n"
> + " nested_paddr: 0x%lx vm->page_size: 0x%x", nested_paddr, vm->page_size);
> + TEST_ASSERT((paddr % vm->page_size) == 0,
> + "Guest physical address not on page boundary,\n"
> + " paddr: 0x%lx vm->page_size: 0x%x", paddr, vm->page_size);
> + TEST_ASSERT((paddr >> vm->page_shift) <= vm->max_gfn,
> + "Physical address beyond maximum supported,\n"
> + " paddr: 0x%lx vm->max_gfn: 0x%lx vm->page_size: 0x%x",
> + paddr, vm->max_gfn, vm->page_size);
> +
> + ptep = addr_gpa2hva(vm, guest_pgd) + ((nested_paddr >> 39) & 0x1ffu) * 8;
> + if (!*ptep)
> + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PGD_TYPE_TABLE | PTE_VALID;
Same but given this is stage 2 translation tables, KVM_PTE_VALID?
Thanks,
Itaru.
> + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 30) & 0x1ffu) * 8;
> + if (!*ptep)
> + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PUD_TYPE_TABLE | PTE_VALID;
> + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 21) & 0x1ffu) * 8;
> + if (!*ptep)
> + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PMD_TYPE_TABLE | PTE_VALID;
> + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 12) & 0x1ffu) * 8;
> +
> + pg_attr = PTE_AF | PTE_ATTRINDX(attr_idx) | PTE_TYPE_PAGE | PTE_VALID;
> + pg_attr |= PTE_SHARED;
> +
> + *ptep = (paddr & GENMASK(47, 12)) | pg_attr;
> +}
> +
> +void nested_map(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> + uint64_t nested_paddr, uint64_t paddr, uint64_t size)
> +{
> + size_t npages = size / SZ_4K;
> +
> + TEST_ASSERT(nested_paddr + size > nested_paddr, "Vaddr overflow");
> + TEST_ASSERT(paddr + size > paddr, "Paddr overflow");
> +
> + while (npages--) {
> + __nested_pg_map(vm, guest_pgd, nested_paddr, paddr, MT_NORMAL);
> + nested_paddr += SZ_4K;
> + paddr += SZ_4K;
> + }
> +}
> +
> +/*
> + * Prepare an identity shadow page table that maps all the
> + * physical pages in VM.
> + */
> +void nested_map_memslot(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> + uint32_t memslot)
> +{
> + sparsebit_idx_t i, last;
> + struct userspace_mem_region *region =
> + memslot2region(vm, memslot);
> +
> + i = (region->region.guest_phys_addr >> vm->page_shift) - 1;
> + last = i + (region->region.memory_size >> vm->page_shift);
> + for (;;) {
> + i = sparsebit_next_clear(region->unused_phy_pages, i);
> + if (i > last)
> + break;
> +
> + nested_map(vm, guest_pgd,
> + (uint64_t)i << vm->page_shift,
> + (uint64_t)i << vm->page_shift,
> + 1 << vm->page_shift);
> + }
> +}
> +
> void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
> {
> size_t l2_stack_size;
> @@ -32,7 +116,16 @@ void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
>
> void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
> {
> - vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_HCR_EL2), HCR_EL2_RW);
> + vm_paddr_t guest_pgd;
> +
> + guest_pgd = vm_phy_pages_alloc(vm, 1,
> + KVM_GUEST_PAGE_TABLE_MIN_PADDR,
> + vm->memslots[MEM_REGION_PT]);
> + nested_map_memslot(vm, guest_pgd, 0);
> +
> + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_HCR_EL2), HCR_EL2_RW | HCR_EL2_VM);
> + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VTTBR_EL2), guest_pgd);
> + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VTCR_EL2), get_l1_vtcr());
> }
>
> void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc)
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH] clk: spear: fix resource leak in clk_register_vco_pll()
From: Haoxiang Li @ 2026-03-25 6:22 UTC (permalink / raw)
To: vireshk, mturquette, sboyd
Cc: linux-arm-kernel, soc, linux-clk, linux-kernel, Haoxiang Li
Add a goto label in clk_register_vco_pll(), unregister vco_clk
if tpll_clk is failed to be registered.
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
---
drivers/clk/spear/clk-vco-pll.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/spear/clk-vco-pll.c b/drivers/clk/spear/clk-vco-pll.c
index 723a6eb67754..ceb82723fa8c 100644
--- a/drivers/clk/spear/clk-vco-pll.c
+++ b/drivers/clk/spear/clk-vco-pll.c
@@ -343,13 +343,15 @@ struct clk *clk_register_vco_pll(const char *vco_name, const char *pll_name,
tpll_clk = clk_register(NULL, &pll->hw);
if (IS_ERR_OR_NULL(tpll_clk))
- goto free_pll;
+ goto unregister_clk;
if (pll_clk)
*pll_clk = tpll_clk;
return vco_clk;
+unregister_clk:
+ clk_unregister(vco_clk);
free_pll:
kfree(pll);
free_vco:
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 1/3] dt-bindings: dma: arm-dma350: document generic and combined IRQ topologies
From: Jun Guo @ 2026-03-25 6:05 UTC (permalink / raw)
To: Robin Murphy, peter.chen, fugang.duan, robh, krzk+dt, conor+dt,
vkoul, ychuang3, schung, Frank.Li
Cc: dmaengine, devicetree, linux-kernel, cix-kernel-upstream,
linux-arm-kernel
In-Reply-To: <c91176d1-851a-4cf5-b7dc-cde431a8326e@arm.com>
On 3/24/2026 8:04 PM, Robin Murphy wrote:
> [Some people who received this message don't often get email from
> robin.murphy@arm.com. Learn why this is important at https://aka.ms/
> LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL
>
> On 2026-03-23 11:48 am, Jun Guo wrote:
>> Update the DMA-350 DT binding to match the current driver behavior.
>>
>> Allow both:
>> - "arm,dma-350" as the generic compatible, and
>> - "cix,sky1-dma-350", "arm,dma-350" for SoC-specific fallback usage.
>>
>> Also document interrupt topology variants supported by hardware
>> integration:
>> - one combined interrupt for all channels, or
>> - one interrupt per channel (up to 8 channels).
>
> To repeat myself for the 3rd time, this is at best unnecessary, and at
> worst arguably wrong. Here's an example of a system which happens to use
> the combined interrupt from another IP block which also offers both
> options:
>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> tree/arch/arm64/boot/dts/freescale/imx8qm.dtsi#n279
>
> Same thing here; each channel is a distinct interrupt source, so it is
> perfectly honest to describe that consistently in DT, regardless of
> whether or not the interrupt signals are still distinct by the time they
> reach the interrupt controller.
>
> Furthermore, in this case the IRQ_COMB_NONSEC interrupt actually has
> additional functionality beyond just being a mux of the individual
> IRQ_CHANNEL interrupts. So although Linux probably won't ever care, if
> it's going to be in the DT binding then it should really be distinct
> from the channel interrupts anyway, since systems could well wire them
> *all* up, and an OS could choose to use the IRQ_CHANNEL outputs directly
> for individual channel completion/error status, while also using the
> IRQ_COMB_NONSEC just for its overall INTR_ALLCH{STOPPED,PAUSED,IDLE}
> status.
>
> If you only want to make your thing work in Linux, all that is needed is
> a 1-line change in the driver to enable the INTR_ANYCHINTR bit (which as
> I've also said before, we can do unconditionally because we're *not*
> using the other INTR_ALLCH stuff), and to write your DT using the
> existing binding. "One interrupt per channel" already carries no
> expectation that they all have to be *different* interrupts.
>
You've indeed said this for the third time, but I did not ignore your
comments earlier. I carefully reviewed your feedback on both the V1
and V2 patches. However, since your initial comments were not as detailed,
I promptly replied to your emails hoping to discuss them further.
Unfortunately, you did not respond to either of my follow-up emails,
so I proceeded with submitting the current version of the patch.
You can refer to the records here:
https://lore.kernel.org/all/20251216123026.3519923-2-jun.guo@cixtech.com/
or
https://lore.kernel.org/all/20251117015943.2858-3-jun.guo@cixtech.com/
Now, with this latest email, I clearly understand the point you are making.
I will revise and resubmit the patch accordingly, which should result in
a much more concise version. Thank you for your reply.
Best regards,
Jun
^ permalink raw reply
* Re: [PATCH v10 05/12] arm64: rqspinlock: Remove private copy of smp_cond_load_acquire_timewait()
From: Ankur Arora @ 2026-03-25 5:58 UTC (permalink / raw)
To: Kumar Kartikeya Dwivedi
Cc: Ankur Arora, linux-kernel, linux-arch, linux-arm-kernel, linux-pm,
bpf, arnd, catalin.marinas, will, peterz, akpm, mark.rutland,
harisokn, cl, ast, rafael, daniel.lezcano, zhenglifeng1, xueshuai,
rdunlap, david.laight.linux, joao.m.martins, boris.ostrovsky,
konrad.wilk
In-Reply-To: <CAP01T75VaNGk+adULuX3q_8uxc0z78J5B_5ECLy2VR=i7pBi0g@mail.gmail.com>
Kumar Kartikeya Dwivedi <memxor@gmail.com> writes:
> On Mon, 16 Mar 2026 at 02:37, Ankur Arora <ankur.a.arora@oracle.com> wrote:
>>
>> In preparation for defining smp_cond_load_acquire_timeout(), remove
>> the private copy. Lacking this, the rqspinlock code falls back to using
>> smp_cond_load_acquire().
>
> nit: This temporarily breaks bisection (or rather, leaves things
> broken until later commits), but I don't care too much.
Yeah. Would have avoided it if I easily could. But given that there
was a private interface involved this seemed the cleanest way.
>> Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
>> Cc: Alexei Starovoitov <ast@kernel.org>
>> Cc: bpf@vger.kernel.org
>> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>> Reviewed-by: Haris Okanovic <harisokn@amazon.com>
>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>> ---
>
> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Thanks.
--
ankur
^ permalink raw reply
* Re: [PATCH v10 09/12] bpf/rqspinlock: switch check_timeout() to a clock interface
From: Ankur Arora @ 2026-03-25 5:57 UTC (permalink / raw)
To: Kumar Kartikeya Dwivedi
Cc: Ankur Arora, linux-kernel, linux-arch, linux-arm-kernel, linux-pm,
bpf, arnd, catalin.marinas, will, peterz, akpm, mark.rutland,
harisokn, cl, ast, rafael, daniel.lezcano, zhenglifeng1, xueshuai,
rdunlap, david.laight.linux, joao.m.martins, boris.ostrovsky,
konrad.wilk
In-Reply-To: <CAP01T76iJAtfovOAhm+9-QwtbVJRbiQgUPWLBZZXYFozLFK=uw@mail.gmail.com>
Kumar Kartikeya Dwivedi <memxor@gmail.com> writes:
> On Mon, 16 Mar 2026 at 02:37, Ankur Arora <ankur.a.arora@oracle.com> wrote:
>>
>> check_timeout() gets the current time value and depending on how
>> much time has passed, checks for deadlock or times out, returning 0
>> or -errno on deadlock or timeout.
>>
>> Switch this out to a clock style interface, where it functions as a
>> clock in the "lock-domain", returning the current time until a
>> deadlock or timeout occurs. Once a deadlock or timeout has occurred,
>> it stops functioning as a clock and returns error.
>>
>> Also adjust the RES_CHECK_TIMEOUT macro to discard the clock value
>> when updating the explicit return status.
>>
>> Cc: bpf@vger.kernel.org
>> Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
>> Cc: Alexei Starovoitov <ast@kernel.org>
>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>> --
>
> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Thanks Kumar.
--
ankur
^ permalink raw reply
* RE: [PATCH v2] media: nxp: imx8-isi: Add virtual channel support
From: G.N. Zhou (OSS) @ 2026-03-25 5:51 UTC (permalink / raw)
To: Laurent Pinchart, G.N. Zhou (OSS)
Cc: Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
linux-media@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, G.N. Zhou
In-Reply-To: <20260319224641.GA962817@killaraus.ideasonboard.com>
Hi Laurent,
Thanks for your review.
> -----Original Message-----
> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Sent: Friday, March 20, 2026 6:47 AM
> To: G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix
> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; linux-media@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; G.N. Zhou
> <guoniu.zhou@nxp.com>
> Subject: Re: [PATCH v2] media: nxp: imx8-isi: Add virtual channel support
>
> Hi Guoniu,
>
> Thank you for the patch.
>
> On Tue, Mar 10, 2026 at 02:53:10PM +0800, Guoniu Zhou wrote:
> > From: Guoniu Zhou <guoniu.zhou@nxp.com>
> >
> > Add virtual channel support for ISI driver.
>
> You can drop this line, it duplicates the subject line.
>
> > The ISI supports different numbers of virtual channels depending on
> > the platform. i.MX95 supports 8 virtual channels, and i.MX8QXP/QM
> > support 4 virtual channels. They are used in multiple camera use
> > cases, such as surround view. Other platforms (such as
> > i.MX8MN/8MP/8ULP/93/91) don't support virtual channels, and the VC_ID
> bits are marked as read-only.
> >
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> > ---
> > Changes in v2:
> > - Add Rb tag from Frank Li
> > - Fix typo in comment(s/support/supports/)
> > - Update commit log to include more details about ISI virtual channel support
> > on different platform
> > - Include bitfield.h file to fix following build error
> > drivers/media/platform/nxp/imx8-isi/imx8-isi-regs.h:23:65: error:
> > implicit declaration of function ‘FIELD_PREP’
> > [-Wimplicit-function-declaration]
> > - Link to v1:
> > https://lore.kernel.org/r/20260309-isi_vc-v1-1-fd0b8035d1cd@nxp.com
> >
> > Changes in v1:
> > - Depends on
> > https://lore.kernel.org/linux-media/20251105-isi_imx95-v3-2-3987533cca
> > 1c@nxp.com/
> > ---
> > .../media/platform/nxp/imx8-isi/imx8-isi-core.h | 3 ++
> > drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c | 4 +-
> > .../media/platform/nxp/imx8-isi/imx8-isi-pipe.c | 43
> ++++++++++++++++++++++
> > .../media/platform/nxp/imx8-isi/imx8-isi-regs.h | 6 +--
> > 4 files changed, 52 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
> > b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
> > index
> >
> 3cbd35305af0f8026c4f76b5eb5d0864f8e36dc3..11a5e395792f11752c44d738
> 18c8
> > 25f2f175aa1d 100644
> > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
> > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
> > @@ -256,6 +256,9 @@ struct mxc_isi_pipe {
> > u8 acquired_res;
> > u8 chained_res;
> > bool chained;
> > +
> > + /* Virtual channel ID for the ISI channel */
> > + u8 vc;
> > };
> >
> > struct mxc_isi_m2m {
> > diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c
> > b/drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c
> > index
> >
> 0187d4ab97e8e28fca9013f6864a094e08f2c570..2babb8573227de9e1aa36d9
> a39be
> > 41b286cf0c57 100644
> > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c
> > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c
> > @@ -338,7 +338,9 @@ static void mxc_isi_channel_set_control(struct
> mxc_isi_pipe *pipe,
> > } else {
> > val |= CHNL_CTRL_SRC_TYPE(CHNL_CTRL_SRC_TYPE_DEVICE);
> > val |= CHNL_CTRL_SRC_INPUT(input);
> > - val |= CHNL_CTRL_MIPI_VC_ID(0); /* FIXME: For CSI-2 only */
> > + val |= CHNL_CTRL_MIPI_VC_ID(pipe->vc);
>
> You're not addressing the FIXME comment, so it should be kept (or ideally
> addressed :-)).
Ok, will add it back.
>
> > + /* Platform like i.MX95, ISI supports 8 virtual channels */
> > + val |= CHNL_CTRL_VC_ID_1(pipe->vc >> 2);
>
> This should be done for i.MX95 only. You also need to clear the bit above in the
> function just after reading CHNL_CTRL (for i.MX95 only as well), otherwise
> switching between different virtual channels won't work.
Yes, you're right. Will fix it in next version.
>
> > }
> >
> > mxc_isi_write(pipe, CHNL_CTRL, val); diff --git
> > a/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
> > b/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
> > index
> >
> a41c51dd9ce0f2eeb779e9aa2461593b0d635f41..cc4348ea6006ee19243aae3
> abceb
> > 235d00beea4d 100644
> > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
> > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
> > @@ -232,6 +232,45 @@ static inline struct mxc_isi_pipe *to_isi_pipe(struct
> v4l2_subdev *sd)
> > return container_of(sd, struct mxc_isi_pipe, sd); }
> >
> > +static int mxc_isi_get_vc(struct mxc_isi_pipe *pipe) {
> > + struct mxc_isi_crossbar *xbar = &pipe->isi->crossbar;
> > + struct device *dev = pipe->isi->dev;
> > + struct v4l2_mbus_frame_desc source_fd;
> > + struct v4l2_mbus_frame_desc_entry *entry = NULL;
> > + unsigned int i;
> > + int ret;
> > +
> > + ret = v4l2_subdev_call(&xbar->sd, pad, get_frame_desc,
> > + xbar->num_sinks + pipe->id, &source_fd);
>
> I don't see the xbar implementing get_frame_desc(). Am I missing a
> dependency ?
Good catch, thank you.
The xbar get_frame_desc() implementation was developed separately and I
mistakenly didn't include it in this series. You're not missing anything -
it's my error in patch organization.
I will include it in next version to make this series self-contained and complete.
>
> > + if (ret < 0) {
> > + dev_err(dev, "Failed to get source frame desc from pad %u\n",
> > + xbar->num_sinks + pipe->id);
> > + return ret;
> > + }
> > +
> > + for (i = 0; i < source_fd.num_entries; i++) {
> > + if (source_fd.entry[i].stream == 0) {
> > + entry = &source_fd.entry[i];
> > + break;
> > + }
> > + }
> > +
> > + if (!entry) {
> > + dev_err(dev, "Failed to find stream from source frame desc\n");
> > + return -EPIPE;
> > + }
> > +
> > + if (entry->bus.csi2.vc >= pipe->isi->pdata->num_channels) {
> > + dev_err(dev, "Virtual channel(%d) out of range\n",
> > + entry->bus.csi2.vc);
> > + return -EINVAL;
> > + }
> > +
> > + pipe->vc = entry->bus.csi2.vc;
> > + return 0;
> > +}
> > +
> > int mxc_isi_pipe_enable(struct mxc_isi_pipe *pipe) {
> > struct mxc_isi_crossbar *xbar = &pipe->isi->crossbar; @@ -280,6
> > +319,10 @@ int mxc_isi_pipe_enable(struct mxc_isi_pipe *pipe)
> >
> > v4l2_subdev_unlock_state(state);
> >
> > + ret = mxc_isi_get_vc(pipe);
> > + if (ret)
> > + return ret;
> > +
> > /* Configure the ISI channel. */
> > mxc_isi_channel_config(pipe, input, &in_size, &scale, &crop,
> > sink_info->encoding, src_info->encoding); diff --git
> > a/drivers/media/platform/nxp/imx8-isi/imx8-isi-regs.h
> > b/drivers/media/platform/nxp/imx8-isi/imx8-isi-regs.h
> > index
> >
> 1b65eccdf0da4bbc3a77c91e06fccc35d6c7e022..a4036da72f0057265e991087
> f21b
> > c079bd6c6573 100644
> > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-regs.h
> > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-regs.h
> > @@ -6,6 +6,7 @@
> > #ifndef __IMX8_ISI_REGS_H__
> > #define __IMX8_ISI_REGS_H__
> >
> > +#include <linux/bitfield.h>
> > #include <linux/bits.h>
> >
> > /* ISI Registers Define */
> > @@ -19,9 +20,8 @@
> > #define CHNL_CTRL_CHAIN_BUF_NO_CHAIN 0
> > #define CHNL_CTRL_CHAIN_BUF_2_CHAIN 1
> > #define CHNL_CTRL_SW_RST BIT(24)
> > -#define CHNL_CTRL_BLANK_PXL(n) ((n) <<
> 16)
>
> I'm tempted to keep this, in case we'll need to set it later. We can add a
> comment to indicate the field is only valid on i.MX8QM and i.MX8QXP:
>
> #define CHNL_CTRL_BLANK_PXL(n) ((n) <<
> 16) /* i.MX8{QM,QXP} */
>
> or
>
> #define CHNL_CTRL_BLANK_PXL(n)
> FIELD_PREP(GENMASK(23, 16), (n)) /* i.MX8{QM,QXP} */
>
> > -#define CHNL_CTRL_BLANK_PXL_MASK
> GENMASK(23, 16)
> > -#define CHNL_CTRL_MIPI_VC_ID(n) ((n) <<
> 6)
> > +#define CHNL_CTRL_VC_ID_1(n)
> FIELD_PREP(BIT(16), (n))
>
> Please also add a comment to indicate the field is valid on i.MX95 only.
>
> #define CHNL_CTRL_VC_ID_1(n)
> FIELD_PREP(BIT(16), (n)) /* i.MX95 */
>
Sounds good. I will add a comment in next version to clarify this.
> > +#define CHNL_CTRL_MIPI_VC_ID(n)
> FIELD_PREP(GENMASK(7, 6), (n))
> > #define CHNL_CTRL_MIPI_VC_ID_MASK
> GENMASK(7, 6)
> > #define CHNL_CTRL_SRC_TYPE(n) ((n) <<
> 4)
> > #define CHNL_CTRL_SRC_TYPE_MASK BIT(4)
> >
> > ---
> > base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> > change-id: 20260309-isi_vc-285fd815140e
> > prerequisite-patch-id: 6f139a1d54fa3e0632db9b8a736ae27037c5f45a
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* [PATCH 6/6] arm64: dts: rockchip: Add Bluetooth support for Khadas Edge 2L
From: Gray Huang @ 2026-03-25 5:46 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260325054614.1497147-1-gray.huang@wesion.com>
Enable Bluetooth support for the Ampak AP6275P module on the
Khadas Edge 2L. This involves enabling the UART5 interface for
HCI communication and defining the required regulators and
power-sequence pins.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 8ecd00f6645d..345dc4c981c1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -560,6 +560,20 @@ usb_host_pwren: usb-host-pwren {
};
};
+ bluetooth {
+ bt_reg_on: bt-reg-on {
+ rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ bt_wake_host: bt-wake-host {
+ rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ host_wake_bt: host-wake-bt {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
wifi {
wifi_reg_on: wifi-reg-on {
rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
@@ -603,6 +617,27 @@ &uart0 {
status = "okay";
};
+&uart5 {
+ pinctrl-0 = <&uart5m1_xfer &uart5m1_ctsn &uart5m1_rtsn>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = <&hym8563>;
+ clock-names = "lpo";
+ device-wakeup-gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB1 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-0 = <&bt_reg_on &bt_wake_host &host_wake_bt>;
+ pinctrl-names = "default";
+ shutdown-gpios = <&gpio4 RK_PB2 GPIO_ACTIVE_HIGH>;
+ vbat-supply = <&vcc_3v3_s3>;
+ vddio-supply = <&vcc_1v8_s3>;
+ };
+};
+
&vop {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH 3/6] arm64: dts: rockchip: Enable GPU for Khadas Edge 2L
From: Gray Huang @ 2026-03-25 5:46 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260325054614.1497147-1-gray.huang@wesion.com>
Enable the Mali GPU node on the Khadas Edge 2L board. Assign the
corresponding regulator to the mali-supply property to ensure
proper power management and dynamic voltage scaling (DVFS).
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 09cb0f0d6dcf..15676ba3b599 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -70,6 +70,11 @@ &cpu_b0 {
cpu-supply = <&vdd_cpu_big_s0>;
};
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ status = "okay";
+};
+
&i2c1 {
status = "okay";
--
2.34.1
^ permalink raw reply related
* [PATCH 5/6] arm64: dts: rockchip: Enable USB for Khadas Edge 2L
From: Gray Huang @ 2026-03-25 5:46 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260325054614.1497147-1-gray.huang@wesion.com>
The Khadas Edge 2L board provides one USB 3.0 Host port and one
USB 2.0 port (connected via an internal hub). Enable the
corresponding DWC3 controllers and PHYs.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 47 +++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 003342fd69a7..8ecd00f6645d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -30,6 +30,29 @@ hdmi_con_in: endpoint {
};
};
+ vcc5v0_device: regulator-vcc5v0-device {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_device";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vcc5v0_host: regulator-vcc5v0-host {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_host";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ gpio = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&vcc5v0_device>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb_host_pwren>;
+ };
+
vcc_sys: regulator-vcc5v0-sys {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
@@ -531,6 +554,12 @@ pcie0_rst: pcie0-rst {
};
};
+ usb {
+ usb_host_pwren: usb-host-pwren {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
wifi {
wifi_reg_on: wifi-reg-on {
rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
@@ -542,6 +571,24 @@ wifi_wake_host: wifi-wake-host {
};
};
+&usb_drd1_dwc3 {
+ dr_mode = "host";
+ status = "okay";
+};
+
+&u2phy1 {
+ status = "okay";
+};
+
+&u2phy1_otg {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+};
+
+&combphy1_psu {
+ status = "okay";
+};
+
&sdhci {
bus-width = <8>;
no-sdio;
--
2.34.1
^ permalink raw reply related
* [PATCH 4/6] arm64: dts: rockchip: Add HDMI and VOP support for Khadas Edge 2L
From: Gray Huang @ 2026-03-25 5:46 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260325054614.1497147-1-gray.huang@wesion.com>
Enable the Video Output Processor (VOP) and the HDMI TX controller
to support HDMI display output on the Khadas Edge 2L. Also, enable
the associated HDMI PHY.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 15676ba3b599..003342fd69a7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -4,6 +4,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
#include "rk3576.dtsi"
/ {
@@ -18,6 +19,17 @@ chosen {
stdout-path = "serial0:1500000n8";
};
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
vcc_sys: regulator-vcc5v0-sys {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
@@ -75,6 +87,30 @@ &gpu {
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_in {
+ hdmi_in_vp0: endpoint {
+ remote-endpoint = <&vp0_out_hdmi>;
+ };
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&hdptxphy {
+ status = "okay";
+};
+
&i2c1 {
status = "okay";
@@ -519,3 +555,18 @@ &sdhci {
&uart0 {
status = "okay";
};
+
+&vop {
+ status = "okay";
+};
+
+&vop_mmu {
+ status = "okay";
+};
+
+&vp0 {
+ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+ reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+ remote-endpoint = <&hdmi_in_vp0>;
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 2/6] arm64: dts: rockchip: Add AP6275P wireless support for Khadas Edge 2L
From: Gray Huang @ 2026-03-25 5:46 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260325054614.1497147-1-gray.huang@wesion.com>
The Khadas Edge 2L board uses the Ampak AP6275P (BCM43752) PCIe
Wi-Fi 6 module.
Enable the pcie0 controller and add the Wi-Fi module as its child
node. Additionally, enable the HYM8563 RTC to provide the 32.768kHz
LPO clock required by the Wi-Fi module, along with the necessary
CombPHY and fixed regulator.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 71 ++++++++++++++++++-
1 file changed, 70 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 5781deae00d9..09cb0f0d6dcf 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -47,7 +47,19 @@ vcc_2v0_pldo_s3: regulator-vcc-2v0-pldo-s3 {
vin-supply = <&vcc_sys>;
};
-
+ vcc_wifi_reg_on: regulator-wifi-reg-on {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&wifi_reg_on>;
+ pinctrl-names = "default";
+ regulator-name = "wifi_reg_on";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_1v8_s3>;
+ };
};
&cpu_l0 {
@@ -431,6 +443,63 @@ regulator-state-mem {
};
};
+&combphy0_ps {
+ status = "okay";
+};
+
+&pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_rst>;
+ reset-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
+ status = "okay";
+
+ pcie@0,0 {
+ reg = <0x0 0 0 0 0>;
+ bus-range = <0x0 0xf>;
+ device_type = "pci";
+ ranges;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ wifi: wifi@0,0 {
+ compatible = "pci14e4,449d";
+ reg = <0x10000 0 0 0 0>;
+ clocks = <&hym8563>;
+ clock-names = "lpo";
+ };
+ };
+};
+
+&i2c2 {
+ status = "okay";
+
+ hym8563: hym8563@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-output-names = "hym8563";
+ wakeup-source;
+ };
+};
+
+&pinctrl {
+ pcie0 {
+ pcie0_rst: pcie0-rst {
+ rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_reg_on: wifi-reg-on {
+ rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ wifi_wake_host: wifi-wake-host {
+ rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+};
&sdhci {
bus-width = <8>;
--
2.34.1
^ permalink raw reply related
* [PATCH 1/6] arm64: dts: rockchip: Add PMIC support for Khadas Edge 2L
From: Gray Huang @ 2026-03-25 5:46 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260325054614.1497147-1-gray.huang@wesion.com>
Add RK806 PMIC support for the Khadas Edge 2L board. Assign the
corresponding PMIC regulators (vdd_cpu_lit_s0 and vdd_cpu_big_s0)
to the little and big CPU clusters to enable proper power
management and CPU frequency scaling.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
---
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 413 ++++++++++++++++++
1 file changed, 413 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
index 68630379af63..5781deae00d9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
@@ -17,8 +17,421 @@ aliases {
chosen {
stdout-path = "serial0:1500000n8";
};
+
+ vcc_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vcc_2v0_pldo_s3: regulator-vcc-2v0-pldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_2v0_pldo_s3";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ vin-supply = <&vcc_sys>;
+ };
+
+
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
};
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&i2c1 {
+ status = "okay";
+
+ rk806: pmic@23 {
+ compatible = "rockchip,rk806";
+ reg = <0x23>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+ <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+ system-power-controller;
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc5-supply = <&vcc_sys>;
+ vcc6-supply = <&vcc_sys>;
+ vcc7-supply = <&vcc_sys>;
+ vcc8-supply = <&vcc_sys>;
+ vcc9-supply = <&vcc_sys>;
+ vcc10-supply = <&vcc_sys>;
+ vcc11-supply = <&vcc_2v0_pldo_s3>;
+ vcc12-supply = <&vcc_sys>;
+ vcc13-supply = <&vcc_1v1_nldo_s3>;
+ vcc14-supply = <&vcc_1v1_nldo_s3>;
+ vcca-supply = <&vcc_sys>;
+
+ rk806_dvs1_null: dvs1-null-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs2_null: dvs2-null-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs3_null: dvs3-null-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs1_slp: dvs1-slp-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun1";
+ };
+
+ rk806_dvs1_pwrdn: dvs1-pwrdn-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun2";
+ };
+
+ rk806_dvs1_rst: dvs1-rst-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun3";
+ };
+
+ rk806_dvs2_slp: dvs2-slp-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun1";
+ };
+
+ rk806_dvs2_pwrdn: dvs2-pwrdn-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun2";
+ };
+
+ rk806_dvs2_rst: dvs2-rst-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun3";
+ };
+
+ rk806_dvs2_dvs: dvs2-dvs-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun4";
+ };
+
+ rk806_dvs2_gpio: dvs2-gpio-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun5";
+ };
+
+ rk806_dvs3_slp: dvs3-slp-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun1";
+ };
+
+ rk806_dvs3_pwrdn: dvs3-pwrdn-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun2";
+ };
+
+ rk806_dvs3_rst: dvs3-rst-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun3";
+ };
+
+ rk806_dvs3_dvs: dvs3-dvs-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun4";
+ };
+
+ rk806_dvs3_gpio: dvs3-gpio-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun5";
+ };
+
+ regulators {
+ vdd_cpu_big_s0: dcdc-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_big_s0";
+ regulator-enable-ramp-delay = <400>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_npu_s0: dcdc-reg2 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_npu_s0";
+ regulator-enable-ramp-delay = <400>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_lit_s0: dcdc-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_lit_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vcc_3v3_s3: dcdc-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vdd_gpu_s0: dcdc-reg5 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <900000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_s0";
+ regulator-enable-ramp-delay = <400>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ vddq_ddr_s0: dcdc-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vddq_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_logic_s0: dcdc-reg7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <800000>;
+ regulator-name = "vdd_logic_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s3: dcdc-reg8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd2_ddr_s3: dcdc-reg9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd2_ddr_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vdd_ddr_s0: dcdc-reg10 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vdd_ddr_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8_s0: pldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca_1v8_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pldo2_s0: pldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca1v8_pldo2_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_1v2_s0: pldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vdda_1v2_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_3v3_s0: pldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcca_3v3_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd_s0: pldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pldo6_s3: pldo-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca1v8_pldo6_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd_0v75_s3: nldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s3";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdda_ddr_pll_s0: nldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdda_ddr_pll_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v75_hdmi_s0: nldo-reg3 {
+ regulator-boot-on;
+ regulator-min-microvolt = <837500>;
+ regulator-max-microvolt = <837500>;
+ regulator-name = "vdda0v75_hdmi_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v85_s0: nldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdda_0v85_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v75_s0: nldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdda_0v75_s0";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+
&sdhci {
bus-width = <8>;
no-sdio;
--
2.34.1
^ permalink raw reply related
* [PATCH 0/6] arm64: dts: rockchip: Add peripheral support for Khadas Edge 2L
From: Gray Huang @ 2026-03-25 5:46 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
This patch series adds support for several key peripherals to the
Khadas Edge 2L board, which is based on the Rockchip RK3576 SoC.
These patches build upon the basic board support that was previously
applied to the rockchip tree. This series enables essential
functionalities including power management, wireless connectivity,
graphics, display output, and USB support.
Summary of changes:
- Enable PMIC (RK806) and configure CPU regulators.
- Enable PCIe-based Wi-Fi (AP6275P) and the required RTC clock.
- Enable Mali GPU with proper power supply.
- Enable VOP2 and HDMI display output.
- Enable USB 3.0 Host and USB 2.0 (via internal hub).
- Enable Bluetooth (UART5) for the Ampak module.
Gray Huang (6):
arm64: dts: rockchip: Add PMIC support for Khadas Edge 2L
arm64: dts: rockchip: Add AP6275P wireless support for Khadas Edge 2L
arm64: dts: rockchip: Enable GPU for Khadas Edge 2L
arm64: dts: rockchip: Add HDMI and VOP support for Khadas Edge 2L
arm64: dts: rockchip: Enable USB for Khadas Edge 2L
arm64: dts: rockchip: Add Bluetooth support for Khadas Edge 2L
.../dts/rockchip/rk3576-khadas-edge-2l.dts | 620 ++++++++++++++++++
1 file changed, 620 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH v7 3/4] coresight: cti: add Qualcomm extended CTI identification and quirks
From: Yingchao Deng @ 2026-03-25 5:43 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
Jinlong Mao, Tingwei Zhang, Jie Gan, quic_yingdeng, Yingchao Deng
In-Reply-To: <20260325-extended_cti-v7-0-bb406005089f@oss.qualcomm.com>
Qualcomm implements an extended variant of the ARM CoreSight CTI with a
different register layout and vendor-specific behavior. While the
programming model remains largely compatible, the register offsets differ
from the standard ARM CTI and require explicit handling.
Detect Qualcomm CTIs via the DEVARCH register and record this in the CTI
driver data. Introduce a small mapping layer to translate standard CTI
register offsets to Qualcomm-specific offsets, allowing the rest of the
driver to use a common register access path.
Additionally, handle a Qualcomm-specific quirk where the CLAIMSET
register is incorrectly initialized to a non-zero value, which can cause
tools or drivers to assume the component is already claimed. Clear the
register during probe to reflect the actual unclaimed state.
No functional change is intended for standard ARM CTI devices.
Co-developed-by: Jinlong Mao <jinlong.mao@oss.qualcomm.com>
Signed-off-by: Jinlong Mao <jinlong.mao@oss.qualcomm.com>
Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-cti-core.c | 26 +++++++++-
drivers/hwtracing/coresight/coresight-cti.h | 1 +
drivers/hwtracing/coresight/qcom-cti.h | 65 ++++++++++++++++++++++++
3 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c
index 023993475a2e..afa83d411a4a 100644
--- a/drivers/hwtracing/coresight/coresight-cti-core.c
+++ b/drivers/hwtracing/coresight/coresight-cti-core.c
@@ -21,6 +21,7 @@
#include "coresight-priv.h"
#include "coresight-cti.h"
+#include "qcom-cti.h"
/*
* CTI devices can be associated with a PE, or be connected to CoreSight
@@ -47,6 +48,10 @@ static void __iomem *cti_reg_addr(struct cti_drvdata *drvdata, u32 reg)
u32 offset = CTI_REG_CLR_NR(reg);
u32 nr = CTI_REG_GET_NR(reg);
+ /* convert to qcom specific offset */
+ if (unlikely(drvdata->is_qcom_cti))
+ offset = cti_qcom_reg_off(offset);
+
return drvdata->base + offset + sizeof(u32) * nr;
}
@@ -170,6 +175,9 @@ void cti_write_intack(struct device *dev, u32 ackval)
/* DEVID[19:16] - number of CTM channels */
#define CTI_DEVID_CTMCHANNELS(devid_val) ((int) BMVAL(devid_val, 16, 19))
+/* DEVARCH[31:21] - ARCHITECT */
+#define CTI_DEVARCH_ARCHITECT(devarch_val) ((int)BMVAL(devarch_val, 21, 31))
+
static int cti_set_default_config(struct device *dev,
struct cti_drvdata *drvdata)
{
@@ -698,6 +706,7 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
struct coresight_desc cti_desc;
struct coresight_platform_data *pdata = NULL;
struct resource *res = &adev->res;
+ u32 devarch;
/* driver data*/
drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
@@ -722,6 +731,20 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
raw_spin_lock_init(&drvdata->spinlock);
+ devarch = readl_relaxed(drvdata->base + CORESIGHT_DEVARCH);
+ if (CTI_DEVARCH_ARCHITECT(devarch) == ARCHITECT_QCOM) {
+ drvdata->is_qcom_cti = true;
+ /*
+ * QCOM CTI does not implement Claimtag functionality as
+ * per CoreSight specification, but its CLAIMSET register
+ * is incorrectly initialized to 0xF. This can mislead
+ * tools or drivers into thinking the component is claimed.
+ *
+ * Reset CLAIMSET to 0 to reflect that no claims are active.
+ */
+ writel_relaxed(0, drvdata->base + CORESIGHT_CLAIMSET);
+ }
+
/* initialise CTI driver config values */
ret = cti_set_default_config(dev, drvdata);
if (ret)
@@ -778,7 +801,8 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
/* all done - dec pm refcount */
pm_runtime_put(&adev->dev);
- dev_info(&drvdata->csdev->dev, "CTI initialized\n");
+ dev_info(&drvdata->csdev->dev,
+ "%sCTI initialized\n", drvdata->is_qcom_cti ? "QCOM " : "");
return 0;
}
diff --git a/drivers/hwtracing/coresight/coresight-cti.h b/drivers/hwtracing/coresight/coresight-cti.h
index 21bcdedcb95f..9c0896b17c24 100644
--- a/drivers/hwtracing/coresight/coresight-cti.h
+++ b/drivers/hwtracing/coresight/coresight-cti.h
@@ -187,6 +187,7 @@ struct cti_drvdata {
raw_spinlock_t spinlock;
struct cti_config config;
struct list_head node;
+ bool is_qcom_cti;
};
/*
diff --git a/drivers/hwtracing/coresight/qcom-cti.h b/drivers/hwtracing/coresight/qcom-cti.h
new file mode 100644
index 000000000000..21a33b759b36
--- /dev/null
+++ b/drivers/hwtracing/coresight/qcom-cti.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef _CORESIGHT_QCOM_CTI_H
+#define _CORESIGHT_QCOM_CTI_H
+
+#include "coresight-cti.h"
+
+#define ARCHITECT_QCOM 0x477
+
+/* CTI programming registers */
+#define QCOM_CTIINTACK 0x020
+#define QCOM_CTIAPPSET 0x004
+#define QCOM_CTIAPPCLEAR 0x008
+#define QCOM_CTIAPPPULSE 0x00C
+#define QCOM_CTIINEN 0x400
+#define QCOM_CTIOUTEN 0x800
+#define QCOM_CTITRIGINSTATUS 0x040
+#define QCOM_CTITRIGOUTSTATUS 0x060
+#define QCOM_CTICHINSTATUS 0x080
+#define QCOM_CTICHOUTSTATUS 0x084
+#define QCOM_CTIGATE 0x088
+#define QCOM_ASICCTL 0x08c
+/* Integration test registers */
+#define QCOM_ITCHINACK 0xE70
+#define QCOM_ITTRIGINACK 0xE80
+#define QCOM_ITCHOUT 0xE74
+#define QCOM_ITTRIGOUT 0xEA0
+#define QCOM_ITCHOUTACK 0xE78
+#define QCOM_ITTRIGOUTACK 0xEC0
+#define QCOM_ITCHIN 0xE7C
+#define QCOM_ITTRIGIN 0xEE0
+
+static noinline u32 cti_qcom_reg_off(u32 offset)
+{
+ switch (offset) {
+ case CTIINTACK: return QCOM_CTIINTACK;
+ case CTIAPPSET: return QCOM_CTIAPPSET;
+ case CTIAPPCLEAR: return QCOM_CTIAPPCLEAR;
+ case CTIAPPPULSE: return QCOM_CTIAPPPULSE;
+ case CTIINEN: return QCOM_CTIINEN;
+ case CTIOUTEN: return QCOM_CTIOUTEN;
+ case CTITRIGINSTATUS: return QCOM_CTITRIGINSTATUS;
+ case CTITRIGOUTSTATUS: return QCOM_CTITRIGOUTSTATUS;
+ case CTICHINSTATUS: return QCOM_CTICHINSTATUS;
+ case CTICHOUTSTATUS: return QCOM_CTICHOUTSTATUS;
+ case CTIGATE: return QCOM_CTIGATE;
+ case ASICCTL: return QCOM_ASICCTL;
+ case ITCHINACK: return QCOM_ITCHINACK;
+ case ITTRIGINACK: return QCOM_ITTRIGINACK;
+ case ITCHOUT: return QCOM_ITCHOUT;
+ case ITTRIGOUT: return QCOM_ITTRIGOUT;
+ case ITCHOUTACK: return QCOM_ITCHOUTACK;
+ case ITTRIGOUTACK: return QCOM_ITTRIGOUTACK;
+ case ITCHIN: return QCOM_ITCHIN;
+ case ITTRIGIN: return QCOM_ITTRIGIN;
+
+ default:
+ return offset;
+ }
+}
+
+#endif /* _CORESIGHT_QCOM_CTI_H */
--
2.43.0
^ permalink raw reply related
* [PATCH v7 4/4] coresight: cti: expose banked sysfs registers for Qualcomm extended CTI
From: Yingchao Deng @ 2026-03-25 5:43 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
Jinlong Mao, Tingwei Zhang, Jie Gan, quic_yingdeng, Yingchao Deng
In-Reply-To: <20260325-extended_cti-v7-0-bb406005089f@oss.qualcomm.com>
Qualcomm extended CTI implements banked trigger status and integration
registers, where each bank covers 32 triggers. Multiple instances of
these registers are required to expose the full trigger space.
Add static sysfs entries for the banked CTI registers and control their
visibility based on the underlying hardware configuration. Numbered
sysfs nodes are hidden on standard ARM CTIs, preserving the existing ABI.
On Qualcomm CTIs, only banked registers backed by hardware are exposed,
with the number of visible banks derived from nr_trig_max.
This ensures that userspace only sees registers that are actually
implemented, while maintaining compatibility with existing CTI tooling.
Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-cti-sysfs.c | 58 +++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-cti-sysfs.c b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
index 075f633ea9e1..123ac862d8de 100644
--- a/drivers/hwtracing/coresight/coresight-cti-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
@@ -511,18 +511,36 @@ static struct attribute *coresight_cti_regs_attrs[] = {
&dev_attr_appclear.attr,
&dev_attr_apppulse.attr,
coresight_cti_reg(triginstatus, CTITRIGINSTATUS),
+ coresight_cti_reg(triginstatus1, CTI_REG_SET_NR_CONST(CTITRIGINSTATUS, 1)),
+ coresight_cti_reg(triginstatus2, CTI_REG_SET_NR_CONST(CTITRIGINSTATUS, 2)),
+ coresight_cti_reg(triginstatus3, CTI_REG_SET_NR_CONST(CTITRIGINSTATUS, 3)),
coresight_cti_reg(trigoutstatus, CTITRIGOUTSTATUS),
+ coresight_cti_reg(trigoutstatus1, CTI_REG_SET_NR_CONST(CTITRIGOUTSTATUS, 1)),
+ coresight_cti_reg(trigoutstatus2, CTI_REG_SET_NR_CONST(CTITRIGOUTSTATUS, 2)),
+ coresight_cti_reg(trigoutstatus3, CTI_REG_SET_NR_CONST(CTITRIGOUTSTATUS, 3)),
coresight_cti_reg(chinstatus, CTICHINSTATUS),
coresight_cti_reg(choutstatus, CTICHOUTSTATUS),
#ifdef CONFIG_CORESIGHT_CTI_INTEGRATION_REGS
coresight_cti_reg_rw(itctrl, CORESIGHT_ITCTRL),
coresight_cti_reg(ittrigin, ITTRIGIN),
+ coresight_cti_reg(ittrigin1, CTI_REG_SET_NR_CONST(ITTRIGIN, 1)),
+ coresight_cti_reg(ittrigin2, CTI_REG_SET_NR_CONST(ITTRIGIN, 2)),
+ coresight_cti_reg(ittrigin3, CTI_REG_SET_NR_CONST(ITTRIGIN, 3)),
coresight_cti_reg(itchin, ITCHIN),
coresight_cti_reg_rw(ittrigout, ITTRIGOUT),
+ coresight_cti_reg_rw(ittrigout1, CTI_REG_SET_NR_CONST(ITTRIGOUT, 1)),
+ coresight_cti_reg_rw(ittrigout2, CTI_REG_SET_NR_CONST(ITTRIGOUT, 2)),
+ coresight_cti_reg_rw(ittrigout3, CTI_REG_SET_NR_CONST(ITTRIGOUT, 3)),
coresight_cti_reg_rw(itchout, ITCHOUT),
coresight_cti_reg(itchoutack, ITCHOUTACK),
coresight_cti_reg(ittrigoutack, ITTRIGOUTACK),
+ coresight_cti_reg(ittrigoutack1, CTI_REG_SET_NR_CONST(ITTRIGOUTACK, 1)),
+ coresight_cti_reg(ittrigoutack2, CTI_REG_SET_NR_CONST(ITTRIGOUTACK, 2)),
+ coresight_cti_reg(ittrigoutack3, CTI_REG_SET_NR_CONST(ITTRIGOUTACK, 3)),
coresight_cti_reg_wo(ittriginack, ITTRIGINACK),
+ coresight_cti_reg_wo(ittriginack1, CTI_REG_SET_NR_CONST(ITTRIGINACK, 1)),
+ coresight_cti_reg_wo(ittriginack2, CTI_REG_SET_NR_CONST(ITTRIGINACK, 2)),
+ coresight_cti_reg_wo(ittriginack3, CTI_REG_SET_NR_CONST(ITTRIGINACK, 3)),
coresight_cti_reg_wo(itchinack, ITCHINACK),
#endif
NULL,
@@ -533,10 +551,50 @@ static umode_t coresight_cti_regs_is_visible(struct kobject *kobj,
{
struct device *dev = kobj_to_dev(kobj);
struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
+ const char * const qcom_suffix_registers[] = {
+ "triginstatus",
+ "trigoutstatus",
+#ifdef CONFIG_CORESIGHT_CTI_INTEGRATION_REGS
+ "ittrigin",
+ "ittrigout",
+ "ittriginack",
+ "ittrigoutack",
+#endif
+ };
+ int i, nr, max_bank;
+ size_t len;
if (attr == &dev_attr_asicctl.attr && !drvdata->config.asicctl_impl)
return 0;
+ /*
+ * Banked regs are exposed as <qcom_suffix_registers><nr> (nr = 1..3).
+ * - Hide them on standard CTIs.
+ * - On QCOM CTIs, hide suffixes beyond the number of banks implied
+ * by nr_trig_max (32 triggers per bank).
+ */
+ for (i = 0; i < ARRAY_SIZE(qcom_suffix_registers); i++) {
+ len = strlen(qcom_suffix_registers[i]);
+
+ if (strncmp(attr->name, qcom_suffix_registers[i], len))
+ continue;
+
+ if (kstrtoint(attr->name + len, 10, &nr))
+ continue;
+
+ if (!drvdata->is_qcom_cti)
+ return 0;
+
+ if (nr < 1 || nr > 3)
+ return 0;
+
+ max_bank = DIV_ROUND_UP(drvdata->config.nr_trig_max, 32) - 1;
+ if (nr > max_bank)
+ return 0;
+
+ break;
+ }
+
return attr->mode;
}
--
2.43.0
^ permalink raw reply related
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