Message ID | 1454505500-30384-1-git-send-email-mans@mansr.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 436e056c4ba368f13a5709a5a4a7f26fc238a5a6 |
Headers | show |
On Wed, Feb 03, 2016 at 01:18:20PM +0000, Mans Rullgard wrote: > If something else, typically a codec, has enabled mclk, the BUSY > bit may be set when hw_params() is called without this being an > error. This check thus causes intermittent failures to configure > the sound device when used in such a manner. Fix this by making > the test conditional on !saif->mclk_in_use. Please remember to CC the maintainers for the driver when sending patches.
Mark Brown <broonie@kernel.org> writes: > On Wed, Feb 03, 2016 at 01:18:20PM +0000, Mans Rullgard wrote: >> If something else, typically a codec, has enabled mclk, the BUSY >> bit may be set when hw_params() is called without this being an >> error. This check thus causes intermittent failures to configure >> the sound device when used in such a manner. Fix this by making >> the test conditional on !saif->mclk_in_use. > > Please remember to CC the maintainers for the driver when sending > patches. I CCd everybody scripts/get_maintainers.pl suggested. How am I supposed to know who the maintainers are if they're not listed in MAINTAINERS?
On Fri, Feb 05, 2016 at 01:23:20PM +0000, Måns Rullgård wrote: > Mark Brown <broonie@kernel.org> writes: > > Please remember to CC the maintainers for the driver when sending > > patches. > I CCd everybody scripts/get_maintainers.pl suggested. How am I supposed > to know who the maintainers are if they're not listed in MAINTAINERS? By looking at people working on the driver in git and the authors listed in the driver (get_maintainer --git will do most of this for you, though you do have to think about false positives). As previously advised this is not something that can be fully automated, you need to think about who you are sending things to and why.
Mark Brown <broonie@kernel.org> writes: > On Fri, Feb 05, 2016 at 01:23:20PM +0000, Måns Rullgård wrote: >> Mark Brown <broonie@kernel.org> writes: > >> > Please remember to CC the maintainers for the driver when sending >> > patches. > >> I CCd everybody scripts/get_maintainers.pl suggested. How am I supposed >> to know who the maintainers are if they're not listed in MAINTAINERS? > > By looking at people working on the driver in git and the authors listed > in the driver (get_maintainer --git will do most of this for you, though > you do have to think about false positives). As previously advised this > is not something that can be fully automated, you need to think about > who you are sending things to and why. Most files have been touched by many people. I thought the entire point of the MAINTAINERS file was to remove the guesswork from choosing where to send patches. Apparently sound/ has rules of its own.
On Fri, Feb 05, 2016 at 01:43:22PM +0000, Måns Rullgård wrote: > Mark Brown <broonie@kernel.org> writes: > > By looking at people working on the driver in git and the authors listed > > in the driver (get_maintainer --git will do most of this for you, though > > you do have to think about false positives). As previously advised this > > is not something that can be fully automated, you need to think about > > who you are sending things to and why. > Most files have been touched by many people. I thought the entire point > of the MAINTAINERS file was to remove the guesswork from choosing where > to send patches. Apparently sound/ has rules of its own. No, this is true in general for the kernel - I'm just repeating SubmittingPatches to you here. Most individual drivers don't have a specific entry in MAINTAINERS and it's probably not worth the bother trying to get it completely 100% accurate. MAINTAINERS is there to be helpful and to have things like lists and git hanging off it but it's not the be all and end all of everything, it still generates false positives (consider how many ASoC patches Jaroslav has reviewed for example) and false negatives. No automated system is going to be perfect, at some point you're going to need to think.
diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index a6c7b8d87cd2..13631003cb7c 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -418,7 +418,7 @@ static int mxs_saif_hw_params(struct snd_pcm_substream *substream, } stat = __raw_readl(saif->base + SAIF_STAT); - if (stat & BM_SAIF_STAT_BUSY) { + if (!saif->mclk_in_use && (stat & BM_SAIF_STAT_BUSY)) { dev_err(cpu_dai->dev, "error: busy\n"); return -EBUSY; }
If something else, typically a codec, has enabled mclk, the BUSY bit may be set when hw_params() is called without this being an error. This check thus causes intermittent failures to configure the sound device when used in such a manner. Fix this by making the test conditional on !saif->mclk_in_use. Signed-off-by: Mans Rullgard <mans@mansr.com> --- sound/soc/mxs/mxs-saif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)