Re: [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature

[Krzysztof Kozlowski <krzk@kernel.org>]

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 <tanmay.shah@amd.com>
>>> ---
>>>  .../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