On 23/04/2026 17:14, Shah, Tanmay wrote: > Hello, > > Thanks for reviews. Please see my comments below. > > On 4/23/2026 4:09 AM, Krzysztof Kozlowski wrote: >> On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote: >>> Add auto-boot property to notify that remote processor is setup and >>> ready to boot. Linux can attempt to boot or attach to already running >>> remote processor. "firmware-name" property is used to mention default >>> firmware to boot when linux starts the remote processor. >>> >>> Signed-off-by: Tanmay Shah <[email protected]> >>> --- >>> .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git >>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml >>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml >>> index ee63c03949c9..0d27260e3baa 100644 >>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml >>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml >>> @@ -135,6 +135,14 @@ patternProperties: >>> - description: vring1 >>> additionalItems: true >>> >>> + auto-boot: >> >> Last months, I have been asking AMD to follow writing-bindings doc or >> other DT guidelines way too many times. >> >> Or you just sent us downstream... Do you see anywhere such property? >> What properties do you see? How are they named? >> > > I should have put note about this. Current auto-boot properties are > named like st,auto-boot fsl,auto-boot etc. but nothing vendor specific > there. Can we have a common auto-boot property? Similar to > firmware-name? If we agree to it then what's the correct location? New > file remoteproc.yaml is okay?
Common properties go to dtschema, so it would need to go there, but the point is that it's way too generic - every component with FW could be called "auto-boot". This should stay vendor property, IMO. > >>> + type: boolean >>> + description: remote core is either already running or ready to boot >> >> And why is this property of a board? >> > > Not sure what indicates it is? The property is under remoteproc child > device that is SOC level property. Remote core is on same SOC wher linux > core is running. So it is implied by SoC compatible? Please provide some arguments why it cannot be implied by the SoC compatible. I gave you one way out, but if you disagree then no problem. > >>> + >>> + firmware-name: >>> + maxItems: 1 >>> + description: default firmware to load >> >> Can you load non-default firmware later? IOW, why adding description >> here, what is special? >> > > The rootfs contains other firmware demos, and it is possible to stop the > default firmware, load other fw elf and re-run the remote core. > I don't have strong preference on the description part, I will remove it > if redundant. No, it's fine, I wanted to be sure that such use case makes sense. Best regards, Krzysztof
