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 <[email protected]> >> >> The change itself LGTM. >> >> Reviewed-by: Alice Ryhl <[email protected]>
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/[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. 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.)
