[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YrmYbZV4mj9d9++t@sirena.org.uk>
Date: Mon, 27 Jun 2022 12:45:49 +0100
From: Mark Brown <broonie@...nel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.com>,
s.nawrocki@...sung.com, jrdr.linux@...il.com, lgirdwood@...il.com,
alsa-devel@...a-project.org, patches@...nsource.cirrus.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: samsung: s3c24xx-i2s: Fix typo in DAIFMT handling
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.
> 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.
> 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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists