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
