Re: [PATCH 1/2] dt-bindings: remoteproc: add AMD MicroBlaze binding

[Michal Simek]

On 4/15/26 09:07, Krzysztof Kozlowski wrote:
> On 15/04/2026 08:55, Michal Simek wrote:
> > > > Does it make sense?
> > >
> > > Yes, drop from DT. No need for generic stuff. Or describe the hardware.
> >
> > You need to describe that connection to HW. GPIOs, memory location, etc.
> > It means there must be any description.
>
> No, you can write user-space driver or pass everything through SW nodes.
> No need for DT description.

The firmware memory typically sits behind AXI-to-AXI bridges and 

interconnect switches. The bus topology varies between FPGA designs. 

DT ranges-based address translation is the standard way to describe 

this, and pushing it into userspace would just mean hardcoding what 

ranges already provides.

I don't think SW nodes should be used here.

> But if you want a DT description, then it must be for the specific
> hardware, since the hardware is not generic.

But there is specific HW loaded. It is loaded at power up and don't change over 
life cycle. What I am just saying that access to this fixed HW (in fpga) is 
generic. At this stage memory and gpio only.

What I was trying to say is that the hardware topology (memory window + 

reset GPIO) is the same regardless of the soft-core cpu (MicroBlaze,
RISC-V, etc.)/fpga, so naming it after the ISA architecture felt wrong to me 

too.

When I look at other bindings. For example this one.
Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml

the compatible describes the communication mechanism (FIFO-based G-Link), not 
the specific processor behind it. 

 

Our case is similar the compatible describes the control mechanism firmware 
loaded through a memory window, processor started via GPIO reset. What sits 
behind that interface varies and is opaque to the binding.
 

Would something like "amd,mem-gpio-rproc" be acceptable, following the same 
pattern where the compatible identifies the interface mechanism?

Thanks,
Michal