What we have atm: snd_sof_probe - might be called from wq snd_sof_remove - might be called from wq (cleans up the snd_sof_probe step)
I don't think it's correct, snd_sof_remove cannot be called from a wq. The device core knows nothing about workqueues.
We want a callbacks for hardware/device probing, right, split the snd_sof_probe (and remove) to be able to support a sane level of deferred probing support.
With that in mind: snd_sof_device_probe - Not called from wq (to handle deferred probing) snd_sof_probe - might be called from wq
snd_sof_remove - might be called from wq (cleans up the snd_sof_probe step) snd_sof_device_remove - Not called from wq (to up the snd_sof_device_probe step)
Naming option: s/device/hardware
I like the 'device' hint since it's directly related to the device (or subsystem) callbacks.
However, I think the snd_sof_device_remove itself is redundant and we might not need it at all as in case we have wq and there is a failure in there we do want to release resources as much as possible. The module will be kept loaded (no deferred handling in wq) and that might block PM, other devices to behave correctly. Iow, if the wq has failure we should do a cleanup to the best effort to reach a level like the driver is not even loaded.
If we have a failure in a workqueue used for probe, then we have to clean-up everything since nothing in the device core will do so for us.