> 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.
