[PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
From: shengjiu wang shengjiu.wang@nxp.com
When condition ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) is true, then goto fail, the uninitialized variable ret will be returned.
Signed-off-by: shengjiu wang shengjiu.wang@nxp.com Reported-by: kernel test robot lkp@intel.com --- sound/soc/fsl/imx-hdmi.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c index 2c2a76a71940..ede4a9ad1054 100644 --- a/sound/soc/fsl/imx-hdmi.c +++ b/sound/soc/fsl/imx-hdmi.c @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) { dev_err(&pdev->dev, "Invalid HDMI DAI link\n"); + ret = -EINVAL; goto fail; }
On Wed, Dec 16, 2020 at 06:44:24PM +0800, Shengjiu Wang wrote:
From: shengjiu wang shengjiu.wang@nxp.com
When condition ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) is true, then goto fail, the uninitialized variable ret will be returned.
Signed-off-by: shengjiu wang shengjiu.wang@nxp.com Reported-by: kernel test robot lkp@intel.com
Acked-by: Nicolin Chen nicoleotsuka@gmail.com
Hi Shengjiu,
On Wed, Dec 16, 2020 at 7:52 AM Shengjiu Wang shengjiu.wang@nxp.com wrote:
From: shengjiu wang shengjiu.wang@nxp.com
When condition ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) is true, then goto fail, the uninitialized variable ret will be returned.
Signed-off-by: shengjiu wang shengjiu.wang@nxp.com Reported-by: kernel test robot lkp@intel.com
Thanks for the fix.
This should have:
Fixes: 6a5f850aa83a ("ASoC: fsl: Add imx-hdmi machine driver")
Reviewed-by: Fabio Estevam festevam@gmail.com
On Wed, 16 Dec 2020 18:44:24 +0800, Shengjiu Wang wrote:
When condition ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) is true, then goto fail, the uninitialized variable ret will be returned.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret commit: acd894aee3149c15847bc4f0690fccba59ced5e7
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
On Wed, Dec 16, 2020 at 06:44:24PM +0800, Shengjiu Wang wrote:
From: shengjiu wang shengjiu.wang@nxp.com
When condition ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) is true, then goto fail, the uninitialized variable ret will be returned.
Signed-off-by: shengjiu wang shengjiu.wang@nxp.com Reported-by: kernel test robot lkp@intel.com
sound/soc/fsl/imx-hdmi.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c index 2c2a76a71940..ede4a9ad1054 100644 --- a/sound/soc/fsl/imx-hdmi.c +++ b/sound/soc/fsl/imx-hdmi.c @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) { dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
ret = -EINVAL;-- 2.17.1
I still see a warning in v5.11-rc3 that is fixed by this patch, is it not going in this release cycle? It is a regression fix, seems like it should.
Cheers, Nathan
On Tue, Jan 12, 2021 at 11:19:49AM -0700, Nathan Chancellor wrote:
Please delete unneeded context from mails when replying. Doing this makes it much easier to find your reply in the message, helping ensure it won't be missed by people scrolling through the irrelevant quoted material.
Signed-off-by: shengjiu wang shengjiu.wang@nxp.com Reported-by: kernel test robot lkp@intel.com
I still see a warning in v5.11-rc3 that is fixed by this patch, is it not going in this release cycle? It is a regression fix, seems like it should.
This is a random warning fix, why would you expect it to be sent as a bug fix? This is the first indication I've seen that anyone is seeing it in mainline, in general the people who report and fix warnings are doing so based on -next and the patch seems to be from a month ago. I don't have this in my inbox so I assume it's applied already or needs to be resubmitted anyway.
On Tue, Jan 12, 2021 at 06:48:48PM +0000, Mark Brown wrote:
This is a random warning fix, why would you expect it to be sent as a bug fix? This is the first indication I've seen that anyone is seeing it in mainline, in general the people who report and fix warnings are doing so based on -next and the patch seems to be from a month ago. I don't have this in my inbox so I assume it's applied already or needs to be resubmitted anyway.
Well, I consider compiler warnings bugs. I have had plenty of my compiler warning patches sent as bug fixes for an -rc. Furthermore, this patch was sent three times by different people, that should give you some indication that people are tripping over it.
https://lore.kernel.org/alsa-devel/X9NGQaF4pmK8oUAF@mwanda/ https://lore.kernel.org/alsa-devel/1608115464-18710-1-git-send-email-shengji... https://lore.kernel.org/alsa-devel/20201230154443.656997-1-arnd@kernel.org/
The first version was sent on December 11th, it looks like your pull for 5.11 went on the December 14th, then the second version was applied on December 16th so I figured it might be destined for 5.11 but I could not tell (your for-next branch is a merge of your for-5.11 and for-5.12):
https://lore.kernel.org/alsa-devel/160813397775.31838.8934909997692637790.b4...
Cheers, Nathan
On Tue, Jan 12, 2021 at 12:09:21PM -0700, Nathan Chancellor wrote:
On Tue, Jan 12, 2021 at 06:48:48PM +0000, Mark Brown wrote:
This is a random warning fix, why would you expect it to be sent as a bug fix? This is the first indication I've seen that anyone is seeing it in mainline, in general the people who report and fix warnings are doing so based on -next and the patch seems to be from a month ago. I don't have this in my inbox so I assume it's applied already or needs to be resubmitted anyway.
Well, I consider compiler warnings bugs. I have had plenty of my compiler warning patches sent as bug fixes for an -rc. Furthermore, this patch was sent three times by different people, that should give you some indication that people are tripping over it.
I really don't have that good a recall of what warning fixes people are sending, I might notice if I get two versions of the same thing that I look at at roughly the same time but even with a few hours between it's most likely that I'll have completely forgotten. Warning fixes are in general not memorable, it's not a good sign if they are. The default assumption for any warning fix that doesn't say anything else is going to be that either the issue or the toolchain is very new.
For any kind of fix if you think that things are in some way urgent you should say something promptly (or provide some indication of this in the submission if you're sending the fix yourself, such as with a fixes tag). If nobody says anything then you should assume that nobody else is going to be aware of any urgency and that this will affect handling. Should it happen that things aren't flagged up then of course do so but consider that this may well be the first time people will be aware there's any urgency, don't assume that people will have been operating with information they didn't have.
The first version was sent on December 11th, it looks like your pull for 5.11 went on the December 14th, then the second version was applied on December 16th so I figured it might be destined for 5.11 but I could not tell (your for-next branch is a merge of your for-5.11 and for-5.12):
If it's on the for-5.11 branch then it will be for 5.11, which it must be if it was applied then. If it was and it was applied that long ago it'll already be queued in Takashi's tree and I guess he didn't send it on yet.
participants (5)
-
Fabio Estevam -
Mark Brown -
Nathan Chancellor -
Nicolin Chen -
Shengjiu Wang