From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f73.google.com (mail-ed1-f73.google.com [209.85.208.73]) (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 526EC1F3B87 for ; Mon, 16 Feb 2026 09:01:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771232469; cv=none; b=on67xPW2YLn3qEmbl8bND1GPUuQM37zLy7mtGTmXZZ8STKIdR+KTB2/AOclFDcR9qCRp0C5yPfuF2v5/bB/BzcAtMPnMlWhIinZNfRXhjTpg2Y1WpyF1UHt1G0tkHXokrsBKlpSItADVs/1swWZCdOiw4tvM8dWWRLyVejDVNtg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771232469; c=relaxed/simple; bh=uESNrQehw2PaWEb5/sJSYw2DgDRBw4jYVJ7Ut3+F63o=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=QihAS3fv2a5n2kZMAHlp7JlX8gVBZ/YqOERGvnoqRTgwpAX8e9StqIY+6lRcCZ7fA/dJuQW2P564FuNa899iHom/SsR2t+i21Cc3M6mJwAk11sIlE3tQ/mh+t8E3k1S0IKFbzntjfOTgML52/WqUN76advfp3mwIGvYcYq2eIEA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=S4JlMjjP; arc=none smtp.client-ip=209.85.208.73 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=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="S4JlMjjP" Received: by mail-ed1-f73.google.com with SMTP id 4fb4d7f45d1cf-65b9db0c150so2771184a12.1 for ; Mon, 16 Feb 2026 01:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771232467; x=1771837267; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=APVmnuexgYlYm9KOiPuEkrUPvIg2mrqcImpeCDaBBkU=; b=S4JlMjjPI5/Houu0bPDQwFgYLLL/CFKMyb6oRGckM8JGiRux7q2nzqtEufD/SlBn7+ XexdG2pd78XPNzYtgfI+cyla5bPWQWmrYx1f1Nq0WCsTeWW4VThttT8c4mtse2tYLQp1 0K3ZHLrGZIjZHSxVKY4833JjHjARWJfEQOUAnKrCNRoOaacS3xaY3ncJN+zYqyjEwC3o 1h6AFSEXtM+i5kNZ3G+EDZVoIloPXkQFQ3ibUGVf1rlUHjlvRPuDmn7bvUKgye3SEq3p 7PU3DeMYWaV6I/N7E1U4KT3sggvNHpMdAn9lvpBSbVVGVedIPru2pam2mBUWDZyjcbvx H5Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771232467; x=1771837267; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=APVmnuexgYlYm9KOiPuEkrUPvIg2mrqcImpeCDaBBkU=; b=Q2h5CjV6GO1YD/JqQF8MnABfN8/4O3T69cBLDjpy5dsSkPjdC1FdVhxH0b5QFbRF8q o5RZdZlb9iNF+hfNC8mXKvyfY++kU4gDtY4XNVbbZI6Q32Bdk0y1WKeq0SHhwjKQQFjH Y16p4QEPjhLDMOY3L18qjkqVjqBtdxEqbDu6/A9XYtnhK2Q72hrOc1ts3Ip7dJ+AIHCR o3ghD5JyEdopsuwL3aK91d8j1SGVyH9Jho9dZ7MST7iaTi/Ey22MHh/cTCHo4DO9PxUV EDLswaNxKVRlvmVgT25/7UvLdYXuE3CwX30i9NOJfsoBKxkHrnkOl11k4jKv7pNqlnIj kf0A== X-Forwarded-Encrypted: i=1; AJvYcCXZ8X4vJSVbt+SdAbnkpmNmCc3G5/WqaG8UFgFh/gY83gb++XZOzmnhNgh4IcFrL5D6SH4AgUfMQVWjExM=@vger.kernel.org X-Gm-Message-State: AOJu0YxE//XYPR4XuTTOszU/o+XBNlMRwR8QzifM/oa0L7vUiODaxGab Rh7VT4qNZ5+a17vzmUD0rAQMdCEf4lHkfQJIIGpCrrmgl/3Ad3pQAkbwWWXHuElHTnQKQ918a5x FJnvVnqrFjy4mW8bbbQ== X-Received: from edxf6.prod.google.com ([2002:a05:6402:14c6:b0:65b:9daa:35ad]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6402:2549:b0:65a:3f4b:947b with SMTP id 4fb4d7f45d1cf-65bb112f4fcmr4663313a12.15.1771232466462; Mon, 16 Feb 2026 01:01:06 -0800 (PST) Date: Mon, 16 Feb 2026 09:01:05 +0000 In-Reply-To: <20260216-register-v6-5-eec9a4de9e9e@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260216-register-v6-0-eec9a4de9e9e@nvidia.com> <20260216-register-v6-5-eec9a4de9e9e@nvidia.com> Message-ID: Subject: Re: [PATCH v6 5/9] rust: io: add IoRef and IoWrite types From: Alice Ryhl To: Alexandre Courbot Cc: Danilo Krummrich , Daniel Almeida , Miguel Ojeda , Gary Guo , "=?utf-8?B?QmrDtnJu?= Roy Baron" , Benno Lossin , Andreas Hindborg , Trevor Gross , Boqun Feng , Yury Norov , John Hubbard , Alistair Popple , Joel Fernandes , Timur Tabi , Edwin Peer , Eliot Courtney , Dirk Behme , Steven Price , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" On Mon, Feb 16, 2026 at 05:04:41PM +0900, Alexandre Courbot wrote: > I/O accesses are defined by the following properties: > > - For reads, a start address, a width, and a type to interpret the read > value as, > - For writes, the same as above, and a value to write. > > Introduce the `IoRef` trait, which allows implementing types to specify > the address a type expects to be accessed at, as well as the width of > the access, and the user-facing type used to perform the access. > > This allows read operations to be made generic with the `read` method > over an `IoRef` argument. > > Write operations need a value to write on top of the `IoRef`: fulfill > that purpose with the `IoWrite`, which is the combination of an `IoRef` > and a value of the type it expects. This allows write operations to be > made generic with the `write` method over a single `IoWrite` argument. > > The main purpose of these new entities is to allow register types to be > written using these generic `read` and `write` methods of `Io`. > > Co-developed-by: Gary Guo > Signed-off-by: Gary Guo > Signed-off-by: Alexandre Courbot > --- > rust/kernel/io.rs | 243 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 243 insertions(+) > > diff --git a/rust/kernel/io.rs b/rust/kernel/io.rs > index b150743ffa4f..6da8593f7858 100644 > --- a/rust/kernel/io.rs > +++ b/rust/kernel/io.rs > @@ -173,6 +173,160 @@ pub trait IoCapable { > unsafe fn io_write(&self, value: T, address: usize); > } > > +/// Reference to an I/O location, describing the offset, width, and return type of an access. In the next patch you implement this for usize, but here you say it's a reference to an I/O location. I'm pretty sure usize is not a reference to an I/O location. > +/// This trait is the key abstraction allowing [`Io::read`], [`Io::write`], and [`Io::update`] > +/// to work uniformly with both raw `usize` offsets (for primitive types like `u32`) and typed > +/// references. > +/// > +/// An `IoRef` carries three pieces of information: > +/// > +/// - The offset to access (returned by [`IoRef::offset`]), > +/// - The width of the access (determined by [`IoRef::IoType`]), > +/// - The type `T` in which data is returned or provided. > +/// > +/// `T` and `IoType` may differ: for instance, a typed register has `T` = the register type with > +/// its bitfields, and `IoType` = its backing primitive (e.g. `u32`), with `From`/`Into` > +/// conversions between them. > +/// > +/// An `IoRef` can be passed directly to [`Io::read`] or [`Io::try_read`] to obtain a value, or > +/// turned into an [`IoWrite`] via [`IoRef::set`] to be passed to [`Io::write`] or > +/// [`Io::try_write`]. > +pub trait IoRef: Copy > +where > + T: From + Into, Prefer to use Into for trait bounds: where T: Into, Self::IoType: Into, Alice