linux-kernel - Re: [PATCH] spi: bcm2835: do not unregister controller in shutdown handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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