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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20c5ee69-3510-4c15-aa40-6d61c64d8ef1@collabora.com>
Date: Thu, 1 Aug 2024 21:05:03 +0300
From: Dmitry Osipenko <dmitry.osipenko@...labora.com>
To: Sebastian Reichel <sebastian.reichel@...labora.com>,
 Heiko Stübner <heiko@...ech.de>
Cc: Lee Jones <lee@...nel.org>, Mark Brown <broonie@...nel.org>,
 Urja <urja@...a.dev>, linux-rockchip@...ts.infradead.org,
 linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
 kernel@...labora.com, stable@...r.kernel.org
Subject: Re: [PATCH v1 1/1] mfd: rk8xx: Fix shutdown handler

On 8/1/24 20:52, Sebastian Reichel wrote:
> Hi,
> 
> On Thu, Aug 01, 2024 at 07:41:44PM GMT, Heiko Stübner wrote:
>> Am Donnerstag, 1. August 2024, 17:31:33 CEST schrieb Dmitry Osipenko:
>>> On 7/30/24 21:05, Sebastian Reichel wrote:
>>>> +	/*
>>>> +	 * Currently the Rockchip SPI driver always sleeps when doing SPI
>>>> +	 * transfers. This is not allowed in the SYS_OFF_MODE_POWER_OFF
>>>> +	 * handler, so we are using the prepare handler as a workaround.
>>>> +	 * This should be removed once the Rockchip SPI driver has been
>>>> +	 * adapted.
>>>> +	 */
>>>> +	if (is_spi)
>>>> +		pwr_off_mode = SYS_OFF_MODE_POWER_OFF_PREPARE;
>>>
>>> This prevents the syscore_shutdown() step from execution. Is it better
>>> than not powering off?
>>>
>>> I'd rather skip registration of the power-off handlers in a case of SPI :)
>>
>> Or blasphemous thought, we could live with the warning-splash for a bit.
>>
>> From Sebastian's log I assume the WARNING comes from the
>> wait_for_completion() in spi_transfer_wait(), and I guess the transfer
>> with the poweroff command itself will already have happened then?
>>
>> So the device is most likely still powered off in that case?
>> Not sure how much of "bad taste" that thought is though ;-)
> 
> Yes, as far as I could see it works fine (the splash from the commit
> message is from exactly this solution running on RK3588 EVB1 and the
> board was powered off properly as far as I can tell). But it felt a
> bit strange to knowingly introduce an error splash in a fix intended
> for being backported to the stable trees, so I switched to the current
> version before sending.

Can you add a busy-wait to the SPI driver TX func for the case where
it's invoked with a disabled interrupts? That could be a better
workaround, silencing the warning and keeping power-off working properly.

-- 
Best regards,
Dmitry


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ