* Re: [PATCH v4 0/4] Introduce Allwinner H616 PWM controller
From: Uwe Kleine-König @ 2026-03-25 7:14 UTC (permalink / raw)
To: Richard GENOUD
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Philipp Zabel, Paul Kocialkowski,
Thomas Petazzoni, John Stultz, Joao Schim, linux-pwm, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <b47801f9-3828-4c68-992c-e85373576f3d@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
Hello Richard,
On Mon, Mar 23, 2026 at 05:27:07PM +0100, Richard GENOUD wrote:
> Hi Uwe, do you plan to grab this series or does it needs some further
> reviews?
I didn't find the time to look into your patches yet, but I have them on
my list. Unfortunately there is quite some more on that list, so I'll
have to ask you for some patience.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] clk: spear: fix resource leak in clk_register_vco_pll()
From: Viresh Kumar @ 2026-03-25 7:07 UTC (permalink / raw)
To: Haoxiang Li
Cc: vireshk, mturquette, sboyd, linux-arm-kernel, soc, linux-clk,
linux-kernel
In-Reply-To: <20260325062204.169648-1-lihaoxiang@isrc.iscas.ac.cn>
On 25-03-26, 14:22, Haoxiang Li wrote:
> 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:
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* RE: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
From: Hongxing Zhu @ 2026-03-25 7:06 UTC (permalink / raw)
To: manivannan.sadhasivam@oss.qualcomm.com, Bjorn Helgaas,
Mahesh J Salgaonkar, Oliver O'Halloran, Will Deacon,
Lorenzo Pieralisi, Krzysztof Wilczy��ski,
Manivannan Sadhasivam, Rob Herring, Heiko Stuebner, Philipp Zabel
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-rockchip@lists.infradead.org,
Niklas Cassel, Wilfred Mallawa, Krishna Chaitanya Chundru,
Lukas Wunner, Brian Norris, Wilson Ding
In-Reply-To: <20260310-pci-port-reset-v7-0-9dd00ccc25ab@oss.qualcomm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 16040 bytes --]
Hi Mani:
I've accidentally encountered a new issue based on the reset root port patch-set.
After performing a few hot-reset operations, the PCIe link enters a continuous up/down cycling pattern.
I found that calling pci_reset_secondary_bus() first in pcibios_reset_secondary_bus() appears to resolve this issue.
Have you experienced a similar problem?
"
...
[ 141.897701] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
[ 142.086341] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
[ 142.092038] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000c00) link down detected
...
"
Platform: i.MX95 EVK board plus local Root Ports reset supports based on the #1 and #2 patches of v7 patch-set.
Notes of the logs:
- One Gen3 NVME device is connected.
- "./memtool 4c341058=0;./memtool 4c341058=1;" is used to toggle the LTSSM_EN bit to trigger the link down.
- Toggle BIT6 of Bridge Control Register to trigger hot reset by "./memtool 4c30003c=004001ff; ./memtool 4c30003c=000001ff;"
- The Root Port reset patches works correctly at first.
However, after several hot-reset triggers, the link enters a repeated down/up cycling state.
Logs:
[ 3.553188] imx6q-pcie 4c300000.pcie: host bridge /soc/pcie@4c300000 ranges:
[ 3.560308] imx6q-pcie 4c300000.pcie: IO 0x006ff00000..0x006fffffff -> 0x0000000000
[ 3.568525] imx6q-pcie 4c300000.pcie: MEM 0x0910000000..0x091fffffff -> 0x0010000000
[ 3.577314] imx6q-pcie 4c300000.pcie: config reg[1] 0x60100000 == cpu 0x60100000
[ 3.796029] imx6q-pcie 4c300000.pcie: iATU: unroll T, 128 ob, 128 ib, align 4K, limit 1024G
[ 4.003746] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
[ 4.009553] imx6q-pcie 4c300000.pcie: PCI host bridge to bus 0000:00
root@imx95evk:~#
root@imx95evk:~#
root@imx95evk:~# ./memtool 4c341058=0;./memtool 4c341058=1; Writing 32-bit value 0x0 to address 0x4C341058
Writing 32-bit v
[ 87.265348] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000d01) link down detected
alue 0x1 to adder
[ 87.273106] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down
ss 0x4C341058
[ 87.281264] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
[ 87.289245] pci 0000:01:00.0: AER: can't recover (no error_detected callback)
root@imx95evk:~# [ 87.514216] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
[ 87.702968] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
[ 87.834983] pcieport 0000:00:00.0: Root Port has been reset
[ 87.840714] pcieport 0000:00:00.0: AER: device recovery failed
[ 87.846592] imx6q-pcie 4c300000.pcie: Rescan bus after link up is detected
[ 87.855947] pcieport 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 87.864423] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
root@imx95evk:~#
root@imx95evk:~# cat /proc/interrupts | grep lnk;
273: 2 0 0 0 0 0 GICv3 342 Level PCIe PME, lnk_notify
root@imx95evk:~#
root@imx95evk:~#
root@imx95evk:~# ./memtool 4c30003c=004001ff; ./memtool 4c30003c=000001ff; Writing 32-bit va
[ 107.028086] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000d00) link down detected lue 0x4001FF to a
[ 107.037018] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down ddress 0x4C30003C
[ 107.045137] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
Writing 32-bit
[ 107.053332] pci 0000:01:00.0: AER: can't recover (no error_detected callback) value 0x1FF to address 0x4C30003C root@imx95evk:~#
[ 107.282146] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
[ 107.470801] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
[ 107.602823] pcieport 0000:00:00.0: Root Port has been reset
[ 107.608601] pcieport 0000:00:00.0: AER: device recovery failed
[ 107.614497] imx6q-pcie 4c300000.pcie: Rescan bus after link up is detected
[ 107.623805] pcieport 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 107.632281] pci_bus 0000:01: busn_res: [bus 01] end is updated to 01
root@imx95evk:~#
root@imx95evk:~# cat /proc/interrupts | grep lnk;
273: 4 0 0 0 0 0 GICv3 342 Level PCIe PME, lnk_notify
root@imx95evk:~#
root@imx95evk:~# ./memtool 4c30003c=004001ff; ./memtool 4c30003c=000001ff; Writing 32-bit va
[ 133.424041] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000d00) link down detected lue 0x4001FF to a
[ 133.432954] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down ddress 0x4C30003C
[ 133.441106] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
Writing 32-bit
[ 133.449309] pci 0000:01:00.0: AER: can't recover (no error_detected callback) value 0x1FF to address 0x4C30003C root@imx95evk:~#
[ 133.677824] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
[ 133.870414] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
[ 134.002534] pcieport 0000:00:00.0: Root Port has been reset
[ 134.008307] pcieport 0000:00:00.0: AER: device recovery failed
[ 134.014193] imx6q-pcie 4c300000.pcie: Rescan bus after link up is detected
[ 134.023418] pcieport 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 134.031881] pci_bus 0000:01: busn_res: [bus 01] end is updated to 01
root@imx95evk:~# ./memtool 4c30003c=004001ff; ./memtool 4c30003c=000001ff; Writing 32-bit va
[ 140.149713] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000d00) link down detected lue 0x4001FF to a
[ 140.158614] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down ddress 0x4C30003C
[ 140.166779] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
[ 140.174981] pci 0000:01:00.0: AER: can't recover (no error_detected callback) Writing 32-bit value 0x1FF to address 0x4C30003C root@imx95evk:~#
[ 140.401605] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
[ 140.590491] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
[ 140.596206] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000c00) link down detected
root@imx95evk:~#
[ 141.630311] pcieport 0000:00:00.0: Data Link Layer Link Active not set in 100 msec
[ 141.637950] pcieport 0000:00:00.0: Failed to reset Root Port: -25
[ 141.644095] pcieport 0000:00:00.0: AER: subordinate device reset failed
[ 141.650883] pcieport 0000:00:00.0: AER: device recovery failed
[ 141.656784] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down
[ 141.663520] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
[ 141.670271] pci 0000:01:00.0: AER: can't recover (no error_detected callback)
[ 141.897701] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
[ 142.086341] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
[ 142.092038] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000c00) link down detected
[ 143.126273] pcieport 0000:00:00.0: Data Link Layer Link Active not set in 100 msec
[ 143.133919] pcieport 0000:00:00.0: Failed to reset Root Port: -25
[ 143.140052] pcieport 0000:00:00.0: AER: subordinate device reset failed
[ 143.146747] pcieport 0000:00:00.0: AER: device recovery failed
[ 143.152604] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down
[ 143.159314] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
[ 143.166022] pci 0000:01:00.0: AER: can't recover (no error_detected callback)
[ 143.389723] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
[ 143.582294] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
[ 143.587996] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000c00) link down detected
Thanks.
Best Regards
Richard Zhu
> -----Original Message-----
> From: Manivannan Sadhasivam via B4 Relay
> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org>
> Sent: 2026Äê3ÔÂ10ÈÕ 22:02
> To: Bjorn Helgaas <bhelgaas@google.com>; Mahesh J Salgaonkar
> <mahesh@linux.ibm.com>; Oliver O'Halloran <oohall@gmail.com>; Will
> Deacon <will@kernel.org>; Lorenzo Pieralisi <lpieralisi@kernel.org>;
> Krzysztof Wilczy¨½ski <kwilczynski@kernel.org>; Manivannan Sadhasivam
> <mani@kernel.org>; Rob Herring <robh@kernel.org>; Heiko Stuebner
> <heiko@sntech.de>; Philipp Zabel <p.zabel@pengutronix.de>
> Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-arm-msm@vger.kernel.org; linux-rockchip@lists.infradead.org; Niklas
> Cassel <cassel@kernel.org>; Wilfred Mallawa <wilfred.mallawa@wdc.com>;
> Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>;
> mani@kernel.org; Lukas Wunner <lukas@wunner.de>; Hongxing Zhu
> <hongxing.zhu@nxp.com>; Brian Norris <briannorris@chromium.org>;
> Wilson Ding <dingwei@marvell.com>; Manivannan Sadhasivam
> <manivannan.sadhasivam@oss.qualcomm.com>; Frank Li
> <frank.li@nxp.com>; Manivannan Sadhasivam <mani@kernel.org>
> Subject: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a
> platform specific way
>
> Hi,
>
> Currently, in the event of AER/DPC, PCI core will try to reset the slot (Root
> Port) and its subordinate devices by invoking bridge control reset and FLR.
> But in some cases like AER Fatal error, it might be necessary to reset the
> Root Ports using the PCI host bridge drivers in a platform specific way (as
> indicated by the TODO in the pcie_do_recovery() function in
> drivers/pci/pcie/err.c).
> Otherwise, the PCI link won't be recovered successfully.
>
> So this series adds a new callback 'pci_host_bridge::reset_root_port' for the
> host bridge drivers to reset the Root Port when a fatal error happens.
>
> Also, this series allows the host bridge drivers to handle PCI link down event
> by resetting the Root Ports and recovering the bus. This is accomplished by
> the help of the new 'pci_host_handle_link_down()' API. Host bridge drivers
> are expected to call this API (preferrably from a threaded IRQ handler) with
> relevant Root Port 'pci_dev' when a link down event is detected for the port.
> The API will reuse the pcie_do_recovery() function to recover the link if AER
> support is enabled, otherwise it will directly call the reset_root_port()
> callback of the host bridge driver (if exists).
>
> For reference, I've modified the pcie-qcom driver to call
> pci_host_handle_link_down() API with Root Port 'pci_dev' after receiving the
> LDn global_irq event and populated 'pci_host_bridge::reset_root_port()'
> callback to reset the Root Ports.
>
> Testing
> -------
>
> Tested on Qcom Lemans AU Ride platform with Host and EP SoCs connected
> over PCIe link. Simulated the LDn by disabling LTSSM_EN on the EP and I
> could verify that the link was getting recovered successfully.
>
> Changes in v7:
> - Dropped Rockchip Root port reset patch due to reported issues. But the
> series
> works on other platforms as tested by others.
> - Added pci_{lock/unlock}_rescan_remove() to guard pci_bus_error_reset()
> as the
> device could be removed in-between due to Native hotplug interrupt.
> - Rebased on top of v7.0-rc1
> - Link to v6:
> https://lore.ke/
> rnel.org%2Fr%2F20250715-pci-port-reset-v6-0-6f9cce94e7bb%40oss.qualcom
> m.com&data=05%7C02%7Chongxing.zhu%40nxp.com%7Cfc7ebf6f8fbf44e7e2
> 9d08de7eada6e1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
> 9087481469497457%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3
> D%3D%7C0%7C%7C%7C&sdata=0Jfe20c6n9OcTMUApKYRXuDd%2B0o85QzjG
> %2B4IbIT%2BT6k%3D&reserved=0
>
> Changes in v6:
> - Incorporated the patch:
> https://lore.ke/
> rnel.org%2Fall%2F20250524185304.26698-2-manivannan.sadhasivam%40lina
> ro.org%2F&data=05%7C02%7Chongxing.zhu%40nxp.com%7Cfc7ebf6f8fbf44e7
> e29d08de7eada6e1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C
> 639087481469541004%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> %3D%3D%7C0%7C%7C%7C&sdata=Y8Qjn9yJfxJ41h%2FRHjPITgY%2BQOqh5LEr
> zir%2Fe3s%2B8g8%3D&reserved=0
> - Link to v5:
> https://lore.ke/
> rnel.org%2Fr%2F20250715-pci-port-reset-v5-0-26a5d278db40%40oss.qualco
> mm.com&data=05%7C02%7Chongxing.zhu%40nxp.com%7Cfc7ebf6f8fbf44e7e
> 29d08de7eada6e1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
> 39087481469572178%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> 3D%3D%7C0%7C%7C%7C&sdata=JUoqvSMB2sMZAxmGlGlN3iKYIQ9edjQhEfD
> kQpqdeWQ%3D&reserved=0
>
> Changes in v5:
> * Reworked the pci_host_handle_link_down() to accept Root Port instead of
> resetting all Root Ports in the event of link down.
> * Renamed 'reset_slot' to 'reset_root_port' to avoid confusion as both terms
> were used interchangibly and the series is intended to reset Root Port
> only.
> * Added the Rockchip driver change to this series.
> * Dropped the applied patches and review/tested tags due to rework.
> * Rebased on top of v6.16-rc1.
>
> Changes in v4:
> - Handled link down first in the irq handler
> - Updated ICC & OPP bandwidth after link up in reset_slot() callback
> - Link to v3:
> https://lore.ke/
> rnel.org%2Fr%2F20250417-pcie-reset-slot-v3-0-59a10811c962%40linaro.org&
> data=05%7C02%7Chongxing.zhu%40nxp.com%7Cfc7ebf6f8fbf44e7e29d08de7
> eada6e1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6390874814
> 69600118%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7
> C0%7C%7C%7C&sdata=k39HxA8Zgft%2FGJ9HaugboOoPbQQkctqWRtiiGa0H95
> I%3D&reserved=0
>
> Changes in v3:
> - Made the pci-host-common driver as a common library for host controller
> drivers
> - Moved the reset slot code to pci-host-common library
> - Link to v2:
> https://lore.ke/
> rnel.org%2Fr%2F20250416-pcie-reset-slot-v2-0-efe76b278c10%40linaro.org&
> data=05%7C02%7Chongxing.zhu%40nxp.com%7Cfc7ebf6f8fbf44e7e29d08de7
> eada6e1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6390874814
> 69625186%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7
> C0%7C%7C%7C&sdata=kQx%2B%2BgCe5TUTDDEwHttUGmqx0WYgL20WfPMf
> WmfA1dk%3D&reserved=0
>
> Changes in v2:
> - Moved calling reset_slot() callback from pcie_do_recovery() to
> pcibios_reset_secondary_bus()
> - Link to v1:
> https://lore.ke/
> rnel.org%2Fr%2F20250404-pcie-reset-slot-v1-0-98952918bf90%40linaro.org&
> data=05%7C02%7Chongxing.zhu%40nxp.com%7Cfc7ebf6f8fbf44e7e29d08de7
> eada6e1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6390874814
> 69647067%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7
> C0%7C%7C%7C&sdata=kag0bpW2uzExYJAl84eHiMcUMVJmMcBPCahete6bDq
> 8%3D&reserved=0
>
> Signed-off-by: Manivannan Sadhasivam
> <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> Manivannan Sadhasivam (4):
> PCI/ERR: Add support for resetting the Root Ports in a platform
> specific way
> PCI: host-common: Add link down handling for Root Ports
> PCI: qcom: Add support for resetting the Root Port due to link down
> event
> misc: pci_endpoint_test: Add AER error handlers
>
> drivers/misc/pci_endpoint_test.c | 20 +++++
> drivers/pci/controller/dwc/pcie-qcom.c | 143
> ++++++++++++++++++++++++++++++-
> drivers/pci/controller/pci-host-common.c | 35 ++++++++
> drivers/pci/controller/pci-host-common.h | 1 +
> drivers/pci/pci.c | 21 +++++
> drivers/pci/pcie/err.c | 6 +-
> include/linux/pci.h | 1 +
> 7 files changed, 221 insertions(+), 6 deletions(-)
> ---
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> change-id: 20250715-pci-port-reset-4d9519570123
>
> Best regards,
> --
> Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
^ permalink raw reply
* [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
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