From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19EEDC433F5 for ; Mon, 4 Oct 2021 16:33:41 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D824A61269 for ; Mon, 4 Oct 2021 16:33:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D824A61269 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/zV3o43yH0U91K/MbVRlJUfccu1ZQ/HAQtz2XV+Vrjk=; b=BHckC+bcC5DCEFQZa4wt7V9vLq M/dqS2PF49s+fWDl5PAZVFSjggqrgjWuotuaZdpVJLIilJrn5trBYrR6yUY7VsWbHIook7Bz883xc jd5VdCaYLuJa9utc4Zg73JaMYbcWXuSglI7EETczSJTvqv5yfdm8E69H3mGbvg42BynKg34eUVGxD 77w/gHyBctV9N5k+ZQaOEU2Z2ApQFgWlxhUCk3fU7QiNIHPq9eBZQw34tf13rfQjFZKh72io3r6U8 D7p3a9pLyprolgC+DpbOCWpX9zdYS7Tl6sIXqnZfxS+vwu2VH+x9yXYzE1fAQXTLmGcCjH78EVQtd 8yMUta4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mXQsC-0076XG-O4; Mon, 04 Oct 2021 16:31:28 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mXQs8-0076Vh-Kl; Mon, 04 Oct 2021 16:31:26 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id BD5DE61184; Mon, 4 Oct 2021 16:31:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633365084; bh=xC5zyZY8esd3E0X5X90FwEIpcl9VP5zy4k4PAm5SGaA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i8vpfOh36DB3ixtiEcbdS4OLgvMOR/hegKqLFwK4uQxo6TYEMtzZC/AgqfHRcsCrH cdqpPpDN/5F0k83bkujOD4sGzMzu3p1p3uS+YkT8w9/pO000h5fy+b3qk1CbrFxcxr 0U300JuKxhKys0R8t8DGKNv1a3sUrtga2qYt3mBU2cCinNBTD7vbqWvt5tGLg5adwr 2SAsOKN24KBWCOTSJ/eoAR834iFjXHoHq4IxcN256S/i+K+J12wRbB0gYnX51/v97N 3qR6OdTxIt6B459Jetw/vdgRxwapwC0N+TtIMiOD+lEMNIx/Kpk3Glu5fEPUKG+EK1 UGF+AH67qVZMw== Date: Mon, 4 Oct 2021 17:31:21 +0100 From: Mark Brown To: Jason Gunthorpe Cc: Lino Sanfilippo , f.fainelli@gmail.com, rjui@broadcom.com, sbranden@broadcom.com, bcm-kernel-feedback-list@broadcom.com, nsaenz@kernel.org, linux-spi@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, p.rosenberger@kunbus.com, linux-integrity@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] spi: bcm2835: do not unregister controller in shutdown handler Message-ID: References: <20210928195657.5573-1-LinoSanfilippo@gmx.de> <20211001175422.GA53652@sirena.org.uk> <2c4d7115-7a02-f79e-c91b-3c2dd54051b2@gmx.de> <20211004131756.GW3544071@ziepe.ca> <20211004154436.GY3544071@ziepe.ca> MIME-Version: 1.0 In-Reply-To: <20211004154436.GY3544071@ziepe.ca> X-Cookie: If it heals good, say it. X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211004_093124_750771_D2EDF589 X-CRM114-Status: GOOD ( 28.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9012349873732383129==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============9012349873732383129== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Vk4aO1eaTM88kUGw" Content-Disposition: inline --Vk4aO1eaTM88kUGw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 04, 2021 at 12:44:36PM -0300, Jason Gunthorpe wrote: > On Mon, Oct 04, 2021 at 03:12:20PM +0100, Mark Brown wrote: > > On Mon, Oct 04, 2021 at 10:17:56AM -0300, Jason Gunthorpe wrote: > > > When something like kexec happens we need the machine to be in a state > > > where random DMA's are not corrupting memory. > > That's all well and good but there's no point in implementing something > > half baked that's opening up a whole bunch of opportunities to crash the > > system if more work comes in after it's half broken the device setup. = =20 > Well, that is up to the driver implementing this. It looks like device > shutdown is called before the userspace is all nuked so yes, > concurrency with userspace is a possible concern here. It's not just userspace that can initiate things - interrupts are also an issue, someone could press a button or whatever. Frankly for SPI the quiescing part doesn't seem like logic that should be implemented in drivers, it's a subsystem level thing since there's nothing driver specific about it. > > > Due to the emergency sort of nature it is not appropriate to do > > > locking complicated sorts of things like struct device unregistrations > > > here. > > That's just not what's actually implemented in a bunch of places, nor > > something one would infer from the documentation ("Called at shut-down > > to quiesce the device", no mention of emergency cases which I'd guess > > would just be kdump) -=20 > Drivers mis understanding stuff is not new.. Not just drivers, entire subsystems. And like I say given the documentation I'd be hard pressed to say that it's a misunderstanding. > > that's a different thing and definitely abusing the API. I would guess > > that a good proportion of people implementing it are more worried about > > clean system shutdown than they are about kdump. > The other important case is to get the device cleaned up enough to > pass back to firmware for platforms that use a firmware > shutdown/reboot path. Right, so the other cases I'm aware of are doing pretty much that - bringing things down to a state where the system can reboot cleanly. That can definitely include things like blocking for some hardware, and you're going to need some concurrency handling which means a combination of locking and infrequently tested lockless code paths. In the case of this specific driver I'm still not clear that the best thing isn't just to delete the shutdown callback and let any ongoing transfers complete, though I guess there'd be issues in kexec cases with long enough tansfers. --Vk4aO1eaTM88kUGw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmFbLFgACgkQJNaLcl1U h9CBKQf9GQ2KXuo+WmJK0ivezZx5gC5jF7VSvNRus+fKLGu5Uorq8FQ3ylrl1/pR 85lCQLPVoaHAzKbptULKGdqo4kp/Rz623GgSEHAbSazeq+jiO4Okp/BgcYr6swYT PU3xCob1clSWHd7TaUort5ObersVFAmy3egaELXdpDTy6o7/W1JmR5ikEDuEg5Us EWNn9h2oeYcqkbygqa+0yiA2/Z+UICUyv1ZI6GLGIAZqiWH/hLF2o0fxkKLDbMNw BjuDlgtc4FEn6fss/GojWqaHO+OSObdDFeJMckiBIEKW7IxHYOKOm6gVDc/2neFV sECi73OZzJz9snQva6F8G6ZZ+h9/bA== =3RQB -----END PGP SIGNATURE----- --Vk4aO1eaTM88kUGw-- --===============9012349873732383129== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============9012349873732383129==--