Re: [PATCH 2/2] riscv: dts: sophgo: Add dma-coherent to SG2042 PCIe controllers
Chen Wang <[email protected]> Thu, 2 Apr 2026 16:43:58 +0800
| Newsgroups | dev.linux.lists.sophgo,org.infradead.lists.linux-riscv,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci,org.kernel.vger.stable |
|---|---|
| Message-ID | <MA5PR01MB12500707BE1C6E11EC3F4B94FFE51A@MA5PR01MB12500.INDPRD01.PROD.OUTLOOK.COM> |
On 4/1/2026 1:12 AM, Han Gao wrote: > SG2042's PCIe root complexes are cache-coherent with the CPU. Mark all > four PCIe controller nodes (pcie_rc0 through pcie_rc3) as dma-coherent > so the kernel uses coherent DMA mappings instead of non-coherent bounce > buffering. > > Cc: [email protected] > Signed-off-by: Han Gao <[email protected]> > --- > arch/riscv/boot/dts/sophgo/sg2042.dtsi | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/riscv/boot/dts/sophgo/sg2042.dtsi b/arch/riscv/boot/dts/sophgo/sg2042.dtsi > index 9fddf3f0b3b9..3af770549742 100644 > --- a/arch/riscv/boot/dts/sophgo/sg2042.dtsi > +++ b/arch/riscv/boot/dts/sophgo/sg2042.dtsi > @@ -417,6 +417,7 @@ pcie_rc0: pcie@7060000000 { > vendor-id = <0x1f1c>; > device-id = <0x2042>; > cdns,no-bar-match-nbits = <48>; > + dma-coherent; > msi-parent = <&msi>; > status = "disabled"; > }; > @@ -439,6 +440,7 @@ pcie_rc1: pcie@7060800000 { > vendor-id = <0x1f1c>; > device-id = <0x2042>; > cdns,no-bar-match-nbits = <48>; > + dma-coherent; > msi-parent = <&msi>; > status = "disabled"; > }; > @@ -461,6 +463,7 @@ pcie_rc2: pcie@7062000000 { > vendor-id = <0x1f1c>; > device-id = <0x2042>; > cdns,no-bar-match-nbits = <48>; > + dma-coherent; > msi-parent = <&msi>; > status = "disabled"; > }; > @@ -483,6 +486,7 @@ pcie_rc3: pcie@7062800000 { > vendor-id = <0x1f1c>; > device-id = <0x2042>; > cdns,no-bar-match-nbits = <48>; > + dma-coherent; > msi-parent = <&msi>; > status = "disabled"; > }; For binding changes, LGTM. But I have a question regarding this change in dtsi. From your patch description, I understand that enabling the `dma-coherent` attribute requires upgrading the firmware `fip.bin`. If a user only updates the kernel (which is relatively easy) but forgets or doesn't know how to upgrade the firmware, enabling `coherent` might cause the kernel to skip all explicit cache maintenance operations. Could this pose a subtle risk? Wouldn't it be safer to leave the upstream unchanged in dtsi and allow users to add the `dma-coherent` attribute themselves after they upgrade the firmware? I would greatly appreciate your guidance. Thanks, Chen