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. -- Florian
