On Wed, 04 Jan 2023 15:22:13 +0100, Michael Ralston wrote:
On Wed, 4 Jan 2023 at 19:16, Takashi Iwai tiwai@suse.de 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