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.
