[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f481f7cc-6734-59b3-6432-5c2049cd87ea@gmail.com>
Date: Mon, 4 Oct 2021 09:55:32 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Mark Brown <broonie@...nel.org>,
Lino Sanfilippo <LinoSanfilippo@....de>, rjui@...adcom.com,
sbranden@...adcom.com, bcm-kernel-feedback-list@...adcom.com,
nsaenz@...nel.org, linux-spi@...r.kernel.org,
linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
p.rosenberger@...bus.com, linux-integrity@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH] spi: bcm2835: do not unregister controller in shutdown
handler
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
Powered by blists - more mailing lists