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

[Rob Herring]

On Wed, Apr 15, 2026 at 1:16 AM Michal Simek <michal.simek@xxxxxxx> wrote:
>
>
>
> 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.

Generic to AMD though, not everyone, right?

I agree it probably doesn't matter what the processor arch is. The
compatible just needs to be specific enough when there's some
quirk/feature in the interface to the operating system, that we can
distinguish the specific implementation *without* a DT update.

> 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.

That never works because then there's timing/ordering constraints for
enabling/disabling all those resources. Then we end up with a never
ending stream of properties added which results in a poorly designed
binding.

Rob