Re: [PATCH v1 01/24] psci: Accessor for configured PSCI version

2020-11-11 Thread David Brazdil
> > + > > struct psci_operations { > > u32 (*get_version)(void); > > int (*cpu_suspend)(u32 state, unsigned long entry_point); > > I still maintain that populating .get_version in all cases instead of > duplicating an existing functionality is a better outcome. PSCI not > supported would

Re: [PATCH v1 01/24] psci: Accessor for configured PSCI version

2020-11-10 Thread Marc Zyngier
On 2020-11-09 11:32, David Brazdil wrote: The version of PSCI that the kernel should use to communicate with firmware is typically obtained from probing PSCI_VERSION. However, that doesn't work for PSCI v0.1 where the host gets the information from DT/ACPI, or if PSCI is not supported / was disab

[PATCH v1 01/24] psci: Accessor for configured PSCI version

2020-11-09 Thread David Brazdil
The version of PSCI that the kernel should use to communicate with firmware is typically obtained from probing PSCI_VERSION. However, that doesn't work for PSCI v0.1 where the host gets the information from DT/ACPI, or if PSCI is not supported / was disabled. KVM's host PSCI proxy needs to be conf