Well, just write a CODEC driver that matches what you've got down on your boards. Usually the driver does need to enforce some kind of limits (on input format and sample rate normally) even for a simple device with no software control otherwise the device can get driven out of spec.
The CODEC is part of the system integration process. From SOC standpoint the machine driver is what needs to be delivered. I dont know finally what the final codec will be, its upto the integrator to write. May be he can pick the ones from the asoc:codecs list.
I dont like the dependency of the machine driver with the codec driver for enumeration. Machine driver can self exist without having for the codec driver. [USB, PCi, HDMI, S/PDIF] However the vice-versa is not true and is of no use. Binding them together will make the usecases easy (power for instance, user interaction), but should not have been a hardlimit. Given the thought process, ALSA should allow dummy_codec drivers which it does (from spdif_tranceiver.c), but why not make it completely generic? (remove the s/pdif keywords).
Thanks for your ideas about the hdmi driver, will check how is that handling this dependency on codec driver.
--Nitin