On Sun May 10, 2026 at 11:39 PM CEST, Danilo Krummrich wrote: > 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.)
One additional note: It would however be possible to support this as an additional special case (it is special implementation wise, but usage wise it is the common case) when there's only a single entry in the match table, and otherwise provide the option to fall back on the existing runtime dispatch. That said, I'm still not convinced about exposing the type and whether it is worth the extra complexity on the child driver side, but I'd also like to further consider it as a potential subsequent improvement. The draft implementation I mentioned previously can be found in [1]; it is based on top of the HRT rework, as it provides a much better picture of how it turns out eventually. For now, I'll pick this up as is. Thanks, Danilo [1] https://git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/log/?h=poc/aux-typed
