Re: [PATCH 09/26] dibusb: don't do DMA on stack

On Fri, 7 Oct 2016 14:24:19 -0300 Mauro Carvalho Chehab wrote: > The USB control messages require DMA to work. We cannot pass > a stack-allocated buffer, as it is not warranted that the > stack would be into a DMA enabled area. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/us

Re: [PATCH 07/26] dib0700: be sure that dib0700_ctrl_rd() users can do DMA

On Fri, 7 Oct 2016 14:24:17 -0300 Mauro Carvalho Chehab wrote: > dib0700_ctrl_rd() takes a RX and a TX pointer. Be sure that > both will point to a memory allocated via kmalloc(). > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/usb/dvb-usb/dib0700_core.c| 4 +++- > drivers

Re: [PATCH 05/26] cinergyT2-fe: don't do DMA on stack

On Fri, 7 Oct 2016 14:24:15 -0300 Mauro Carvalho Chehab wrote: > The USB control messages require DMA to work. We cannot pass > a stack-allocated buffer, as it is not warranted that the > stack would be into a DMA enabled area. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/us

Re: [PATCH 06/26] cxusb: don't do DMA on stack

On Fri, 7 Oct 2016 14:24:16 -0300 Mauro Carvalho Chehab wrote: > The USB control messages require DMA to work. We cannot pass > a stack-allocated buffer, as it is not warranted that the > stack would be into a DMA enabled area. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/us

Re: [PATCH 02/26] cinergyT2-core: don't do DMA on stack

On Fri, 7 Oct 2016 14:24:12 -0300 Mauro Carvalho Chehab wrote: > The USB control messages require DMA to work. We cannot pass > a stack-allocated buffer, as it is not warranted that the > stack would be into a DMA enabled area. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/us

Re: [PATCH 08/26] dib0700_core: don't use stack on I2C reads

On Fri, 7 Oct 2016 14:24:18 -0300 Mauro Carvalho Chehab wrote: > Be sure that I2C reads won't use stack by passing > a pointer to the state buffer, that we know it was > allocated via kmalloc, instead of relying on the buffer > allocated by an I2C client. > > Signed-off-by: Mauro Carvalho Cheha

Re: [PATCH 11/26] digitv: don't do DMA on stack

On Fri, 7 Oct 2016 14:24:21 -0300 Mauro Carvalho Chehab wrote: > The USB control messages require DMA to work. We cannot pass > a stack-allocated buffer, as it is not warranted that the > stack would be into a DMA enabled area. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/us

Re: [PATCH 14/26] dtt200u: don't do DMA on stack

On Fri, 7 Oct 2016 14:24:24 -0300 Mauro Carvalho Chehab wrote: > From: Mauro Carvalho Chehab > > The USB control messages require DMA to work. We cannot pass > a stack-allocated buffer, as it is not warranted that the > stack would be into a DMA enabled area. > > Signed-off-by: Mauro Carvalho

Re: [PATCH 19/26] nova-t-usb2: don't do DMA on stack

On Fri, 7 Oct 2016 14:24:29 -0300 Mauro Carvalho Chehab wrote: > The USB control messages require DMA to work. We cannot pass > a stack-allocated buffer, as it is not warranted that the > stack would be into a DMA enabled area. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/us

Re: [PATCH 20/26] pctv452e: don't do DMA on stack

On Fri, 7 Oct 2016 14:24:30 -0300 Mauro Carvalho Chehab wrote: > The USB control messages require DMA to work. We cannot pass > a stack-allocated buffer, as it is not warranted that the > stack would be into a DMA enabled area. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/us

Re: [PATCH 22/26] technisat-usb2: use DMA buffers for I2C transfers

On Fri, 7 Oct 2016 14:24:32 -0300 Mauro Carvalho Chehab wrote: > The USB control messages require DMA to work. We cannot pass > a stack-allocated buffer, as it is not warranted that the > stack would be into a DMA enabled area. > > On this driver, most of the transfers are OK, but the I2C > one

Re: RFC - unclear change in "[media] DiBxxxx: Codingstype updates"

Hi, der Herr Hofrat ;-) On Sat, 8 Oct 2016 13:57:14 + Nicholas Mc Guire wrote: > - lo6 |= (1 << 2) | 2; > - else > - lo6 |= (1 << 2) | 1; > + lo6 |= (1 << 2) | 2;//SigmaDelta and Dither > + else { > + if (stat

cron job: media_tree daily build: ERRORS

This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Oct 10 05:00:16 CEST 2016 media-tree git hash:9fce0c226536fc36c7fb0a8ca38a995be43e media_build gi

[PATCH 2/2] [media] blackfin-capture: Delete an error message for a failed memory allocation

From: Markus Elfring Date: Sun, 9 Oct 2016 21:30:18 +0200 The script "checkpatch.pl" pointed information out like the following. WARNING: Possible unnecessary 'out of memory' message Thus remove such a statement here. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Ref

[PATCH 1/2] [media] blackfin-capture: Use kcalloc() in bcap_init_sensor_formats()

From: Markus Elfring Date: Sun, 9 Oct 2016 21:12:13 +0200 A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus reuse the corresponding function "kcalloc". This issue was detected by using the Coccinelle software. Sig

[PATCH 0/2] [media] blackfin-capture: Fine-tuning for two function implementations

From: Markus Elfring Date: Sun, 9 Oct 2016 21:44:33 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Use kcalloc() in bcap_init_sensor_formats() Delete an error message for a failed memory allocation in bcap_probe() drivers/media/

Re: [PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels

Hi Rob, On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote: > On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote: > > LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. > > Multiple incompatible data link layers have been used over time to > > transmit image data t