the SST/SOF driver creates a platform device using the codec _HID as a key to hard-coded lookup tables in sound/soc/intel/common/soc-acpi*.c - it will be probed *after* the codec driver probes. I really don't see how to use the machine driver as currently implemented to establish board-level connections that would influence the codec driver probe and its use of a clock.
You have the opportunity to run whatever code you want to run at the point where you're registering your drivers with the system on module init, things like DMI quirk tables (which is what you're going to need to do here AFAICT) should work just as well there as they do later on when the driver loads.
The idea here was to have one single build, and then rely on what the user configured with initrd override to probe the right I2C codec driver and indirectly the machine driver. It's similar to device tree overlays.
With the same up2 board, I change the .aml file in /lib/firmware/acpi-upgrades, swap one HAT board for another and the new board is handled automagically.
I don't see how I can use hard-coded DMI tables or board-specific things without losing the single build?
I think you're giving up way too easily here. The kernel has really good support for systems that don't have any firmware description at all, this shouldn't be complex or breaking new ground.
See above, I don't think the machine driver can do what you had in mind?
I don't see how to proceed unless we remove all support for ACPI, both for codec and clock driver, and trigger their probe "manually" with a board-level initialization.
The clkdev stuff can use dev_name() so so long as the devices appear with predictable names you should be fine. If not IIRC everything in ACPI is named in the AML so clkdev could be extended to be able to find things based on the names it gives.
I had a discussion with Andy Shevchenko that we should precisely not be using dev_name() since we don't control the names that ACPI selects for us. And since I was using the generic PRP0001 thing for the clock device to probe using the 'compatible' string it's actually even less reliable and unique...
And btw there's already a precedent for using global names, it's what the Skylake driver does for the mclk and ssp clocks. To the best of my knowledge the device specific namespacing does not exist on any ACPI platform. We have
No machine description at all exists on board file systems other than what we write in C and they manage to cope with this, I'm sure we can find a way to do it with ACPI. I mentioned clkdev before, that is something that's done entirely at the Linux level.
a request from Dialog to implement the same thing for SOF to solve dependencies on the clock being stable before turning on the codec, so if global names are not acceptable we have a real problem.
If existing usages that have ended up getting merged are going to be used to push for additional adoption then that's not encouraging.
I wasn't trying to push this against your will, rather I wanted to highlight that we should be clear on the direction for all these uses of the clk API in an ACPI context. If what I suggested here is not the right path, then how do we deal with all the existing cases? This PCM512x use is not a mainstream usage, we use this board mainly for validation and for community support, the other cases with 'mclk' and 'sspX_fsync' are critical and impact devices shipping in large volumes.