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 SNDLooks like you are assuming the regular USB audio stuff is probed first?
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.
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.