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
