Nothing ever restores the constraints if a clock is specified again, and in general it's odd that the enable/disable don't match up - if we're setting variable constraints I'd expect that in the freq == 0 case we should be setting ->sysclk_constraints to NULL rather than the contents. Indeed, we'll segfault here if the frequency is set to 0 without having first been set to some actual value. It's also bad to modify static data potentially shared between multiple instances of the device in a system.
Having said all that though I'm not clear why we're doing this constraint stuff at all, we never reference sysclk_constraints during startup and teardown and you'd usually do this because you want to set constraints that depend on the sysclk but this is just a constant set of constraints that should be set in the DAI desription.
Comes from 8316.c. Will remove the constraints. Will submit a patch later to remove the constraints in es8316.c. We can assume that the producer(master) provides correct mclk(sysclk) rate.
One question on the interrupt handling: should there be an interrupt disable on suspend and conversely an interrupt enable on resume?
That shouldn't be needed (in general the interrupt enable/disable stuff shouldn't be needed at all).
isn't there a risk of an interrupt being triggered after all the jack detection resources are disabled?
The jack detection resources are only disabled after codec power down?