linux-kernel - Re: [PATCH RFC 2/4] rust: add basic serial device bus abstractions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <DFNP6FEZ0S1O.1MQGAXEGX1P7@kernel.org>
Date: Tue, 13 Jan 2026 20:10:37 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Markus Probst" <markus.probst@...teo.de>
Cc: "Kari Argillander" <kari.argillander@...il.com>, "Rob Herring"
 <robh@...nel.org>, "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "Jiri
 Slaby" <jirislaby@...nel.org>, "Miguel Ojeda" <ojeda@...nel.org>, "Boqun
 Feng" <boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>, "Benno Lossin"
 <lossin@...nel.org>, "Andreas Hindborg" <a.hindborg@...nel.org>, "Alice
 Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>,
 <linux-serial@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH RFC 2/4] rust: add basic serial device bus abstractions

On Tue Jan 13, 2026 at 6:59 PM CET, Markus Probst wrote:
> This is gated behind "if T::HAS_RECEIVE_INITIAL". And in probe its
> gated behind "if T::HAS_RECEIVE_INITIAL".

I guess you mean `if !T::HAS_RECEIVE_INITIAL` in probe().

Anyways, I now get what you are trying to do. (I got confused by late_probe(),
which I think is a misleading name for what it actually is and in which context
it might run in. I think a better name would be initial_xfer() or something
along those lines.)

So, what you really want is additional private data that is valid between some
inital xfer happening at some point of time after probe() and unbind(), and
hence is valid to access in all subsequent transfers callbacks.

There are three options:

  (1) What you already implement, but with less callbacks.

      I think the only additional callback you need is initial_xfer(), where you
      return the init private data.

      For storing this data you probably want to add void *init_data to
      struct serdev_device.

  (2) A synchronous inital transfer in probe() as proposed by Kari.

      This is much simpler than (1), but still leaves the driver without an
      Option for the init data in its device private data.

  (3) Leave it to the driver.

      The driver can store an Option in its device private data, which is
      initialized in the first callback.

> Which one do you think should be used for the abstraction?

I don't know, it depends on the requirements of serdev drivers.

But since you already mentioned that there is only a single driver that needs
this initial xfer data, I'd say don't consider it in the abstraction at all
until we are sure it is a common pattern needed by drivers. We can always add it
later on if needed.