Re: [PATCH v2 3/4] firmware: psci: Read and use vendor reset types

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 4/14/24 21:30, Elliot Berman wrote:
SoC vendors have different types of resets and are controlled through
various registers. For instance, Qualcomm chipsets can reboot to a
"download mode" that allows a RAM dump to be collected. Another example
is they also support writing a cookie that can be read by bootloader
during next boot. PSCI offers a mechanism, SYSTEM_RESET2, for these
vendor reset types to be implemented without requiring drivers for every
register/cookie.

Add support in PSCI to statically map reboot mode commands from
userspace to a vendor reset and cookie value using the device tree.

Reboot mode framework is close but doesn't quite fit with the
design and requirements for PSCI SYSTEM_RESET2. Some of these issues can
be solved but doesn't seem reasonable in sum:
  1. reboot mode registers against the reboot_notifier_list, which is too
     early to call SYSTEM_RESET2. PSCI would need to remember the reset
     type from the reboot-mode framework callback and use it
     psci_sys_reset.
  2. reboot mode assumes only one cookie/parameter is described in the
     device tree. SYSTEM_RESET2 uses 2: one for the type and one for
     cookie.
  3. psci cpuidle driver already registers a driver against the
     arm,psci-1.0 compatible. Refactoring would be needed to have both a
     cpuidle and reboot-mode driver.

Signed-off-by: Elliot Berman <quic_eberman@xxxxxxxxxxx>
---

[...]

+arch_initcall(psci_init_system_reset2_modes);

Perhaps this could be called from \/

Konrad

+
  int __init psci_dt_init(void)
  {
  	struct device_node *np;





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux