On Mon, Oct 04, 2021 at 09:55:32AM -0700, Florian Fainelli wrote:
On 10/4/21 9:51 AM, Jason Gunthorpe wrote:
On Mon, Oct 04, 2021 at 09:36:37AM -0700, Florian Fainelli wrote:
No please don't, I should have arguably justified the reasons why better, but the main reason is that one of the platforms on which this driver is used has received extensive power management analysis and changes, and shutting down every bit of hardware, including something as small as a SPI controller, and its clock (and its PLL) helped meet stringent power targets.
Huh? for device shutdown? What would this matter if the next step is reboot or power off?
Power off, the device is put into a low power state (equivalent to ACPI S5) and then a remote control key press, or a GPIO could wake-up the device again. While it is in that mode, it consumes less than 0.5W(AC). Imagine your stick/cast/broom behind your TV falling in that category.
So really this is more of a very deep sleep that cannot be recovered from than what other platforms would call a shutdown - eg the powerdomain of the device under driver control will not loose power.
I'm kind of surprised a scheme like this didn't involve a FW call after Linux is done with the CPUs to quiet all the HW and let it sleep, I've built things that way before at least.
I am fairly sure that no driver write knows about the being bound in time aspect.
Well, it is a logical consequence. The system is shutting down, no driver should be designed to deadlock the shutdown forever.
I suppose this is why I've occasionally seen Linux just hang at a black screen and no power off when told to shutdown :)
Jason