usb: renesas_usbhs: avoid uninitialized variable use
PATCH 1/1 usb: renesas_usbhs: avoid uninitialized variable use
After the renesas_usbhs driver is enabled in ARM multi_v7_defconfig, we now get a new warning:
renesas_usbhs/mod.c: In function 'usbhs_interrupt':renesas_usbhs/mod.c:246:7: warning: 'intenb1' may be used uninitialized in this function [-Wmaybe-uninitialized]
gcc correctly points to a problem here, for the case that the device is in host mode, we use the intenb1 variable without having assigned it first. The state->intsts1 has a similar problem, but gcc cannot know that.
This avoids the problem by initializing both sides of the comparison to zero when we don't read them from the respective registers.
drivers/usb/renesas_usbhs/mod.c +2 -0
@@ -223,6 +223,8 @@ static int usbhs_status_get_each_irq(struct usbhs_priv *priv,if (usbhs_mod_is_host (priv)) { state->intsts1 =usbhs_read (priv,INTSTS1 ); intenb1 =usbhs_read (priv,INTENB1 ); + }else { + state->intsts1 = intenb1 =0 ; }/* mask */
PATCH 1/1 usb: renesas_usbhs: avoid uninitialized variable use
Hi Arnd,
Quoted 13 lines
Sent: Friday, May 22, 2015 8:07 PM
After the
renesas_usbhsdriver is enabled in ARMmulti_v7_defconfig, we now get a new warning:
renesas_usbhs/mod.c: In function 'usbhs_interrupt':renesas_usbhs/mod.c:246:7: warning: 'intenb1' may be used uninitialized in this function [-Wmaybe-uninitialized]gcc correctly points to a problem here, for the case that the device is in host mode, we use the intenb1 variable without having assigned it first. The
state->intsts1has a similar problem, but gcc cannot know that.
Quoted 6 lines
This avoids the problem by initializing both sides of the comparison to zero when we don't read them from the respective registers.
Signed-off-by Arnd Bergmann <[email protected]>Fixes 88a25e02f3 ("usb: renesas_usbhs: Add access control for INTSTS1 and INTENB1 register")
Thank you very much for the patch!
(I'm not sure why a toolchain I used (Linaro GCC 2014.11) doesn't show this warning...)
Best regards,
Yoshihiro Shimoda
Quoted 18 lines
drivers/usb/renesas_usbhs/mod.c +2
-1@@ -223,6 +223,8 @@ static int usbhs_status_get_each_irq(struct usbhs_priv *priv,if (usbhs_mod_is_host (priv)) { state->intsts1 =usbhs_read (priv,INTSTS1 ); intenb1 =usbhs_read (priv,INTENB1 ); + }else { + state->intsts1 = intenb1 =0 ; }/* mask */ --To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 1/1 usb: renesas_usbhs: avoid uninitialized variable use
Quoted 22 lines · Yoshihiro Shimoda
Hi Arnd,
Quoted 13 lines
Sent: Friday, May 22, 2015 8:07 PM
After the
renesas_usbhsdriver is enabled in ARMmulti_v7_defconfig, we now get a new warning:
renesas_usbhs/mod.c: In function 'usbhs_interrupt':renesas_usbhs/mod.c:246:7: warning: 'intenb1' may be used uninitialized in this function [-Wmaybe-uninitialized]gcc correctly points to a problem here, for the case that the device is in host mode, we use the intenb1 variable without having assigned it first. The
state->intsts1has a similar problem, but gcc cannot know that.Quoted 6 lines
This avoids the problem by initializing both sides of the comparison to zero when we don't read them from the respective registers.
Signed-off-by Arnd Bergmann <[email protected]>Fixes 88a25e02f3 ("usb: renesas_usbhs: Add access control for INTSTS1 and INTENB1 register")
Quoted 8 lines
Thank you very much for the patch!
(I'm not sure why a toolchain I used (Linaro GCC 2014.11) doesn't show this warning...)
Best regards,
Yoshihiro Shimoda
Quoted 20 lines
Quoted 19 lines
drivers/usb/renesas_usbhs/mod.c +2
-1@@ -223,6 +223,8 @@ static int usbhs_status_get_each_irq(struct usbhs_priv *priv,if (usbhs_mod_is_host (priv)) { state->intsts1 =usbhs_read (priv,INTSTS1 ); intenb1 =usbhs_read (priv,INTENB1 ); + }else { + state->intsts1 = intenb1 =0 ; }/* mask */ --To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html