On Tue, 15 Mar 2011 20:54:43 +0000
Malcolm Priestley <tvbox...@gmail.com> wrote:

> The patch failed for the following reason.
> 
> On Tue, 2011-03-15 at 09:43 +0100, Florian Mickler wrote:
> > usb_control_msg initiates (and waits for completion of) a dma transfer using
> > the supplied buffer. That buffer thus has to be seperately allocated on
> > the heap.
> > 
> > In lib/dma_debug.c the function check_for_stack even warns about it:
> >     WARNING: at lib/dma-debug.c:866 check_for_stack
> > 
> > Note: This change is tested to compile only, as I don't have the hardware.
> > 
> > Signed-off-by: Florian Mickler <flor...@mickler.org>
> > ---
> >  drivers/media/dvb/dvb-usb/lmedm04.c |   16 +++++++++++++---
> >  1 files changed, 13 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c 
> > b/drivers/media/dvb/dvb-usb/lmedm04.c
> > index 0a3e88f..bec5439 100644
> > --- a/drivers/media/dvb/dvb-usb/lmedm04.c
> > +++ b/drivers/media/dvb/dvb-usb/lmedm04.c
> > @@ -314,12 +314,17 @@ static int lme2510_int_read(struct dvb_usb_adapter 
> > *adap)
> >  static int lme2510_return_status(struct usb_device *dev)
> >  {
> >     int ret = 0;
> > -   u8 data[10] = {0};
> > +   u8 *data;
> > +
> > +   data = kzalloc(10, GFP_KERNEL);
> > +   if (!data)
> > +           return -ENOMEM;
> >  
> >     ret |= usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
> >                     0x06, 0x80, 0x0302, 0x00, data, 0x0006, 200);
> >     info("Firmware Status: %x (%x)", ret , data[2]);
> >  
> > +   kfree(data);
> >     return (ret < 0) ? -ENODEV : data[2];
> 
> data has been killed off when we need the buffer contents.
> changing to the following fixed.
> 
>       ret = (ret < 0) ? -ENODEV : data[2];
> 
>       kfree(data);
> 
>       return ret;

Yes. Thanks. I updated the patch locally. 

> 
> > @@ -603,7 +608,7 @@ static int lme2510_download_firmware(struct usb_device 
> > *dev,
> >                                     const struct firmware *fw)
> >  {
> >     int ret = 0;
> > -   u8 data[512] = {0};
> > +   u8 *data;
> >     u16 j, wlen, len_in, start, end;
> >     u8 packet_size, dlen, i;
> >     u8 *fw_data;
> > @@ -611,6 +616,11 @@ static int lme2510_download_firmware(struct usb_device 
> > *dev,
> >     packet_size = 0x31;
> >     len_in = 1;
> >  
> > +   data = kzalloc(512, GFP_KERNEL);
> > +   if (!data) {
> > +           info("FRM Could not start Firmware Download (Buffer allocation 
> > failed)");
> 
> Longer than 80 characters, 

I choose to ignore this warning to keep the string on one line (for
grep and co).

> > +           return -ENOMEM;
> > +   }
> >  
> >     info("FRM Starting Firmware Download");
> >  
> > @@ -654,7 +664,7 @@ static int lme2510_download_firmware(struct usb_device 
> > *dev,
> >     else
> >             info("FRM Firmware Download Completed - Resetting Device");
> >  
> > -
> > +   kfree(data);
> >     return (ret < 0) ? -ENODEV : 0;
> >  }
> >  
> 
> Otherwise the patch as corrected has been put on test. No initial
> problems have been encountered.
> 
> Regards 
> 
> Malcolm
> 

Thanks. I added a 
Tested-by: Malcolm Priestley <tvbox...@gmail.com>,
if that is ok?

Do you know how often/when is the .identify_state callback called during
normal operation? I.e. is this memory allocation/deallocation
in lme2510_return_status happening often and should use a preallocated
buffer?

Regards,
Flo
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to