[U-Boot] [RFC PATCH] USB: get rid of warning when compile with debug enabled

[Marek Vasut]

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