On Nov 15 Takashi Sakamoto wrote:
Dice hardware design doesn't allow drivers to read supported combination between sampling transfer frequencies and the number of Multi bit linear audio data channels. According to the design, ALSA dice driver changes current sampling transfer frequency to generate the cache of combinations at probing processing.
Although, this idea is worse because ALSA dice driver cannot handle bus reset when processing driver's probe callback. The callbacks of drivers for units on IEEE 1394 bus are serialized. For example, when processing .probe callback in workqueue context, any other processing such as .update is not executed. As a result, when processing probe callback, the driver cannot handle bus reset.
[...]
It is natural that .probe(), .update(), .remove() driver methods are not reentrant. We must not call an .update() or .remove() for a device + driver pair whose .probe() has not yet returned successfully.
Therefore, procedures which require bus reset handling should not be implemented within the .probe().
For example, the IEEE 1394 storage initiator driver firewire-sbp2 performs SBP-2 login and the initial SCSI INQUIRY in an own deferred execution context, not inside .probe(). If a bus reset happens in the middle of the SBP-2 login transaction or in the middle of the SCSI INQUIRY transaction, that transaction is aborted and rescheduled.
I am only mentioning this as a general remark, not as a direct comment on this patch or on the snd-dice driver even. Perhaps similar deferred execution in a separate execution context is something suitable for a DICE driver, perhaps not; I can't say as I am entirely unfamiliar with the protocol.
Unfortunately, most Dice based models generate bus reset several times after powering on.
[...]
Besides, if there are more devices on the bus, bus resets could be generated by those other nodes too (for example if they boot at the same time as the audio device does).