On 10/23/23 16:54, Wesley Cheng wrote: > Hi Pierre, > > On 10/17/2023 4:11 PM, Pierre-Louis Bossart wrote: >> >> >> On 10/17/23 15:01, Wesley Cheng wrote: >>> In case the USB backend device has not been initialized/probed, USB SND >>> device connections can still occur. When the USB backend is eventually >>> made available, previous USB SND device connections are not >>> communicated to >>> the USB backend. Call snd_usb_rediscover_devices() to generate the >>> connect >>> callbacks for all USB SND devices connected. This will allow for the >>> USB >>> backend to be updated with the current set of devices available. >>> >>> The chip array entries are all populated and removed while under the >>> register_mutex, so going over potential race conditions: >>> >>> Thread#1: >>> q6usb_component_probe() >>> --> snd_soc_usb_add_port() >>> --> snd_usb_rediscover_devices() >>> --> mutex_lock(register_mutex) >>> >>> Thread#2 >>> --> usb_audio_disconnect() >>> --> mutex_lock(register_mutex) >>> >>> So either thread#1 or thread#2 will complete first. If >>> >>> Thread#1 completes before thread#2: >>> SOC USB will notify DPCM backend of the device connection. Shortly >>> after, once thread#2 runs, we will get a disconnect event for the >>> connected device. >>> >>> Thread#2 completes before thread#1: >>> Then during snd_usb_rediscover_devices() it won't notify of any >>> connection for that particular chip index. >> Looks like you are assuming the regular USB audio stuff is probed first? >> >> What if it's not the case? Have you tested with a manual 'blacklist' and >> "modprobe" sequence long after all the DSP stuff is initialized? >> >> It really reminds me of audio+display issues, and the same opens apply >> IMHO. > > Not necessarily...if the USB audio driver is not probed, then that is > the same scenario as when there is no USB audio capable device plugged > in, while the offload path is waiting for the connect event. I think > this is the standard scenario. > > In the situation where the platform sound card hasn't probed yet and USB > audio devices are being identified, then that is basically the scenario > that would be more of an issue, since its USB SND that notifies of the > connection state (at the time of connect/disconnect). Not following if this scenario is covered? > I've tried with building these drivers as modules and probing them at > different times/sequences, and I haven't seen an issue so far. The scenario I have in mind is this: the platform driver is on the deny list, the USB driver detects a device. When the platform driver probes at a later time (with a manual modprobe to make delays really long), how would the notification be handled? Between audio and display, we use the 'drm_audio_component' layer to model these sort of run-time binding between independent driver stacks. It's not used here but we need a moral equivalent, don't we? It would really help if you documented a bit more the dependencies or timing assumptions, to make sure we have a stable solution to build on.
