From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 ECC0DBA36 for ; Mon, 21 Jul 2025 19:33:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753126428; cv=none; b=Y/e97N2EKR+/bQB0P/kQWgF2NGWZg4a1p8aiITlK2jEIzUQ600mVfU+sDeOPKInSeeBppu5Y06Fmg2yJo+SjpKI+bpYtyYdNoE7P7qzrivC9ekpIyLu6+hzhmnLDdZ8XTTyr9mPu3MPTmOPUQEC01xT3/iIfX5MRKRU/iajQU1I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753126428; c=relaxed/simple; bh=b0Br9Ks6fXh5lsh6KkvcovDZWilidwwTqtBK+nHUNLI=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mlQKSNy5YC05dQ+2J6c+cbt51DM912Pxh+gKUqhPxo0OkOSDsusbO0T/AHwd0QvUXAtMt5iZ89H2qRsPR0keHAryhgR/m5zqvMZF0EZAC89aoNYKzhNzumSV8vwEVj+nLkj+HIyo06ozhHR4M9lwOubjmA9VwIN3T4qsQ9V1onU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=tmRs6/gS; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="tmRs6/gS" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4561ca74829so52027645e9.0 for ; Mon, 21 Jul 2025 12:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1753126425; x=1753731225; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HBrX1LhQ4C9q6FY08bFZ+5XkQcWo67qB3JLKdiHTV0U=; b=tmRs6/gSRQIKKgplNVfb9rW3B9zbsYsipI0QPcT1Fw2Nb+DUGUzU3JKmNxlaqBmPn5 zAK8UmB1zIaP9Gz9Jz2fbjt3allkZwFDBX4TFNjPW3ZQsfNTdnMHC05WfSezfhKdcAfY SkC8pjVdBRV9mT8uEzCWVxl+mLIbRGtFLBWiYOHGQXyum7NntsUHin9oTXpIVI9slFAi cGjd1QG2hxDMoxhNnuLcTkrAo9rTEVCAayg+7bcSwoJtZBIrQP4FJVytG9HDVKKjT9D8 RibmBH/IFpk6SRTf9imJ3i1VlSoOlBJShU3FBL7aTiVpcA85vCgbiF1CMZdZXYt6nbh3 R2Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753126425; x=1753731225; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HBrX1LhQ4C9q6FY08bFZ+5XkQcWo67qB3JLKdiHTV0U=; b=gbpo57J4rKtxFzXD8SmFya2P3wuAg2+wZGRriuKfoZ4Ffv/9DElaJhYLu0SHtkBzdU cxJE1mkZUXOZ/5X02AHFyj97wcqs30StkjZm1FGNp5dhfhxWahJtBAH3LUvV/iYqSOB9 NxRL24lLtx+83C1dOK1jHwXU1GMK2NkTIMd4kVnLkQzxobBUScsJm02hYgZT9PS6DTKY SI3x4BazJpAUrlqb17NiyjoG+/UxhNc8pZ5FK28eJS7CD9B3Hfhs0TGSqFUQ8psRT76G v3awdmxWNvuUZeaFRaSHhi3rQJlrvwCJSgkAGSzt0O3OOMJ6YhBvQ2uLF31/kZUsnHpn ZXEA== X-Forwarded-Encrypted: i=1; AJvYcCUc9m+Tpz/9Owqzz/RQtiIH6j58DAtLpv3e4k77OL26ZtJRSiJeFiItLRocx1P5yxNEfVjwhAl8tcSGcVeEow==@vger.kernel.org X-Gm-Message-State: AOJu0YzwIgxnENulv5c2D2hXqZ0fcT9BrZQXvVaexR/HXd9CHUAR4NJf avbk0LaI2HaNmz7btv7OcRAGY31xd+8UKxDQTdfWUqHsP0QWoHCiuBGEi6f+DzwkmlGDBqLrLkV YX7jGdqR5cqrqWBoVwRIdVXeOLfSwaOqnNzvOvM8W X-Gm-Gg: ASbGncuHVqhvI7x+wUBHvmp9KX8Cl/XaRuL/TBgkbY6Eav+WQ8go6eszL3BF84Q3caf yKF5KOmO4P4rE+Amhkc0d0Lyv3kA6aGAmxnraByD6S+BtSo/fU65RV0c/ugbe9JYNh4J9xtuLLB ooE1leatKIR++F/c3Yl7QTb9RAaHH6mvr72rRvgvowAG0QN7Oy1sWjE84XvAESPB2O6pMoIvTVG N3od8za X-Google-Smtp-Source: AGHT+IGNspYtBPncBdW3w/SsuWiBzoraM8UjDYrcQv9P+WyMTcNLgDlaVPcW5XrC7nb2ZAo4MrVL17F2FHDqTh3VVdA= X-Received: by 2002:a05:6000:4804:b0:3a4:e5fa:73f0 with SMTP id ffacd0b85a97d-3b60e4d5533mr15467594f8f.20.1753126425187; Mon, 21 Jul 2025 12:33:45 -0700 (PDT) Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250721-irq-bound-device-v1-1-4fb2af418a63@google.com> In-Reply-To: From: Alice Ryhl Date: Mon, 21 Jul 2025 21:33:32 +0200 X-Gm-Features: Ac12FXz3PAqla3h6HMW15ltSgos8jwB8mwZW-LrpptSGLIfz_bq8PvUKZkNYscI Message-ID: Subject: Re: [PATCH] rust: irq: add &Device argument to irq callbacks To: Daniel Almeida Cc: Miguel Ojeda , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Greg Kroah-Hartman , "Rafael J. Wysocki" , Thomas Gleixner , Bjorn Helgaas , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Benno Lossin , Dirk Behme , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-pci@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2025 at 9:14=E2=80=AFPM Daniel Almeida wrote: > > Alice, > > > On 21 Jul 2025, at 11:38, Alice Ryhl wrote: > > > > When working with a bus device, many operations are only possible while > > the device is still bound. The &Device type represents a proof i= n > > the type system that you are in a scope where the device is guaranteed > > to still be bound. Since we deregister irq callbacks when unbinding a > > device, if an irq callback is running, that implies that the device has > > not yet been unbound. > > > > To allow drivers to take advantage of that, add an additional argument > > to irq callbacks. > > > > Signed-off-by: Alice Ryhl > > --- > > This patch is a follow-up to Daniel's irq series [1] that adds a > > &Device argument to all irq callbacks. This allows you to use > > operations that are only safe on a bound device inside an irq callback. > > > > The patch is otherwise based on top of driver-core-next. > > > > [1]: https://lore.kernel.org/r/20250715-topics-tyr-request_irq2-v7-0-d4= 69c0f37c07@collabora.com > > I am having a hard time applying this locally. Your irq series currently doesn't apply cleanly on top of driver-core-next and requires resolving a minor conflict. You can find the commits here: https://github.com/Darksonn/linux/commits/sent/20250721-irq-bound-device-c9= fdbfdd8cd9-v1/ > > /// > > /// This function should be only used as the callback in `request_irq`. > > unsafe extern "C" fn handle_irq_callback(_irq: i32, ptr: *m= ut c_void) -> c_uint { > > - // SAFETY: `ptr` is a pointer to T set in `Registration::new` > > - let handler =3D unsafe { &*(ptr as *const T) }; > > - T::handle(handler) as c_uint > > + // SAFETY: `ptr` is a pointer to `Registration` set in `Registr= ation::new` > > + let registration =3D unsafe { &*(ptr as *const Registration) }; > > + // SAFETY: The irq callback is removed before the device is unboun= d, so the fact that the irq > > + // callback is running implies that the device has not yet been un= bound. > > + let device =3D unsafe { registration.inner.device().as_bound() }; > > Where was this function introduced? i.e. I am missing the change that bro= ught > in RegistrationInner::device(), or maybe some Deref impl that would make = this > possible? In this series: https://lore.kernel.org/all/20250713182737.64448-2-dakr@kernel.org/ > Also, I wonder if we can't make the scope of this unsafe block smaller? I guess we could with an extra `let` statement. Alice