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 CBC1EC433F5 for ; Mon, 4 Oct 2021 15:47:02 +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 9D93A610A2 for ; Mon, 4 Oct 2021 15:47:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9D93A610A2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca 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-Transfer-Encoding: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-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Os9d6XSbZkZKRep1N3aKDzTrwXf1KUJ1O7sG0q/bz4U=; b=CGk/fDrXp/sgLy kQ0Fq3Fyk1UcvHoEb/gMfJd5sVDqcCsipB9D5aCszkhm3DTTvISpccd81CvX4eVTilmuUO7LVA9bg AxOBETG8WDZmrK2Juwjd/eoiy6MONodM3h7Ylh9QKvFXepON9psjSJN02we1YrnWMPKEARBy03Lvv V4vH0kEngGehYIB/1JUxO/mvsSZENIm+SiRW3Mme189P17AZjmf20iBO6jN6MaHzC/IX2O0nqsVeQ Au3epM/MmJ2aAAOWPre3eoONJuXf1wRH7EtSwQkrmbYCyzSypxFdCJAB6U17YlHhWbE0puy4p+Mv2 hLRamJ+MzAE0e8BWNrJQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mXQ8x-006xE3-EC; Mon, 04 Oct 2021 15:44:43 +0000 Received: from mail-qk1-x72c.google.com ([2607:f8b0:4864:20::72c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mXQ8s-006xCK-UB for linux-arm-kernel@lists.infradead.org; Mon, 04 Oct 2021 15:44:41 +0000 Received: by mail-qk1-x72c.google.com with SMTP id b65so16830519qkc.13 for ; Mon, 04 Oct 2021 08:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=0/aP63vy196i8qH5aGLzYmPHF4Nnb+LayDyFtr1MXMg=; b=FrrVaLmatO49LvYV8N9t8dOdbGVBJR3uVBoq9V1WS6cSj2Cb1rm4irSPU637X3Eyv9 XYle6u16GK8tqSmcZsxSml+QoQhROr2ixOlYw/HLYJ0moUkyLT+ARSKEyFM4P2Vf2aVZ bHQ5rlQcKN7lXDC26PuHAyymZGCME2n3eKQruQF7BGnnssj52apDsqZ47vaw7CneEVj0 FbmRF1DEjIiJ6n+vrG4P3iETCVLbIN9IA29e3wqYeJm8Q7sCRb8NuFBkaHIhfa0kgUe7 OTTt++eukDUH5MZyWsRhjylFCBO9ap9F9k0d6VFXYGnSLUhrgW/TGUYiQYgBmpTnuwrV 3xsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=0/aP63vy196i8qH5aGLzYmPHF4Nnb+LayDyFtr1MXMg=; b=YCoHgdR+Q6CGhPnPOguK6LS7ui6UGxE2MAhmfZUHtAoRgmXaAm4WNFUXfr/ShS9fnJ f8R+a5sFpERZaf0gQWsLw+uJMrEL9F1pPu8HrHfqemGBTaW1ivB/jZn+up5d6sM6vZiQ Q1YV9mMZksBoNXigjalylwzrK8gwHtuPw9viBH/DYvLorqCh4Gd+muPHm9UMf74Xrrtg RJX+0x2M69YHrvLPEV0LWWm3Cx+oaP/7LQH1SH+EpdX6Bl8ZFvWI0SIdrIXTgHbGoOnl LNCCpHAdlCf5MDoT3g7ON99uLX+O3XxvXHNOYzoQF5911VsSQqGLieukXLuJNRedArAV gnnA== X-Gm-Message-State: AOAM533hcmD0KHe0MfgjUftXYKep9vsQmy61BXnQ53GjbqQwQopl+9mZ 1FjGJKlVMFRlHwc+8AxUNnvmUw== X-Google-Smtp-Source: ABdhPJzmrnxoimB1jf2ei4cUIinalbPGsZ26WCIenMwLucficq046xW8YP3iE+lNnoSolu8XpL/UpQ== X-Received: by 2002:a37:670d:: with SMTP id b13mr10467091qkc.420.1633362277573; Mon, 04 Oct 2021 08:44:37 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id h66sm7850926qkc.5.2021.10.04.08.44.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Oct 2021 08:44:36 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1mXQ8q-00AW43-2f; Mon, 04 Oct 2021 12:44:36 -0300 Date: Mon, 4 Oct 2021 12:44:36 -0300 From: Jason Gunthorpe To: Mark Brown 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: <20211004154436.GY3544071@ziepe.ca> References: <20210928195657.5573-1-LinoSanfilippo@gmx.de> <20211001175422.GA53652@sirena.org.uk> <2c4d7115-7a02-f79e-c91b-3c2dd54051b2@gmx.de> <20211004131756.GW3544071@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211004_084439_053902_1D056BC9 X-CRM114-Status: GOOD ( 23.04 ) 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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: > > > Shutdown is supposed to quiet the HW so it is not doing DMAs any > > more. This is basically an 'emergency' kind of path, the HW should be > > violently stopped if available - ie clearing the bus master bits on > > PCI, for instance. > > > 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. 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. > > 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) - Drivers mis understanding stuff is not new.. > 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. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel