All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: rafael@kernel.org, ojeda@kernel.org, alex.gaynor@gmail.com,
	boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com,
	benno.lossin@proton.me, a.hindborg@kernel.org,
	aliceryhl@google.com, tmgross@umich.edu,
	david.m.ertman@intel.com, ira.weiny@intel.com, leon@kernel.org,
	kwilczynski@kernel.org, bhelgaas@google.com,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 1/8] rust: device: introduce device::Internal
Date: Tue, 1 Jul 2025 12:41:47 +0200	[thread overview]
Message-ID: <aGO7a3dsRdcjdBnb@pollux> (raw)
In-Reply-To: <2025070110-renounce-blinks-b28f@gregkh>

On Tue, Jul 01, 2025 at 11:26:47AM +0200, Greg KH wrote:
> On Sat, Jun 21, 2025 at 09:43:27PM +0200, Danilo Krummrich wrote:
> > Introduce an internal device context, which is semantically equivalent
> > to the Core device context, but reserved for bus abstractions.
> > 
> > This allows implementing methods for the Device type, which are limited
> > to be used within the core context of bus abstractions, i.e. restrict
> > the availability for drivers.
> > 
> > Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> > ---
> >  rust/kernel/device.rs | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/rust/kernel/device.rs b/rust/kernel/device.rs
> > index 665f5ceadecc..e9094d8322d5 100644
> > --- a/rust/kernel/device.rs
> > +++ b/rust/kernel/device.rs
> > @@ -261,6 +261,10 @@ pub trait DeviceContext: private::Sealed {}
> >  /// any of the bus callbacks, such as `probe()`.
> >  pub struct Core;
> >  
> > +/// Semantically the same as [`Core`] but reserved for internal usage of the corresponding bus
> > +/// abstraction.
> > +pub struct Internal;
> 
> Naming is hard :)
> 
> As this is ONLY for the bus code to touch, why not call it Bus_Internal?

BusInternal is better indeed!

> And can a driver touch this, or only the bus owner?

It is to prevent drivers from getting access to functions implemented for
&Device<BusInternal>.

  reply	other threads:[~2025-07-01 10:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-21 19:43 [PATCH 0/8] Device: generic accessors for drvdata + Driver::unbind() Danilo Krummrich
2025-06-21 19:43 ` [PATCH 1/8] rust: device: introduce device::Internal Danilo Krummrich
2025-07-01  9:26   ` Greg KH
2025-07-01 10:41     ` Danilo Krummrich [this message]
2025-07-01 12:32       ` Danilo Krummrich
2025-07-03 15:06         ` Greg KH
2025-06-21 19:43 ` [PATCH 2/8] rust: device: add drvdata accessors Danilo Krummrich
2025-07-01  9:27   ` Greg KH
2025-07-01 10:58     ` Danilo Krummrich
2025-07-01 13:12       ` Danilo Krummrich
2025-07-05 11:15   ` Benno Lossin
2025-07-05 15:06     ` Danilo Krummrich
2025-07-05 21:38       ` Benno Lossin
2025-07-07  7:46   ` Alexandre Courbot
2025-07-07  9:40     ` Danilo Krummrich
2025-06-21 19:43 ` [PATCH 3/8] rust: platform: use generic device " Danilo Krummrich
2025-06-21 19:43 ` [PATCH 4/8] rust: pci: " Danilo Krummrich
2025-07-01  9:30   ` Greg KH
2025-06-21 19:43 ` [PATCH 5/8] rust: auxiliary: " Danilo Krummrich
2025-06-21 19:43 ` [PATCH 6/8] rust: platform: implement Driver::unbind() Danilo Krummrich
2025-06-21 19:43 ` [PATCH 7/8] rust: pci: " Danilo Krummrich
2025-06-21 19:43 ` [PATCH 8/8] samples: rust: pci: reset pci-testdev in unbind() Danilo Krummrich
2025-07-01  9:25 ` [PATCH 0/8] Device: generic accessors for drvdata + Driver::unbind() Greg KH
2025-07-01 10:40   ` Danilo Krummrich
2025-07-07  7:18     ` Alexandre Courbot
2025-07-07  9:26       ` Danilo Krummrich
2025-07-08 22:25 ` Danilo Krummrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aGO7a3dsRdcjdBnb@pollux \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=david.m.ertman@intel.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=ira.weiny@intel.com \
    --cc=kwilczynski@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.