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 <[email protected]>
+
+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
