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