[U-Boot] [RFC PATCH] USB: get rid of warning when compile with debug enabled
When compile with debug information is enabled, if call spin_lock_irqsave, it will give following warning information. This patch is used to get rid of it. --->8--- warning: 'flags' is used uninitialized in this function [-Wuninitialized] ---8<---
Signed-off-by: Bo Shen voice.shen@atmel.com ---
include/usb/lin_gadget_compat.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/usb/lin_gadget_compat.h b/include/usb/lin_gadget_compat.h index a25e9d9..fb525e7 100644 --- a/include/usb/lin_gadget_compat.h +++ b/include/usb/lin_gadget_compat.h @@ -15,7 +15,7 @@ /* common */ #define spin_lock_init(...) #define spin_lock(...) -#define spin_lock_irqsave(lock, flags) do { debug("%lu\n", flags); } while (0) +#define spin_lock_irqsave(lock, flags) do { flags = 1; debug("%lu\n", flags); } while (0) #define spin_unlock(...) #define spin_unlock_irqrestore(lock, flags) do {flags = 0; } while (0) #define disable_irq(...)
On Monday, August 25, 2014 at 11:23:19 AM, Bo Shen wrote:
When compile with debug information is enabled, if call spin_lock_irqsave, it will give following warning information. This patch is used to get rid of it. --->8--- warning: 'flags' is used uninitialized in this function [-Wuninitialized] ---8<---
The patch is wrong. The compiler complains that flags might be used uninited because that is the case -- you call spin_lock_irqsave() with uninited flags and because debug() is expanded to printf() I guess, the compiler spews.
So which file does this warning come from ?
Signed-off-by: Bo Shen voice.shen@atmel.com
include/usb/lin_gadget_compat.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/usb/lin_gadget_compat.h b/include/usb/lin_gadget_compat.h index a25e9d9..fb525e7 100644 --- a/include/usb/lin_gadget_compat.h +++ b/include/usb/lin_gadget_compat.h @@ -15,7 +15,7 @@ /* common */ #define spin_lock_init(...) #define spin_lock(...) -#define spin_lock_irqsave(lock, flags) do { debug("%lu\n", flags); } while (0) +#define spin_lock_irqsave(lock, flags) do { flags = 1; debug("%lu\n", flags); } while (0) #define spin_unlock(...) #define spin_unlock_irqrestore(lock, flags) do {flags = 0; } while (0) #define disable_irq(...)
Best regards, Marek Vasut
Hi Marek,
On 08/25/2014 06:43 PM, Marek Vasut wrote:
On Monday, August 25, 2014 at 11:23:19 AM, Bo Shen wrote:
When compile with debug information is enabled, if call spin_lock_irqsave, it will give following warning information. This patch is used to get rid of it. --->8--- warning: 'flags' is used uninitialized in this function [-Wuninitialized] ---8<---
The patch is wrong. The compiler complains that flags might be used uninited because that is the case -- you call spin_lock_irqsave() with uninited flags and because debug() is expanded to printf() I guess, the compiler spews.
So which file does this warning come from ?
I enable debug information (In common.h, define the DEBUG).
It comes out from usb gadget driver, for example, atmel_usba_udc.c and also s3c_udc_otg.c and etc.
I see the spin_lock_irqsave() function in <drivers/usb/musb-new/linux-compat.h> defined as: --->8--- #define spin_lock_irqsave(lock, flags) do {} while (0) ---8<---
As in u-boot, there is no lock actually, so I think we can fix it as <drivers/usb/musb-new/linux-compat.h>, or use the patch as I suggest, or anything else, what about your opinion?
Signed-off-by: Bo Shen voice.shen@atmel.com
include/usb/lin_gadget_compat.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/usb/lin_gadget_compat.h b/include/usb/lin_gadget_compat.h index a25e9d9..fb525e7 100644 --- a/include/usb/lin_gadget_compat.h +++ b/include/usb/lin_gadget_compat.h @@ -15,7 +15,7 @@ /* common */ #define spin_lock_init(...) #define spin_lock(...) -#define spin_lock_irqsave(lock, flags) do { debug("%lu\n", flags); } while (0) +#define spin_lock_irqsave(lock, flags) do { flags = 1; debug("%lu\n", flags); } while (0) #define spin_unlock(...) #define spin_unlock_irqrestore(lock, flags) do {flags = 0; } while (0) #define disable_irq(...)
Best regards, Marek Vasut
Best Regards, Bo Shen
On Tuesday, August 26, 2014 at 03:11:13 AM, Bo Shen wrote:
Hi Marek,
On 08/25/2014 06:43 PM, Marek Vasut wrote:
On Monday, August 25, 2014 at 11:23:19 AM, Bo Shen wrote:
When compile with debug information is enabled, if call spin_lock_irqsave, it will give following warning information. This patch is used to get rid of it. --->8--- warning: 'flags' is used uninitialized in this function [-Wuninitialized] ---8<---
The patch is wrong. The compiler complains that flags might be used uninited because that is the case -- you call spin_lock_irqsave() with uninited flags and because debug() is expanded to printf() I guess, the compiler spews.
So which file does this warning come from ?
I enable debug information (In common.h, define the DEBUG).
It comes out from usb gadget driver, for example, atmel_usba_udc.c and also s3c_udc_otg.c and etc.
Then those need fixing. There is no problem with the macro.
I see the spin_lock_irqsave() function in <drivers/usb/musb-new/linux-compat.h> defined as: --->8--- #define spin_lock_irqsave(lock, flags) do {} while (0) ---8<---
As in u-boot, there is no lock actually, so I think we can fix it as <drivers/usb/musb-new/linux-compat.h>, or use the patch as I suggest, or anything else, what about your opinion?
Fix all the offending drivers which pass uninited variable into macro which might use it. That's the fix.
Best regards, Marek Vasut
Hi Marek,
On 08/26/2014 02:46 PM, Marek Vasut wrote:
On Tuesday, August 26, 2014 at 03:11:13 AM, Bo Shen wrote:
Hi Marek,
On 08/25/2014 06:43 PM, Marek Vasut wrote:
On Monday, August 25, 2014 at 11:23:19 AM, Bo Shen wrote:
When compile with debug information is enabled, if call spin_lock_irqsave, it will give following warning information. This patch is used to get rid of it. --->8--- warning: 'flags' is used uninitialized in this function [-Wuninitialized] ---8<---
The patch is wrong. The compiler complains that flags might be used uninited because that is the case -- you call spin_lock_irqsave() with uninited flags and because debug() is expanded to printf() I guess, the compiler spews.
So which file does this warning come from ?
I enable debug information (In common.h, define the DEBUG).
It comes out from usb gadget driver, for example, atmel_usba_udc.c and also s3c_udc_otg.c and etc.
Then those need fixing. There is no problem with the macro.
I see the spin_lock_irqsave() function in <drivers/usb/musb-new/linux-compat.h> defined as: --->8--- #define spin_lock_irqsave(lock, flags) do {} while (0) ---8<---
As in u-boot, there is no lock actually, so I think we can fix it as <drivers/usb/musb-new/linux-compat.h>, or use the patch as I suggest, or anything else, what about your opinion?
Fix all the offending drivers which pass uninited variable into macro which might use it. That's the fix.
Thanks for your opinion.
I will send out the patch as you suggested to fix this issue.
Best regards, Marek Vasut
Best Regards, Bo Shen
On Wednesday, August 27, 2014 at 09:39:04 AM, Bo Shen wrote:
Hi Marek,
On 08/26/2014 02:46 PM, Marek Vasut wrote:
On Tuesday, August 26, 2014 at 03:11:13 AM, Bo Shen wrote:
Hi Marek,
On 08/25/2014 06:43 PM, Marek Vasut wrote:
On Monday, August 25, 2014 at 11:23:19 AM, Bo Shen wrote:
When compile with debug information is enabled, if call spin_lock_irqsave, it will give following warning information. This patch is used to get rid of it. --->8--- warning: 'flags' is used uninitialized in this function [-Wuninitialized] ---8<---
The patch is wrong. The compiler complains that flags might be used uninited because that is the case -- you call spin_lock_irqsave() with uninited flags and because debug() is expanded to printf() I guess, the compiler spews.
So which file does this warning come from ?
I enable debug information (In common.h, define the DEBUG).
It comes out from usb gadget driver, for example, atmel_usba_udc.c and also s3c_udc_otg.c and etc.
Then those need fixing. There is no problem with the macro.
I see the spin_lock_irqsave() function in <drivers/usb/musb-new/linux-compat.h> defined as: --->8--- #define spin_lock_irqsave(lock, flags) do {} while (0) ---8<---
As in u-boot, there is no lock actually, so I think we can fix it as <drivers/usb/musb-new/linux-compat.h>, or use the patch as I suggest, or anything else, what about your opinion?
Fix all the offending drivers which pass uninited variable into macro which might use it. That's the fix.
Thanks for your opinion.
I will send out the patch as you suggested to fix this issue.
Thanks!
Best regards, Marek Vasut
On Wed, Aug 27, 2014 at 07:45:57PM +0200, Marek Vasut wrote:
On Wednesday, August 27, 2014 at 09:39:04 AM, Bo Shen wrote:
Hi Marek,
On 08/26/2014 02:46 PM, Marek Vasut wrote:
On Tuesday, August 26, 2014 at 03:11:13 AM, Bo Shen wrote:
Hi Marek,
On 08/25/2014 06:43 PM, Marek Vasut wrote:
On Monday, August 25, 2014 at 11:23:19 AM, Bo Shen wrote:
When compile with debug information is enabled, if call spin_lock_irqsave, it will give following warning information. This patch is used to get rid of it. --->8--- warning: 'flags' is used uninitialized in this function [-Wuninitialized] ---8<---
The patch is wrong. The compiler complains that flags might be used uninited because that is the case -- you call spin_lock_irqsave() with uninited flags and because debug() is expanded to printf() I guess, the compiler spews.
So which file does this warning come from ?
I enable debug information (In common.h, define the DEBUG).
It comes out from usb gadget driver, for example, atmel_usba_udc.c and also s3c_udc_otg.c and etc.
Then those need fixing. There is no problem with the macro.
I see the spin_lock_irqsave() function in <drivers/usb/musb-new/linux-compat.h> defined as: --->8--- #define spin_lock_irqsave(lock, flags) do {} while (0) ---8<---
As in u-boot, there is no lock actually, so I think we can fix it as <drivers/usb/musb-new/linux-compat.h>, or use the patch as I suggest, or anything else, what about your opinion?
Fix all the offending drivers which pass uninited variable into macro which might use it. That's the fix.
Thanks for your opinion.
I will send out the patch as you suggested to fix this issue.
Thanks!
This is about to be complicated / fixed by the NAND patches that I'm merging and pushing shortly, so hold on please!
On Wednesday, August 27, 2014 at 09:48:32 PM, Tom Rini wrote:
On Wed, Aug 27, 2014 at 07:45:57PM +0200, Marek Vasut wrote:
On Wednesday, August 27, 2014 at 09:39:04 AM, Bo Shen wrote:
Hi Marek,
On 08/26/2014 02:46 PM, Marek Vasut wrote:
On Tuesday, August 26, 2014 at 03:11:13 AM, Bo Shen wrote:
Hi Marek,
On 08/25/2014 06:43 PM, Marek Vasut wrote:
On Monday, August 25, 2014 at 11:23:19 AM, Bo Shen wrote: > When compile with debug information is enabled, if call > spin_lock_irqsave, it will give following warning information. > This patch is used to get rid of it. > --->8--- > warning: 'flags' is used uninitialized in this function > [-Wuninitialized] ---8<---
The patch is wrong. The compiler complains that flags might be used uninited because that is the case -- you call spin_lock_irqsave() with uninited flags and because debug() is expanded to printf() I guess, the compiler spews.
So which file does this warning come from ?
I enable debug information (In common.h, define the DEBUG).
It comes out from usb gadget driver, for example, atmel_usba_udc.c and also s3c_udc_otg.c and etc.
Then those need fixing. There is no problem with the macro.
I see the spin_lock_irqsave() function in <drivers/usb/musb-new/linux-compat.h> defined as: --->8--- #define spin_lock_irqsave(lock, flags) do {} while (0) ---8<---
As in u-boot, there is no lock actually, so I think we can fix it as <drivers/usb/musb-new/linux-compat.h>, or use the patch as I suggest, or anything else, what about your opinion?
Fix all the offending drivers which pass uninited variable into macro which might use it. That's the fix.
Thanks for your opinion.
I will send out the patch as you suggested to fix this issue.
Thanks!
This is about to be complicated / fixed by the NAND patches that I'm merging and pushing shortly, so hold on please!
Can you please point out the exact patches ? Also, this is USB stuff, how can this be affected by any MTD stuff (unless there is a problem with patch separation) ?
Best regards, Marek Vasut
On Wed, Aug 27, 2014 at 10:24:06PM +0200, Marek Vasut wrote:
On Wednesday, August 27, 2014 at 09:48:32 PM, Tom Rini wrote:
On Wed, Aug 27, 2014 at 07:45:57PM +0200, Marek Vasut wrote:
On Wednesday, August 27, 2014 at 09:39:04 AM, Bo Shen wrote:
Hi Marek,
On 08/26/2014 02:46 PM, Marek Vasut wrote:
On Tuesday, August 26, 2014 at 03:11:13 AM, Bo Shen wrote:
Hi Marek,
On 08/25/2014 06:43 PM, Marek Vasut wrote: > On Monday, August 25, 2014 at 11:23:19 AM, Bo Shen wrote: >> When compile with debug information is enabled, if call >> spin_lock_irqsave, it will give following warning information. >> This patch is used to get rid of it. >> --->8--- >> warning: 'flags' is used uninitialized in this function >> [-Wuninitialized] ---8<--- > > The patch is wrong. The compiler complains that flags might be used > uninited because that is the case -- you call spin_lock_irqsave() > with uninited flags and because debug() is expanded to printf() I > guess, the compiler spews. > > So which file does this warning come from ?
I enable debug information (In common.h, define the DEBUG).
It comes out from usb gadget driver, for example, atmel_usba_udc.c and also s3c_udc_otg.c and etc.
Then those need fixing. There is no problem with the macro.
I see the spin_lock_irqsave() function in <drivers/usb/musb-new/linux-compat.h> defined as: --->8--- #define spin_lock_irqsave(lock, flags) do {} while (0) ---8<---
As in u-boot, there is no lock actually, so I think we can fix it as <drivers/usb/musb-new/linux-compat.h>, or use the patch as I suggest, or anything else, what about your opinion?
Fix all the offending drivers which pass uninited variable into macro which might use it. That's the fix.
Thanks for your opinion.
I will send out the patch as you suggested to fix this issue.
Thanks!
This is about to be complicated / fixed by the NAND patches that I'm merging and pushing shortly, so hold on please!
Can you please point out the exact patches ? Also, this is USB stuff, how can this be affected by any MTD stuff (unless there is a problem with patch separation) ?
It's linux compat "fun", http://patchwork.ozlabs.org/patch/363333/
On Wednesday, August 27, 2014 at 11:20:45 PM, Tom Rini wrote: [...]
This is about to be complicated / fixed by the NAND patches that I'm merging and pushing shortly, so hold on please!
Can you please point out the exact patches ? Also, this is USB stuff, how can this be affected by any MTD stuff (unless there is a problem with patch separation) ?
It's linux compat "fun", http://patchwork.ozlabs.org/patch/363333/
OK, please update this thread when you merge that patch . And Bo, can you please verify after that update if this issue was resolved please ?
Best regards, Marek Vasut
Hi Marek,
On 08/28/2014 05:36 AM, Marek Vasut wrote:
On Wednesday, August 27, 2014 at 11:20:45 PM, Tom Rini wrote: [...]
This is about to be complicated / fixed by the NAND patches that I'm merging and pushing shortly, so hold on please!
Can you please point out the exact patches ? Also, this is USB stuff, how can this be affected by any MTD stuff (unless there is a problem with patch separation) ?
It's linux compat "fun", http://patchwork.ozlabs.org/patch/363333/
OK, please update this thread when you merge that patch . And Bo, can you please verify after that update if this issue was resolved please ?
OK, after this patch is merged, I will check it. Thanks.
Best regards, Marek Vasut
Best Regards, Bo Shen
On Wed, Aug 27, 2014 at 11:36:05PM +0200, Marek Vasut wrote:
On Wednesday, August 27, 2014 at 11:20:45 PM, Tom Rini wrote: [...]
This is about to be complicated / fixed by the NAND patches that I'm merging and pushing shortly, so hold on please!
Can you please point out the exact patches ? Also, this is USB stuff, how can this be affected by any MTD stuff (unless there is a problem with patch separation) ?
It's linux compat "fun", http://patchwork.ozlabs.org/patch/363333/
OK, please update this thread when you merge that patch . And Bo, can you please verify after that update if this issue was resolved please ?
OK, Heiko's patch applied now.
participants (3)
-
Bo Shen -
Marek Vasut -
Tom Rini