Re: [PATCH v2 2/3] rust: auxiliary: add registration data to auxiliary devices

[Danilo Krummrich]

On Wed May 6, 2026 at 3:41 PM CEST, Gary Guo wrote:
> 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 <dakr@xxxxxxxxxx>
>>
>> The change itself LGTM.
>>
>> Reviewed-by: Alice Ryhl <aliceryhl@xxxxxxxxxx>

Thanks!

>> 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/DI6L13A5LMOW.DU7ZTHXZYB0K@xxxxxxxxxxx/.
>
> This does still require the type ID to exist and that probe of auxiliary drivers
> need to fail if type ID mismatches during probing.

Technically, this would be an additional driver match criteria, i.e. the name
string in struct auxiliary_device_id *and* the asserted type of the parent's
registration data must match.

Given that drivers can match against multiple entries in the auxiliary_device_id
table, we must consider that they can have different registration data types
(depending on the specific parent driver that exposed the auxiliary device).

Thus, I don't think we can solve this without a runtime dispatch (over all types
that would need to be listed in the ID table) anyway; and having this dispatch
in the child driver - essentially leaking an implementation detail of each of
the parents into the child - does not seem to add any value; quite the opposite
unfortunately.

(OOC, I hacked up the statically typed version -- I think it turns out OK,
despite the fact that it still leaks the parent's registration private data type
to the child, which I dislike, plus a few hiccups with the generic device
context infrastructure. But as mentioned, I don't think that's an option in the
first place.)