linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Markus Probst" <markus.probst@posteo.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc: "Rob Herring" <robh@kernel.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Kari Argillander" <kari.argillander@gmail.com>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	rust-for-linux@vger.kernel.org
Subject: Re: [PATCH RFC 1/4] serdev: Export internal is_serdev_device() for drivers
Date: Sun, 21 Dec 2025 18:36:23 +0100	[thread overview]
Message-ID: <DF42RR0I52L3.1JET4R0KFDPPH@kernel.org> (raw)
In-Reply-To: <4b55501e500edb8416ed690757f72752f1c49517.camel@posteo.de>

On Sun Dec 21, 2025 at 5:28 PM CET, Markus Probst wrote:
> On Sun, 2025-12-21 at 17:10 +0100, Greg Kroah-Hartman wrote:
>> Yes, and usually that's not a good idea, unless you have a bus with
>> multiple types of devices on it.  I don't think serdev has that, does
>> it?
>> 
>> Only under special circumstances should this be required, so I'm curious
>> as to why you would ever have a pointer to a struct device and not
>> "know" that it is of this type?  Who is passing that to you?
> For example, the pwm rust abstraction currently only provides a
> `device::Device<device::Bound>` reference in callbacks [1]. If we want
> to write data to the serial device in one of the pwm callbacks, we need
> to convert the `device::Device<device::Bound>` reference to
> `serdev::Device<device::Bound>`. The TryFrom implementation provides a
> *safe* abstraction.
>
> At least in the pwm example, this could/should be circumvented with the
> `AsBusDevice` trait [2].

Yes, class device implementations should start using AsBusDevice, so you don't
need the TryFrom upcast.

> But this technically also applies to all other bus device abstractions
> and they also have a `TryFrom<&device::Device<Ctx>>` implementation, so
> with this it would be consistent across all rust bus device
> abstractions.

It should only be PCI and platform and they have it for a reason ()which is the
one Greg already mentioned, i.e. when you potentially have multiple device types
on a bus).

The concrete use-case that motivated adding those for PCI and platform is when
they interact with the auxiliary bus: Imagine a driver that supports devices
from the platform bus and the PCI bus and exports an auxiliary device.

In this case, when you call back into the parent driver from the auxiliary
device the parent driver has to upcast.

This exact constellation is what is implemented by nova-core and nova-drm.

However, outside of such a constellation we should avoid doing upcasts with
TryFrom and make the correct type available in the first place.

- Danilo

  parent reply	other threads:[~2025-12-21 17:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-20 18:44 [PATCH RFC 0/4] rust: add basic serial device bus abstractions Markus Probst
2025-12-20 18:44 ` [PATCH RFC 1/4] serdev: Export internal is_serdev_device() for drivers Markus Probst
2025-12-21 16:10   ` Greg Kroah-Hartman
2025-12-21 16:28     ` Markus Probst
2025-12-21 16:46       ` Greg Kroah-Hartman
2025-12-21 17:36       ` Danilo Krummrich [this message]
2025-12-21 17:40   ` Danilo Krummrich
2025-12-20 18:44 ` [PATCH RFC 2/4] rust: add basic serial device bus abstractions Markus Probst
2025-12-21  9:19   ` Dirk Behme
2025-12-21 12:41     ` Markus Probst
2025-12-25 15:13   ` Kari Argillander
2025-12-26 15:09   ` Kari Argillander
2025-12-20 18:44 ` [PATCH RFC 3/4] samples: rust: add Rust serial device bus sample device driver Markus Probst
2025-12-21  9:11   ` Dirk Behme
2025-12-21 12:39     ` Markus Probst
2025-12-20 18:44 ` [PATCH RFC 4/4] rust: Add serdev rust abstractions to MAINTAINERS file Markus Probst

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=DF42RR0I52L3.1JET4R0KFDPPH@kernel.org \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=kari.argillander@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=markus.probst@posteo.de \
    --cc=ojeda@kernel.org \
    --cc=robh@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).