[PATCH v12 0/8] Implement vendor resets for PSCI SYSTEM_RESET2
Florian Fainelli
florian.fainelli at broadcom.com
Thu Jul 24 09:38:00 PDT 2025
On 7/24/25 07:43, Arnd Bergmann wrote:
> On Thu, Jul 24, 2025, at 16:04, Shivendra Pratap wrote:
>> On 7/24/2025 6:18 PM, Krzysztof Kozlowski wrote:
>>> On 24/07/2025 14:24, Shivendra Pratap wrote:
>
>>> I strongly insist using compatible as way to find your device, not node
>>> names.
>> It will look better to switch to compatible. Will define a compatible for
>> psci reboot-mode binding and align the patch to use the compatible for sysfs.
>> Current patch defines reboot-mode as a property to psci, hope its fine to
>> define a compatible for this property like "psci-vendor-reset" or
>> "psci-reboot-modes"?
>>
>
> How about using the reboot driver name as the identifier in sysfs
> instead of the compatible string? That would make it independent of
> devicetree.
+1
>
> I had a related idea to provide some namespacing on the actual
> reboot syscall parameter, as we have two (or more) orthogonal
> concepts here, when there is more than one reboot driver and
> drivers support multiple modes.
>
> E.g. you could use
>
> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
> LINUX_REBOOT_CMD_RESTART2, "watchdog");
>
> vs
>
> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
> LINUX_REBOOT_CMD_RESTART2, "psci");
>
> to pick one of the drivers, or
>
> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
> LINUX_REBOOT_CMD_RESTART2, "bootloader");
>
> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
> LINUX_REBOOT_CMD_RESTART2, "recovery");
>
> to ask for a reboot from any driver that supports a mode, or
> combine the two and ask a specific mode in a specific driver like
>
> syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
> LINUX_REBOOT_CMD_RESTART2, "psci:bootloader");
Yes that seems entirely adequate as well.
If there is a single reboot driver registered say "psci" then you could
go with the short hand of specifying "bootloader" which would be
functionally equivalent to "psci:bootloader". That is, the driver name
becomes optional. This would maintain user-space compatibility with
existing systems that already support custom reboot modes.
--
Florian
More information about the linux-arm-kernel
mailing list