On Wed May 6, 2026 at 1:42 PM BST, Alice Ryhl wrote:
> On Tue, May 05, 2026 at 05:23:08PM +0200, Danilo Krummrich wrote:
>> Add a registration_data pointer to struct auxiliary_device, allowing the
>> registering (parent) driver to attach private data to the device at
>> registration time and retrieve it later when called back by the
>> auxiliary (child) driver.
>> 
>> By tying the data to the device's registration, Rust drivers can bind
>> the lifetime of device resources to it, since the auxiliary bus
>> guarantees that the parent driver remains bound while the auxiliary
>> device is bound.
>> 
>> On the Rust side, Registration<T> takes ownership of the data via
>> ForeignOwnable. A TypeId is stored alongside the data for runtime type
>> checking, making Device::registration_data<T>() a safe method.
>> 
>> Signed-off-by: Danilo Krummrich <[email protected]>
>
> The change itself LGTM.
>
> Reviewed-by: Alice Ryhl <[email protected]>
>
> But I'm not entirely convinced that this is the most convenient
> user-interface. I'm wondering if the auxiliary driver trait could
> specify which type the parent driver data is using in an associated
> type, and whether you could eliminate the check and error path that way.
> But then again, AuxiliaryDriver does not appear as a generic parameter
> in auxiliary::Driver, so it might not work.

I think that's similar to what I'm suggesting in
https://lore.kernel.org/rust-for-linux/[email protected]/.

This does still require the type ID to exist and that probe of auxiliary drivers
need to fail if type ID mismatches during probing.

Best,
Gary

Reply via email to