linux-kernel - SPI transfers in atomic context [Was: Re: [PATCH v1 1/1] mfd: rk8xx: Fix 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]

Message-ID: <sg5kgo5qjqyzfyk5nyjbkpgvbx6sfb7agc67ch6wsdq3etrsbf@h6xbtfs45k4w>
Date: Thu, 20 Mar 2025 11:10:47 +0100
From: Uwe Kleine-König <ukleinek@...ian.org>
To: Lee Jones <lee@...nel.org>, 
	Sebastian Reichel <sebastian.reichel@...labora.com>, Mark Brown <broonie@...nel.org>, 
	Wolfram Sang <wsa@...-dreams.de>
Cc: Dmitrii Osipenko <dmitry.osipenko@...labora.com>, Urja <urja@...a.dev>, 
	Heiko Stuebner <heiko@...ech.de>, linux-rockchip@...ts.infradead.org, linux-spi@...r.kernel.org, 
	linux-kernel@...r.kernel.org, kernel@...labora.com, stable@...r.kernel.org
Subject: SPI transfers in atomic context [Was: Re: [PATCH v1 1/1] mfd: rk8xx:
 Fix shutdown handler]

Hi,

On Thu, Aug 01, 2024 at 05:22:24PM +0200, Sebastian Reichel wrote:
> On Thu, Aug 01, 2024 at 02:18:23PM GMT, Lee Jones 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.
> > > +	 */
> > 
> > So why not just adapt the SPI driver now?
> 
> This patch is simple and thus can easily be backported, so that the
> Acer Chromebook shutdown is fixed in the stable kernels. SPI based
> rkxx has been using SYS_OFF_MODE_POWER_OFF_PREPARE from the start,
> so it's not a regression.
> 
> As far as I could see the SPI framework does not have something
> comparable to the I2C .xfer_atomic handler. So fixing up the
> Rockchip SPI driver probably involves creating some SPI core
> helpers. I'm not yet sure about the best way to deal with this.
> But I guess it will be better not having to backport all of the
> requires changes to stable.
> 
> In any case I think the next step in this direction is discussing
> how to handle this in general for SPI.
> 
> > What's the bet that if accepted, this hack is still here in 5 years time?
> 
> Even if I don't work on this now, I would expect somebody to have
> issues with broken shutdown on RK3588 boards before 5 years are
> over :)

I'd like to have power-off working on Qnap TS-433 in the next Debian
stable. With my Debian Kernel hat on I'd say cherry-picking such a
commit (if it's in mainline) is acceptable. Backporting a major
extension to the spi framework isn't.

So: Expectation confirmed! And while I agree that hacks are not nice,
I prefer a hack now over a machine that doesn't shut down properly over
the next five years (if Lee's expectation is also correct).

Can we maybe go forward and do both? Accept this hack patch now and work
on spi to make atomic xfers possible?

Mark, are there concerns from your side? 
Wolfram, are there things you would recommend to do differently in spi
than what you have in i2c?

Best regards
Uwe

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)