[RFC PATCH 5/6] riscv: dts: starfive: jh7110: activate XPbmtUC

[Conor Dooley]

On Fri, Mar 13, 2026 at 01:44:06AM -0700, Bo Gan wrote:
> Set riscv,xpbmt-uncache-bit to 32 to match SoC memory map:
> 
>            [0x0,   0x40000000) Low MMIO
>     [0x40000000, 0x2_40000000) Cached Mem
>   [0x4_40000000, 0x6_40000000) Uncached Mem UC+
>   [0x9_00000000, 0x9_d0000000) High MMIO
> 
> Signed-off-by: Bo Gan <ganboing at gmail.com>


What I want know is how this whole setup interacts with the existing
support that we have for these devices?
Samuel's patchetset removed from the devicetree all of the nodes related
to having two mappings of the same memory, and modified the existing
erratum to only be required for older devicetrees.
You've not removed them, only added a new property. The non-coherent
peripherals on jh7110 already work prior to this patchset, is there not
going to be funky behaviour with both of these things operating in
parallel?

> ---
>  arch/riscv/boot/dts/starfive/jh7110.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi
> index 6e56e9d20bb06..6dfeb31538fba 100644
> --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
> @@ -14,6 +14,7 @@ / {
>  	compatible = "starfive,jh7110";
>  	#address-cells = <2>;
>  	#size-cells = <2>;
> +	riscv,xpbmt-uncache-bit = <32>;
>  
>  	cpus: cpus {
>  		#address-cells = <1>;
> -- 
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260313/7dd3f22c/attachment.sig>