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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 15/04/2026 08:16, Michal Simek 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@amd.com>
>>> +
>>> +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 

Luckily I don't speak about driver :)

> target subsystem is Microblaze/Risc-V/whatever based. And I was suggesting them 
> to use more generic name.

So the binding is for drivers - generic loader? Then simply no. Not
suitable for DT.

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

Yes, drop from DT. No need for generic stuff. Or describe the hardware.

Best regards,
Krzysztof