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

[Michal Simek]

On 4/15/26 14:19, Rob Herring wrote:
> 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.


If any fpga vendor creates the same configuration description will be the same 
for them too. But not a problem with having it generic to AMD only.

I think the point is to come up with proper compatible string which you will 
agree on.


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

Actually even current binding should have clock described and handled because 
clock has to be enabled before releasing GPIO out of reset. If it is coming 
outside of chip it should still be modeled.

Anyway I don't think we have ever end in a never ending stream of properties for 
our IP and this is not going to be the case too.

Thanks,
Michal