From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from luna.linkmauve.fr (luna.linkmauve.fr [82.65.109.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 532AA70810; Thu, 5 Feb 2026 12:48:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.65.109.163 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770295722; cv=none; b=o/Ub7ttehImdcYD2X4QU5EVQSCBMT6theQsvdWb/h/qZF9uJmyHOSmy6uuupxLCRBDnmpzi8x1u/3taL1fuBXlVJpM0ubde3zKa+7YCd109a6j+ByR+wiuwMWsbsTSq3Ehf7OKN5wEJbIkpx4IlfMIVRiLJ7e/QNtNlHQxnaD0o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770295722; c=relaxed/simple; bh=AKBciFw30Ysv8G9Jsg24H+1g4+BPM57sr3jlOLYi10k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RUBbedGPVAWQjskLu2POtq/jzcyiJElqd4xALtRdiy2NBEmeyNS4wcK6f/nIHwr2juqDccxea1Sg0TMYRu/Jr3b0mmV0Hdp2f1FZQaWVpEL3V+iCDjiYN/CBYaJn8v/hJMT7EDTa5ZZsu5gV8Ot+wDg3GhZL0E+OrF4ybWRmut8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linkmauve.fr; spf=pass smtp.mailfrom=linkmauve.fr; arc=none smtp.client-ip=82.65.109.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linkmauve.fr Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linkmauve.fr Received: by luna.linkmauve.fr (Postfix, from userid 1000) id D0AB5F43B46; Thu, 05 Feb 2026 13:48:32 +0100 (CET) Date: Thu, 5 Feb 2026 13:48:32 +0100 From: Link Mauve To: Danilo Krummrich Cc: Link Mauve , rust-for-linux@vger.kernel.org, Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Srinivas Kandagatla , Miguel Ojeda , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Daniel Almeida , Ard Biesheuvel , "Martin K. Petersen" , Eric Biggers , Greg Kroah-Hartman , Lyude Paul , Asahi Lina , Viresh Kumar , Lorenzo Stoakes , Tamir Duberstein , FUJITA Tomonori , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, officialTechflashYT@gmail.com, Ash Logan , Roberto Van Eeden , Jonathan =?iso-8859-1?Q?Neusch=E4fer?= Subject: Re: [PATCH v2 2/4] rust: nvmem: Add an abstraction for nvmem providers Message-ID: References: <20260204040505.8447-1-linkmauve@linkmauve.fr> <20260204040505.8447-3-linkmauve@linkmauve.fr> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Jabber-ID: linkmauve@linkmauve.fr On Wed, Feb 04, 2026 at 04:22:16PM +0100, Danilo Krummrich wrote: > On Wed Feb 4, 2026 at 5:04 AM CET, Link Mauve wrote: > > +impl Device { > > + /// Register a managed nvmem provider on the given device. > > + pub fn nvmem_register(&self, mut config: NvmemConfig, priv_: &T::Priv) > > + where > > + T: NvmemProvider + Default, > > + { > > + // FIXME: The last cast to mut indicates some unsoundness here. > > + config.inner.priv_ = core::ptr::from_ref(priv_).cast::().cast_mut(); > > + config.inner.dev = self.as_raw(); > > + config.inner.reg_read = Some(NvmemConfig::::reg_read); > > + config.inner.reg_write = Some(NvmemConfig::::reg_write); > > + // SAFETY: Both self and config can’t be null here, and should have the correct type. > > + unsafe { bindings::devm_nvmem_register(self.as_raw(), &config.inner) }; > > + } > > +} > > This should not be a method on the generic device type. Typically we use a > Registration struct for this, i.e. this would become > nvmem::Registration::register(). Should I also switch to the nvmem_register()/nvmem_unregister() API instead of the devm_nvmem_register() API, so that the unregister can happen in the Drop impl instead of being managed by the kernel? -- Link Mauve