[<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