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

[Michal Simek]

On 4/14/26 19:53, Krzysztof Kozlowski wrote:
> On 14/04/2026 18:15, Ben Levinsky wrote:
>
> A nit, subject: drop second/last, redundant "binding". The "dt-bindings"
> prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> > +---
> > +$id: http://devicetree.org/schemas/remoteproc/amd,microblaze.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: AMD MicroBlaze remote processor
> > +
> > +maintainers:
> > +  - Ben Levinsky <ben.levinsky@xxxxxxx>
> > +
> > +description:
> > +  MicroBlaze remote processor controlled by Linux through the remoteproc
> > +  framework.
>
> Describe hardware, not Linux frameworks. IOW, Linux framework is here
> irrelevant.
>
> > +
> > +  The executable firmware memory window is described in the
> > +  MicroBlaze-local address space by the node's reg property and translated
> > +  to the system physical address space with standard devicetree address
> > +  translation provided by the parent bus node's ranges property.
> > +
> > +properties:
> > +  $nodename:
> > +    pattern: "^remoteproc@[0-9a-f]+$"
> > +
> > +  compatible:
> > +    const: amd,microblaze
>
> microblaze is architecture, so this feels way too generic. You need SoC
> specific compatibles and I suggest do not reference architecture, but
> name or the function of the processor, if there are such.

I have been arguing internally that I think when you look at driver itself it 
can be pretty much generic loader for any firmware and doesn't really matter if 
target subsystem is Microblaze/Risc-V/whatever based. And I was suggesting them 
to use more generic name.

Because at the end of day reg property is pointing to location where firmware 
should be loaded and gpio is a way how to start that subsystem and there is 
nothing Microblaze specific.

I can also imagine that the same driver could be extended with optional power 
domain, power regulator and clock properties if there is a need to drive them 
before subsystem gets out of reset.

Does it make sense?

Thanks,
Michal