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.
