On Wed, Apr 15, 2026 at 1:16 AM Michal Simek <[email protected]> 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 > 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
