Hi Pierre,
On 7/25/2023 2:15 AM, Pierre-Louis Bossart wrote:
On 7/25/23 04:34, Wesley Cheng wrote:
In case of notifying SND platform drivers of connection events, some of
these use cases, such as offloading, require an ASoC USB backend device to
be initialized before the events can be handled. If the USB backend device
has not yet been probed, this leads to missing initial USB audio device
connection events.
Expose an API that traverses the usb_chip array for connected devices, and
to call the respective connection callback registered to the SND platform
driver.
Signed-off-by: Wesley Cheng <quic_wcheng@xxxxxxxxxxx>
---
sound/usb/card.c | 19 +++++++++++++++++++
sound/usb/card.h | 2 ++
2 files changed, 21 insertions(+)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 365f6d978608..27a89aaa0bf3 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -170,6 +170,25 @@ struct snd_usb_stream *snd_usb_find_suppported_substream(int card_idx,
}
EXPORT_SYMBOL_GPL(snd_usb_find_suppported_substream);
+/*
+ * in case the platform driver was not ready at the time of USB SND
+ * device connect, expose an API to discover all connected USB devices
+ * so it can populate any dependent resources/structures.
+ */
+void snd_usb_rediscover_devices(void)
+{
+ int i;
+
+ mutex_lock(®ister_mutex);
+ for (i = 0; i < SNDRV_CARDS; i++) {
+ if (usb_chip[i])
+ if (platform_ops && platform_ops->connect_cb)
+ platform_ops->connect_cb(usb_chip[i]);
what happens if the USB device is removed while the platform device adds
a port?
This sounds super-racy to me. It's the same set of problems we're having
between audio and display/DRM, I would be surprised if this function
dealt with all corner cases of insertion/removal, bind/unbind.
The chip array entries are all populated and removed while under the
register_mutex, so going over your race condition, we should see:
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() we won't notify of any
connection for that particular chip index.
Thanks
Wesley Cheng
