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.
TBH, I still wonder why we have .shutdown() and we simply don't use .remove() which would reduce the amount of work that people have to do validate that the hardware is put in a low power state and would also reduce the amount of burden on the various subsystems.
The difference between remove and shutdown really is that 'emergency' sense that shutdown is something that must complete in bounded time and thus only has to concern itself with quieting hardware to a safe state for the next step in the shutdown/reboot/kexec/kdump sequence.
I am fairly sure that no driver write knows about the being bound in time aspect.
Many remove handlers happily block until, eg all user files are closed or something to allow a graceful module unload.
Fair point.