On Wed, 04 Jan 2023 15:22:13 +0100,
Michael Ralston wrote:
>
> On Wed, 4 Jan 2023 at 19:16, Takashi Iwai <tiwai@xxxxxxx> wrote:
> >
> > I believe it's time to check which commit broke things.
> > Assume that the bug is USB audio core changes, the following 8 commits
> > are relevant:
> >
>
> Reverting 1045f5f1ff0751423aeb65648e5e1abd7a7a8672 resulted in this
> compiler error:
>
> sound/usb/endpoint.c: In function 'snd_usb_endpoint_stop':
> sound/usb/endpoint.c:1672:27: error: 'struct snd_usb_endpoint' has no
> member named 'need_prepare'
> 1672 | ep->need_prepare = true;
> | ^~
>
> I did git annotate on endpoint.c and found line 1672 was added by commit:
> 3759ae6600e40
>
> Reverting this commit has allowed me to compile a kernel again.
>
> 3759ae6600e40
> 1045f5f1ff0751423aeb65648e5e1abd7a7a8672
> 9355b60e401d825590d37f04ea873c58efe9b7bf
> a74f8d0aa902ca494676b79226e0b5a1747b81d4
> 9902b303b5ade208b58f0dd38a09831813582211
> 9a737e7f8b371e97eb649904276407cee2c9cf30
>
> I reverted these six commits, testing each one independently, then
> adding the next on top of the others, and it didn't fix the issue.
> Then the next commit wouldn't revert cleanly.
>
> CONFLICT (content): Merge conflict in sound/usb/pcm.c
> error: could not revert 2be79d586454... ALSA: usb-audio: Split
> endpoint setups for hw_params and prepare (take#2)
>
> ++<<<<<<< HEAD
> + again:
> + if (subs->sync_endpoint) {
> + ret = snd_usb_endpoint_prepare(chip, subs->sync_endpoint);
> + if (ret < 0)
> + goto unlock;
> + }
> +
> + ret = snd_usb_endpoint_prepare(chip, subs->data_endpoint);
> ++=======
> + ret = configure_endpoints(chip, subs);
> ++>>>>>>> parent of 2be79d586454 (ALSA: usb-audio: Split endpoint
> setups for hw_params and prepare (take#2))
> if (ret < 0)
> goto unlock;
> - else if (ret > 0)
> - snd_usb_set_format_quirk(subs, subs->cur_audiofmt);
> - ret = 0;
>
>
> Again, I did a git annotate and found I needed to also revert
> 67fd112b4b040 to get 2be79d58645465351af5320eb14c70a94724c5ef to
> revert.
>
> This one also didn't fix the issue.
>
> ac5e2fb425e1121ceef2b9d1b3ffccc195d55707
> This final revert on top of all the others fixed the issue.
>
> These are the reverts I made:
> 3759ae6600e40
> 1045f5f1ff0751423aeb65648e5e1abd7a7a8672
> 9355b60e401d825590d37f04ea873c58efe9b7bf
> a74f8d0aa902ca494676b79226e0b5a1747b81d4
> 9902b303b5ade208b58f0dd38a09831813582211
> 9a737e7f8b371e97eb649904276407cee2c9cf30
> 67fd112b4b040
> 2be79d58645465351af5320eb14c70a94724c5ef
> ac5e2fb425e1121ceef2b9d1b3ffccc195d55707
Oh, did you test with 6.2-rc? I checked the reverts only on top of
the 6.1.0. From there, you can revert all mentioned commits cleanly
and should build.
In anyway, do I understand correctly that the bug still persists at
the revert of the commit 2be79d58645465351af5320eb14c70a94724c5ef, and
it's fixed by the revert of ac5e2fb425e1121ceef2b9d1b3ffccc195d55707?
If so, what happens if you revert only
ac5e2fb425e1121ceef2b9d1b3ffccc195d55707?
Takashi
