On 23/04/2026 19:59, Shah, Tanmay wrote: > Ack, I will rename it to xlnx,auto-boot. > >>> >>>>> + 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. >> > > So on some SoC, the bootloader supports loading and starting of the > remote processor. But it is totally user's choice. User can choose to > load & start one core of a cluster via bootloader and leave another core > powered-off. > That is why it is not possible to decide based on SoC compatible.
OK. The problem is that "user" is a bit vague and usually user choice goes to user-space. The property will be set or unset for ALL of given boards. So all of the DTS->DTB. That's why it should be clear why all such boards should behave like you described. If this is truly user, as in user-space, choice, then DT is not the way. > > If we don't want to make it a device-tree property then I can implement > in a different way. New way will detect if the remote is running or not > via EMMI/SCMI call to the firmware, and take a decision based on that. > If this new way works, then I don't think we need auto-boot property at all. > > Let me know your thoughts. This works for me and solves my questions from DT point of view, but I cannot judge whether this makes sense for you. Best regards, Krzysztof
