rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: bhelgaas@google.com, 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,
	linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/4] rust: device: implement Device::parent()
Date: Fri, 21 Mar 2025 14:03:30 +0100	[thread overview]
Message-ID: <Z91joggxxBh3e0d8@pollux> (raw)
In-Reply-To: <Z90rlKC_S5WQzO8P@pollux>

On Fri, Mar 21, 2025 at 10:04:26AM +0100, Danilo Krummrich wrote:
> On Thu, Mar 20, 2025 at 06:40:56PM -0700, Greg KH wrote:
> > On Thu, Mar 20, 2025 at 11:27:43PM +0100, Danilo Krummrich wrote:
> > > Device::parent() returns a reference to the device' parent device, if
> > > any.
> > 
> > Ok, but why?  You don't use it in this series, or did I miss it?
> 
> Indeed, it should rather be at the auxbus series.
> 
> > A driver shouldn't care about the parent of a device, as it shouldn't
> > really know what it is.  So what is this needed for?
> 
> Generally, that's true. I use in the auxbus example and in nova-drm [1] (which
> is connected through the auxbus to nova-core) to gather some information about
> the device managed by nova-core.
> 
> Later on, since that's surely not enough, we'll have an interface to nova-core
> that takes the corresponding auxiliary device. nova-core can then check whether
> the given device originates from nova-core, and through the parent find its own
> device.
> 
> [1] https://gitlab.freedesktop.org/drm/nova/-/blob/staging/nova-drm/drivers/gpu/drm/nova/driver.rs

Another category of drivers that came to my mind and seems valid for this is
MFD.

Other than that I found a couple of cases where platform drivers interact with
their corresponding parent devices (mostly embedded platforms where the topology
is known), as well as a couple of HID devices that access their parent to issue
USB transactions etc., which all seems more like an abuse due to a lack of
proper APIs, which may or may not exist at the time the corresponding driver was
written.

So, maybe we should make Device::parent() crate private instead, such that it
can't be accessed by drivers, but only the core abstractions and instead only
provide accessors for the parent device for specific bus devices, where this is
reasonable to be used by drivers, e.g. auxiliary.

  reply	other threads:[~2025-03-21 13:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-20 22:27 [PATCH v2 0/4] Implement TryFrom<&Device> for bus specific devices Danilo Krummrich
2025-03-20 22:27 ` [PATCH v2 1/4] rust: device: implement Device::parent() Danilo Krummrich
2025-03-20 22:44   ` Benno Lossin
2025-03-20 23:46     ` Danilo Krummrich
2025-03-21  1:40   ` Greg KH
2025-03-21  9:04     ` Danilo Krummrich
2025-03-21 13:03       ` Danilo Krummrich [this message]
2025-03-21 13:09         ` Greg KH
2025-03-21 14:16           ` Danilo Krummrich
2025-03-21 14:40   ` Boqun Feng
2025-03-21 14:46     ` Danilo Krummrich
2025-03-20 22:27 ` [PATCH v2 2/4] rust: device: implement bus_type_raw() Danilo Krummrich
2025-03-20 22:55   ` Benno Lossin
2025-03-20 22:27 ` [PATCH v2 3/4] rust: pci: impl TryFrom<&Device> for &pci::Device Danilo Krummrich
2025-03-20 23:44   ` Benno Lossin
2025-03-20 23:48     ` Danilo Krummrich
2025-03-21 16:56   ` kernel test robot
2025-03-21 17:44     ` Danilo Krummrich
2025-03-21 18:59       ` Miguel Ojeda
2025-03-21 19:11         ` Danilo Krummrich
2025-03-21 19:37           ` Miguel Ojeda
2025-03-22 10:08     ` Benno Lossin
2025-03-20 22:27 ` [PATCH v2 4/4] rust: platform: impl TryFrom<&Device> for &platform::Device Danilo Krummrich
2025-03-20 23:44   ` Benno Lossin

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=Z91joggxxBh3e0d8@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=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).