Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp4420619pxy; Tue, 27 Apr 2021 04:50:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwOM5zgZlqK29duY9BfVLYhKmxOLUhGbtiKzj9PVPPR6AguITKrBl/aVNMxM2O+J8asYDMB X-Received: by 2002:a17:90b:4c4f:: with SMTP id np15mr26292270pjb.191.1619524235401; Tue, 27 Apr 2021 04:50:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619524235; cv=none; d=google.com; s=arc-20160816; b=SpBLrOlDhx+pz2s6cSTch1SuvTRorhfXSIrmtvnshm/yM9GcSOOATkPFmOcax1pt3h e2+50iyqG6xNVPUrXAt/r3uG+T6AX7QsGSZNUAaXMLf7clioWVOP6Js1BkiE+/8CWrf+ P8W1kB565PNYeO6vjJDxX2Qn8LmEpOtb6Ez75QIWjogdDiMIm0mbWPjrS4wmj+/gDgdv oBiBGETlNfG2mvJ4nNXmSh0et6UIROHkGKp9u0I54MNBmDCsItdZPSbofvh4uSlesdMl ef2yy5arUrJEEved6qqXSIX0LOVlcqkg8hzPi7PbJMKFbB6VUNaVUeBQJ+gpTMnw8bzc XV0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=lOU7cCIEsWaSCcuHtLCtVk4l2Rux+KhvoNGDKIj9GfI=; b=i09+27o77wWVNsy92oTkeupNwV5Iqm13+T53zqMbk36pQ2U6ENBR1ZtrQ2U8HqDiK1 UDMtLtWqambyt/bHwca+1X2buIMESUIr9+jbcY3rNf9LSF6O7EVEE1Z2hBXJ11cSEClX RBPiiZs3b4ne6aD9PAHESsmlMknwR1u4IlLsTHxZsoIiwzJx/Frn5dMXGxCTDXp6cDES TF7ZyveuFyEVGSTAs+YW+0fiG4XDN1piMQaJJgBAOVOQmtKN2eKDElPGtOpxAygSiozr 5IaMHlsDXGNdtxS+n9lmcNu1lY/8dkNBnnUPUZVm2ZcCTbkf3OBaEwa+lXywXMp/rN8q eR6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=iRUjblZu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w12si21681702pgr.391.2021.04.27.04.50.22; Tue, 27 Apr 2021 04:50:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=iRUjblZu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235428AbhD0Luc (ORCPT + 99 others); Tue, 27 Apr 2021 07:50:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:55962 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230365AbhD0Lub (ORCPT ); Tue, 27 Apr 2021 07:50:31 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D293361002; Tue, 27 Apr 2021 11:49:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1619524188; bh=VX3HwOn8sTx95Uhi2Qyewuwpq9p8vfQOXdkqnYEe10g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iRUjblZuePo0P0vVslJrRyKvz6Jy74fvqhEqjyB2dz+SKs71DH9sBEkfPFuj/tFQf uJHEp0vrHCH4nIhQxtHr/r3o+SgjlDqzeHX7bn9F+XDE+H5Fld/ZzxJEO8CjYqdTEU BB1bXivp4Fdra39fgEX6/2GGdBmKhnHEWB2KNAag= Date: Tue, 27 Apr 2021 13:49:45 +0200 From: Greg Kroah-Hartman To: Andy Shevchenko Cc: Mark Brown , Saravana Kannan , Lukas Wunner , "Rafael J. Wysocki" , Guenter Roeck , Marek Szyprowski , Android Kernel Team , linux-spi , Linux Kernel Mailing List Subject: Re: [PATCH] spi: Fix spi device unregister flow Message-ID: References: <20210426235638.1285530-1-saravanak@google.com> <20210427104851.GC4605@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 27, 2021 at 02:42:19PM +0300, Andy Shevchenko wrote: > On Tue, Apr 27, 2021 at 1:49 PM Mark Brown wrote: > > > > On Tue, Apr 27, 2021 at 09:52:48AM +0300, Andy Shevchenko wrote: > > > +Cc Lukas > > > > The cleanup callback has been in release() since the framework was > > merged AFAICT. > > Yep. > > Personally it feels to me wrong to require device_release() being > atomic. It might be that I missed something in documentation or > somewhere else that suggests the opposite. > But let's wait for other comments if any. There is no requirement from the driver core to have the release callback be "atomic", you should be able to sleep just fine in there. If not, something is wrong and has changed... thanks, greg k-h