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 04C653191BB; Tue, 24 Feb 2026 22:23:33 +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=1771971814; cv=none; b=mBbWmpfNb0Ct4PGyoPR+2nHa6hsDR5zaFyaEEj38vuQtqSzHLaiDJcywWpXjHM6yolJeFwl6ogMJRkKlDEaeKyov51TEAQNcwJyskh8trfD+vG1E9Q4KpmJQNQa3cxAhAFdOsp6u06ciRotcaRTyoLApDAQfi74ArlNGnbqn1a8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771971814; c=relaxed/simple; bh=J2fynfHOABkZGDgR4kc0ETezbHngS79q+9KgNVP7N6s=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=ETII9T3gnmo1iFC5vQFRj5jrRda7GvZOFVb+IgSNLHZHt0x/V2yhEjXtlB4a2t7vhjDyxiahAKFzIkACySbNKGC7dXce0B249oW7sH+v8lXuZoGBiJ7/nQEeCx6J4bKpIMaC61zz/HJXuYE0gUkxVskS8ZUftDUEGNEFttxNF0I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZP22ovgR; 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="ZP22ovgR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 009D7C116D0; Tue, 24 Feb 2026 22:23:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771971813; bh=J2fynfHOABkZGDgR4kc0ETezbHngS79q+9KgNVP7N6s=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=ZP22ovgRHWUDHxxqVR6LASqa4J5zTropMDPU6grqSoNkL7GK56V4dwpJLU6h/Jp9A SNcQgGgT9TtiGt1aTqgw6ff05kE6YhyN7za7jJBrb8MP929qJQuos70VU8ap+/pcKo nnLh5a/LXb3Z/7qMyevjx5uhWRFSk2zcIo5lnkpbgTnwenQXdGlvQFbZcOJBHxYztk jP/vkBeFdUZJZ/Mq3gKiTtTbuf1nJfJYYu31+rLRpANhROqfBIzJb4VyfG3dUQLJNU yrVZLx0urxsppXfoS2iEfgNpOjWiHH3W4kbGR0eSaCQDodzKxqn7ZFaJhiUVwuzY+2 CrgQhzj+wrXyQ== Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 24 Feb 2026 23:23:29 +0100 Message-Id: Subject: Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks Cc: "Rafael J. Wysocki" , "Alvin Sun" , "Miguel Ojeda" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , , , "Greg Kroah-Hartman" To: "Alexandre Belloni" From: "Danilo Krummrich" References: <20260221111619162a41a1@mail.local> <20260222000556ea1938c0@mail.local> <2026022415010804e28202@mail.local> <20260224172822de7f4569@mail.local> In-Reply-To: <20260224172822de7f4569@mail.local> On Tue Feb 24, 2026 at 6:28 PM CET, Alexandre Belloni wrote: > On 24/02/2026 17:35:23+0100, Danilo Krummrich wrote: >> (I did not have any specific hardware in mind when sketching this up (e.= g. an >> IRQ could also only be needed in bus device callbacks, e.g. for loading = firmware >> etc.). But for RTC it obviously is common that it is relevant to the cla= ss >> device too.) >>=20 >> So, I assume you mean because there could already be an ioctl before the= IRQ has >> been successfully registered, and this ioctl may wait for an IRQ? >>=20 >> In this case the irq::Registration should go into rtc_data instead to ac= count >> for this dependency. Unfortunately, this is a semantic dependency that w= e can't >> always catch at compile time. >>=20 >> The reason we sometimes can is because, if you would need access to the >> irq::Registration from ioctls (e.g. for calling synchronize(), enable(), >> disable() etc.) it would be caught, because you couldn't access it witho= ut it >> being in rtc_data in the first place, and being forced to have it in rtc= _data >> guarantees that the ordering can't be wrong. > > No, once you register the rtc, the character device will appear in > userspace and may be opened, at this point, probe is not allowed to fail > anymore which you are allowing by trying to register the IRQ so late. This does not seem to correspond to my previous reply -- may I kindly ask y= ou to read it again? Here's also some sketched up code for what I wrote above: fn probe(pdev: &pci::Device, info: &Self::IdInfo) -> impl PinInit { let dev =3D pdev.as_ref(); let rtc_data =3D impl_pin_init!(SampleRtcData { io: pdev.iomap_region_sized::(0, c"my_rtc/bar0")?, hw_variant: VendorVariant::StV1, irq <- irq::Registration::new(...), }); let rtc =3D rtc::Device::new(dev, rtc_data)?; rtc::Registration::register(rtc)?; Ok(Self { rtc }) } Note that if any of the RTC callbacks would ever need to call irq.synchroni= ze(), irq.disable(), etc. the compiler would enforce correct ordering, as there w= ould not be any other possibility to put the irq::Registration other than into t= he rtc_data that goes into rtc::Device::new(). Besides that, you above mentioned "probe is not allowed to fail anymore" af= ter the RTC device is registered and the corresponding character device becomes visible to userspace. While there most likely isn't any good reason for probe() to fail afterward= s for RTC devices, it is not the case that this isn't allowed. We generally can u= nwind from a class device registration. In fact, this is not different to remove(= ) being called (immediately). Imagine a case where a driver registers multiple class devices, or a class device and an auxiliary device, etc. (But I assume your point was more that for an RTC device specifically this = would be odd or uncommon.)