From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 36E411C01 for ; Sun, 22 Feb 2026 00:06:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771718774; cv=none; b=efRNnCYXke5jzjkkAJCTrGdZ2IPSM6if2TeJKztvIh+BNjGWEiMkQu1gQZfiEuwIy8X3sXgcxxmeKkf6it85mKxailBhQa9Z2DoUaKa1YESvihn5MfQBH4hJtHf3vFOLkU3sJwRTd0fspzQo6TlasD+qjQieeFJk5wruFHoI6vM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771718774; c=relaxed/simple; bh=Ah8lo4WZpBkjeZopq0IefC6nsaLNmX3a+jrUT83i3JQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fhxy/NgwysDnwEBWxs82dwaLm/eO+dpoNFnTpx5UwJIqtS3jRfX6jRD891FaP9XkKFUlMQrX2kpgOi/1LEfni7RSC1/TKlYdxC5cvurntP0wkCljDAT13i1tDjSOpHK+HSyDXxucIg2jSaDJhA9YTXUnvcB/96CZkS3snB8PLYE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=BauXhT9Q; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="BauXhT9Q" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 50B921A10C9; Sun, 22 Feb 2026 00:06:03 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 22CA25FB54; Sun, 22 Feb 2026 00:06:03 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id B02EB103684CE; Sun, 22 Feb 2026 01:05:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1771718762; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=W22sLyGdJ4g2zxHmS6kFaDnO3wQ9l1d2YFN5dAquDGk=; b=BauXhT9QmML3Wq1Yyyyc3k2XFP+BrMwuJqOEliKoNNYr/E0nQOjezEdRlBN8FIazUbrtgo 1fBHFIvd45hWs7n6uRv/eBOxaqy5+U4yaqge6uIK0Ld1jpaWHhLfLDgRIxVlqpPo3f7LH6 1MgA6P4qB8lehHmAKCE3W3IrfeXAQK14OSJhwlejI37N6SG6GJI5v6THwTr9cH7cwT0mTp 5goQPjYP1kyLPIPRqx9S8SWKDsnq0aJmKZCZPZd1xBmBV7Ihp686CIgbOwZbh8VYwYGsTC sX1sVV2EmbkHPxJBX3CXue0jpGX+a8ld0BInehbl4J9VjN671yjbHLEuXAnpcg== Date: Sun, 22 Feb 2026 01:05:56 +0100 From: Alexandre Belloni To: Danilo Krummrich Cc: "Rafael J. Wysocki" , Alvin Sun , Miguel Ojeda , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , linux-rtc@vger.kernel.org, rust-for-linux@vger.kernel.org, Greg Kroah-Hartman Subject: Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks Message-ID: <20260222000556ea1938c0@mail.local> References: <20260116162203.296844-1-sunke@kylinos.cn> <20260116162203.296844-2-sunke@kylinos.cn> <77d373dc-c5f2-4dca-b0d2-b5cee6a21b3b@gmail.com> <20260220225341c5eeb835@mail.local> <20260221111619162a41a1@mail.local> 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: X-Last-TLS-Session-Version: TLSv1.3 On 21/02/2026 15:33:48+0100, Danilo Krummrich wrote: > On Sat Feb 21, 2026 at 12:19 PM CET, Rafael J. Wysocki wrote: > > On Sat, Feb 21, 2026 at 12:16 PM Alexandre Belloni > > wrote: > >> > > Out of 29 drivers, 18 are doing so. > > > > The vast majority of around 50 platform drivers I've inspected > > recently use platform_set_drvdata() or equivalent in probe. > > This thread seems to contain quite a bit of confusion and misunderstandings -- > let me try to clarify. > > (1) How Rust handles bus device private data. > > In Rust the probe() function of a bus implementation (platform, PCI, etc.) > returns an initializer (impl PinInit) for the driver's device > private data. > > The bus implementation takes this initializer and passes it (together with the > underlying struct device) to the driver-core. The driver-core allocates the > required memory, initializes the memory with the given initializer and stores > a pointer to the corresponding object with dev_set_drvdata(). > > So, technically, in Rust all platform drivers call platform_set_drvdata(). > > (Note that this is also true when the driver's device private data type is > empty (i.e. it has no fields). In this case it could still have a destructor > that must be called when the device private data structure is destroyed. Of > course there is no real memory allocation when the struct's size is zero.) > > The driver's device private data can only be accessed when the bus device is > bound to the driver, i.e. the driver can only access it with a &Device; > it (the driver's device private data) is automatically freed by the > driver-core when remove() and all devres callbacks have been completed. > > I.e. the rules are - of course - the same as on the C side, but they are > enforced by the type system and the driver-core code. > This still doesn't explain how you get the class private data that you need when you are in a driver callback that is called from the bus (e.g. suspend/resume) from what you explain, the driver doesn't have any chance to pass it. The whole goal of a device driver is to be the glue between a class device and a bus device as essentially this is the exact physical device, just represented differently. An i2c RTC is not either an i2c device or an RTC, it is a single device and we need to be able to tell the framework when something happens on the bus or we need to be able to talk on the bus when we want to do something with the device. > (2) Bus device private data vs. class device private data. > > The change to pass a struct rtc_device in class device callbacks of RTC, > rather than the base struct device of the corresponding bus device (e.g. AMBA, > platform, etc.) should not aim at storing all data in rtc->dev.private_data > that was previously stored in rtc->dev.parent->private_data. > But what you explain here is that the drive is forbidden to use rtc->dev.parent->private_data at all because the rust core is already using it. What I'm saying is that it won't work because more than half of the drivers currently need it. I get that you are trying to avoid most of the issues by using devres but I'm pretty sure there are cases where this doesn't work. > Instead, it gives drivers the option to differentiate in terms of ownership > and lifetime. > > While the bus device private data has a very defined lifetime from probe() > until the device is unbound from the driver, class device private data might > live shorter than this, or might even out-live driver unbind in some cases. It > really depends on the lifetime of the class device itself, which is not > generally defined. > > Now, from a C side point of view this may not look like a big deal, as it > (unfortunately) is not that uncommon that struct fields are just initialized > and destroyed whenever needed and the code just takes it into account. > > But at the same time, this is what leads to a lot of lifetime problems and > memory bugs and it is one of those things that Rust aims at avoiding by being > very strict about initialization, ownership and lifetimes. > > However, I do also recognize that drivers creating an RTC device are typically > very simple and in practice I would not be surprised if it turns out that it > happens that drivers keep the struct rtc_device alive from probe() until the > bus device is unbound from the driver, i.e. lifetimes just end up being almost > the same. But I don't know if that's always the case. > > Regardless of that, I think it would be good to keep driver authors finding a > common pattern, where class device callbacks carry the corresponding class > device struct (instead of the parent base struct device). > > Especially on the Rust side we now have the chance to make the experience of > writing drivers as consistent as possible, which should help (new) driver > authors a lot in terms of learning the driver lifetime patterns. > The whole point of the RTC is to outlive the system but as Linux can't do anything with the RTC unless it has a bus device to talk to, the class device and the bus device have the exact same lifetime and we do handle device appearing and disappearing from the bus. You may think RTC drivers afe simple but there are plenty of lifetime issues that you will never get with any other devices because they simply die with the system. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com