Dan Carpenter schrieb: > I changed the dma buffers to use allocated memory instead of stack > memory. > > The reason for this is documented in Documentation/DMA-API-HOWTO.txt > under the section: "What memory is DMA'able?" That document was only > added a couple weeks ago and there are still lots of modules which > haven't been corrected yet. Btw. Smatch includes a pretty good test to > find places which use stack memory as a dma buffer. That's how I found > these. (http://smatch.sf.net). > > Signed-off-by: Dan Carpenter <error27@xxxxxxxxx> > > diff --git a/drivers/media/dvb/dvb-usb/az6027.c b/drivers/media/dvb/dvb-usb/az6027.c > index 8934788..baaa301 100644 > --- a/drivers/media/dvb/dvb-usb/az6027.c > +++ b/drivers/media/dvb/dvb-usb/az6027.c > @@ -417,11 +417,15 @@ static int az6027_ci_read_attribute_mem(struct dvb_ca_en50221 *ca, > u16 value; > u16 index; > int blen; > - u8 b[12]; > + u8 *b; > > if (slot != 0) > return -EINVAL; > > + b = kmalloc(12, GFP_KERNEL); > + if (!b) > + return -ENOMEM; > + > mutex_lock(&state->ca_mutex); > > req = 0xC1; Hi Dan, i am not sure if that is the way to go. iff i understand the code correctly the b[12] seems to overcommit only blen bytes (not 12) is needed. There must be a cheaper way to send a few bytes of space to send a command to a device. Perhaps gregKH has a hint ? re, wh -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
