On 27/06/2022 13:45, Mark Brown wrote:
On Mon, Jun 27, 2022 at 11:49:46AM +0200, Krzysztof Kozlowski wrote:
On 27/06/2022 11:43, Charles Keepax wrote:
The conversion of the set_fmt callback to direct clock specification included a small typo, correct the affected code.
Fixes: 91c49199e6d6 ("ASoC: samsung: Update to use set_fmt_new callback")
Where is this commit from? It's not in next.
0b491c7c1b2555ef08285fd49a8567f2f9f34ff8 - if you can't find something search for the subject, people often get things wrong.
Finding it by subject does not solve problem with Fixes tag, that it might be pointing to incorrect commit (e.g. rebased).
You should put such big patchsets in your own repo (e.g. on Github/Gitlab) and feed it to linux-next or at least to LKP.
The size of the patch set isn't really relevant here, the same issue can apply to anything that can be built in more than one configuration. People should of course try to do things that work but equally we shouldn't be putting procedural blockers in place, we have integration trees for a reason.
I would say that size of the patchset is a proof someone is doing bigger work and we want the bigger work to be tested even before hitting maintainer's tree.
My comment was not a requirement (procedural blocker) but a suggestion, because maybe Charles was not aware that developer trees can be tested for free.
This way you would get build coverage... because it seems the build was missing in your case.
That coverage has apparently also been missing in -next for several weeks.
Eh, it seems defconfigs for this old platform do not select sound, so we rely on randconfig. :(
Best regards, Krzysztof