On 10/4/23 11:40, Mark Brown wrote:
On Wed, Oct 04, 2023 at 11:16:09AM -0400, Pierre-Louis Bossart wrote:
matching the name is fine (if you are matching it against an existing name) but expecting the name to be anything specific is not going to work as the name is dynamic and can/will change each boot.
Not following, sorry.
In the SoundWire context, the device name directly follows the ACPI or Device Tree information, I don't really see how its name could change on each boot (assuming no DSDT override or overlays of course). The platform descriptors are pretty much fixed, aren't they?
Intel and AMD make such assumptions on names for pretty much all machine drivers, it's not really something new - probably 15+ years? Adding Mark Brown in CC: to make sure he's aware of this thread.
FWIW DT is much less affected here since all the inter-device references are explicit in the DT (modulo needing to work around breakage) so we're not hard coding in the way ACPI so unfortunately requires.
Isn't there a contradiction between making "all inter-device references explicit in the DT" and having a device name use an IDA, which cannot possibly known ahead of time?
I think we keep circling on the differences between "Controller" and "link" (aka bus). A Controller can have one or more links. A system can have one or more controllers.
Intel platforms have one controller and 4 or more links. QCOM platforms have one or more controllers with one link each.
I am not sure how this IDA-generated bus_id helps deal with these two cases, since we can't really make any assumptions on how controllers/links will be started and probed.
What we are missing is a hierarchical controller/link definition, IOW a controller_id should be given to the master by a higher level instead of using an IDA.