ALSA: timer: Relax start tick time check for slave timer elements

commit ccbfcac05866ebe6eb3bc6d07b51d4ed4fcde436 upstream.

The recent addition of a sanity check for a too low start tick time
seems breaking some applications that uses aloop with a certain slave
timer setup.  They may have the initial resolution 0, hence it's
treated as if it were a too low value.

Relax and skip the check for the slave timer instance for addressing
the regression.

Fixes: 4a63bd179fa8 ("ALSA: timer: Set lower bound of start tick time")
Cc: <stable@vger.kernel.org>
Link: https://github.com/raspberrypi/linux/issues/6294
Link: https://patch.msgid.link/20240810084833.10939-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/sound/core/timer.c b/sound/core/timer.c
index 708c9a46eefe332d1c0a2ec8aa682457a8cc66d4..7e6fd86df41c91a48c530b4ab9afb6886f335be9 100644 (file)
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -556,7 +556,7 @@ static int snd_timer_start1(struct snd_timer_instance *timeri,
        /* check the actual time for the start tick;
         * bail out as error if it's way too low (< 100us)
         */
-       if (start) {
+       if (start && !(timer->hw.flags & SNDRV_TIMER_HW_SLAVE)) {
                if ((u64)snd_timer_hw_resolution(timer) * ticks < 100000) {
                        result = -EINVAL;
                        goto unlock;