This seems to be a consequence of Intel hardware decisions, so I guess best suited place for this is Intel controller, do we really want to have this in core logic?
It's a valid objection.
The reason why I added the alternate strategies in the core logic is that the IDA and hybrid approach are just software-based with no specific hardware dependencies. If QCOM or AMD wanted to use the strategies contributed and tested by Intel, it'd be a two-line change on their side.
That said, it's likely that at some point *someone* will want to constrain the device number allocation further, be it with ACPI/DT properties or reading hardware registers. The device number is a de-facto priority given the way we scan the PING frames, so some systems may want to give a higher priority to a specific peripherals.
This would push us to add a master ops callback to control the device number allocation. It's a bit invasive but that would give the ultimate flexibility. Reuse between vendors could be possible if 'generic' callbacks were part of a library to pick from.
I don't really have any objections if this vendor-specific callback was preferred, it may be a bit early to add this but long-term it's probably what makes more sense.
I'll go with the flow on suggested recommendations.
Thanks, if it all one of the other two controller start using this, it would make sense to move it to core then, for now would be better to have this in specific driver
The code is much cleaner indeed that way.
I still have to work on a race condition if the codec driver probe happens *after* the enumeration. In that case, the properties needed to decide which allocation to use are not initialized yet.
We may need to either force the codec to re-enumerate with a ForceReset, or to switch the device number. In theory the latter is straightforward but there can be additional races if there are interrupts thrown just before the device number change happens.