From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5092012FF69; Sat, 28 Jun 2025 09:58:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751104740; cv=none; b=cxcZZn1hgIwUIZprtHUTEY8m+GJ6z9IsU2KgjZ4VTru3S4nErGRT1Igj7CCMlWEapiuCo7oj9lHuUMQrIWTDmg3chFr120tO5DZ97pBflrasMKuciSliAq1of90N0bvPEMAYJsTeGsEudzQFiaNzMNlnUYC+HPHcHfsFTLfIEhA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751104740; c=relaxed/simple; bh=UN1stUXsni/d6TUJvZpDboqqcUYchqF9z6pjR6r2aIs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K7uluJwozXlZlHhG96ifxN3J8JXcMOl7X8zKDy74S9DMNt+v9OgOr/lF7PI7bLk/3Od7DU9kaVfIWiL2kBwZT3SP19+67ch844imAI+W9MQ5dKM4oOanKfYJsXP5pRgi10WdHNgJYjY/K3CmXqo25XcgAfaep4CgdEX97HtkwMo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E/RbxkOx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E/RbxkOx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E363C4CEEA; Sat, 28 Jun 2025 09:58:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751104739; bh=UN1stUXsni/d6TUJvZpDboqqcUYchqF9z6pjR6r2aIs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E/RbxkOx0QOABP4ujopxBsEo2wnU4pS8HTyKjBj3hdXAdQJ0xH/Eo17uCisCLDXod E6H7hnoAUDKTeEooRc+2NMJkyPqDCdhiLqAuncPhswj++/FcYVHGQHlOV08TE0WLGe TTPBIQOQyGq6/CtJ4kdU+IyXeaaK5666vDVS/P/fY41z2zpZWyMhnXF/UIPLoIAI/f wFNDyIiQJ0ooT7WiHXoEIRbGkAlST99DGOIWcvyqe0HvO5Yo54WDj237jWg5mdgUJS UynDuRu0LxQmS0pznCaWeccR73KaO0eO7GNe8p+cqfz0CbdlB5dIjWntlBuThT1LI/ MLZiIu6EQFX8A== Date: Sat, 28 Jun 2025 11:58:53 +0200 From: Danilo Krummrich To: Benno Lossin Cc: Boqun Feng , gregkh@linuxfoundation.org, rafael@kernel.org, ojeda@kernel.org, alex.gaynor@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu, david.m.ertman@intel.com, ira.weiny@intel.com, leon@kernel.org, kwilczynski@kernel.org, bhelgaas@google.com, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: [PATCH v4 5/5] rust: devres: implement register_release() Message-ID: References: <20250626200054.243480-1-dakr@kernel.org> <20250626200054.243480-6-dakr@kernel.org> Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Jun 28, 2025 at 09:53:06AM +0200, Benno Lossin wrote: > Hmm @Danilo, do you have any use-cases in mind or already done? There may be other use-cases, but the one that I could forsee is very specific: A Registration type that carries additional reference-counted data, where the Registration should be released exactly when the device is unbound, independent of the lifetime of the data. Obviously, this implies that the ForeignOwnable is an Arc. With KBox, Release and Drop are pretty much identical, so using devres::release() instead, is much simpler and hence what we do for all simple class device registrations. Besides that, the use-case described above can also be covered by Devres with the pin-init rework, by having the Registration embed a Devres, which is what irq::Registration does and I also do in the MiscDeviceRegistration patches. Hence, I already considered dropping this patch -- and I think we should do this for now.