When the card was uninstalled with modprobe -r, the da7219 codec was not removed, only component da7219_remove() is invoked, do you suggest the component driver probe and remove has to happen with da7219_i2_driver probe and remove together? Thanks for the code review.
Well as far as I understand it the the devm_* allocated resources are tied to the i2c dev. If I'm correct then unless that's removed then those resources won't be freed. If this is a valid scenario then we would probably have to look at avoiding all devm_ calls in the da7219_probe() code as they wouldn't be released when doing what you are here.
Mark, what's your take on this? Am I missing something obvious?
You're not missing anything, you shouldn't be doing devm allocations at the CODEC level only at the device model level. I'm somewhat confused why you would be registering clocks at the device model level TBH.
I am afraid we have quite a few codec drivers used in x86/ACPI platforms using devm_ clk functions at the component probe level...see e.g.:
da7213, da7218, da7219, es8316, es8328, max98090, max98095, rt5514, rt5616, rt5640, rt5682, tlk320aic32x4
some do even worse: nau8825, tlv320aic32x4 call devm_ functions in set_sysclk.
The module load/unload tests used for SOF remove all the drivers, so as Adam was saying this should not happen if you remove the codec driver.
It already took us quite a bit of effort to make sure all resources are properly allocated/released. We still have known issues when removing the platform driver only, mainly with HDaudio. I wasn't aware of this case for I2C codecs, I guess this just made the list of TODO cleanups even longer. D'oh!