Re: [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq

[Sergei Shtylyov]

On 12/27/2015 9:13 AM, Julia Lawall wrote:


Well, looking again, the patch should be good. I just thought its goal was
to fix the code as well...


I could do that for the irq < 0 case, but I think that in that case, kbuild
will only run the patch version, and the <= cases will not be reported on.
I don't have a general fix for the <= 0.  Is it even correct to have < in
some cases and <= in others?


   That's a good question...
   In my prior fixes of this case I preferred to consider IRQ0 valid and so 
used 'irq < 0'. I myself don't share the "IRQ0 is invalid" sentiment...



julia


MBR, Sergei

--
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

Probably a new board ID for em28xx: [1b80:e349]

[Peter Schlaf]

Hi,

I have a small usb-device with s-vhs, composite-video and stereo-audio 
cabels attached.


The shell just says "MAGIX" and "Made in China". It has also a black 
button to push.


I plugged it in to get some video grabbed but no /dev/videoX was created.

"lsusb" output:

Bus 003 Device 012: ID 1b80:e349 Afatech

journalctl -f output:

kernel: usb 3-1.1: new high-speed USB device number 12 using 
ehci-pci
kernel: usb 3-1.1: New USB device found, idVendor=1b80, 
idProduct=e349
kernel: usb 3-1.1: New USB device strings: Mfr=0, Product=1, 
SerialNumber=0

kernel: usb 3-1.1: Product: USB 2861 Device
mtp-probe[7688]: checking bus 3, device 12: 
"/sys/devices/pci:00/:00:1a.0/usb3/3-1/3-1.1"

mtp-probe[7688]: bus: 3, device: 12 was not an MTP device

Kernel is 4.1.13-5-default on openSuse 42.1

I opened that thing and found these chips:

  SAA7113H
  EM2860
  EMP202

I did
  modprobe em28xx
  modprobe saa7115

but still got no video-device.


(I use an application called "cheese" which works perfect with my other 
usb videograbbing device.)


Is there anything else I can do?


CU
Peter

--
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

Re: [Cocci] [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq

[Julia Lawall]

On Sun, 27 Dec 2015, SF Markus Elfring wrote:

> > The error return value of platform_get_irq seems to often get dropped.
> 
> How do you think about any more fine-tuning here?
> 
> Commit message:
> * … of the platform_get_irq() function seems to get dropped too often.
> 
> * Why do you concentrate on a single function name?
>   Do you plan to extend this source code analysis approach?
> 
> 
> > +@script:python r_report depends on report@
> > +j0 << r.j0;
> > +j1 << r.j1;
> > +@@
> > +
> > +msg = "Propagate return value of platform_get_irq around line %s." % 
> > (j1[0].line)
> 
> Are there more unchecked return values which are interesting
> for further considerations?
> https://cwe.mitre.org/data/definitions/252.html

The value is not unchecked.  I made a specific rule because the specific 
problem is quite common.

julia

[v4l-utils PATCH] man: Fix typos in dvbv5-scan dvbv5-zap pages

[Chris Mayo]

Signed-off-by: Chris Mayo 
---
 utils/dvb/dvbv5-scan.1.in | 2 +-
 utils/dvb/dvbv5-zap.1.in  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/utils/dvb/dvbv5-scan.1.in b/utils/dvb/dvbv5-scan.1.in
index 8958ceb..e6fe3ee 100644
--- a/utils/dvb/dvbv5-scan.1.in
+++ b/utils/dvb/dvbv5-scan.1.in
@@ -172,7 +172,7 @@ New transponder/channel found: #39: 50700
 .fi
 .PP
 The scan process will then scan the other 38 discovered new transponders,
-and generate a dvb_channel.com with several entries with will have not only
+and generate a dvb_channel.conf with several entries with will have not only
 the physical channel/transponder info, but also the Service ID, and the
 corresponding audio/video/other program IDs (PID), like:
 .PP
diff --git a/utils/dvb/dvbv5-zap.1.in b/utils/dvb/dvbv5-zap.1.in
index 9bf2687..2445593 100644
--- a/utils/dvb/dvbv5-zap.1.in
+++ b/utils/dvb/dvbv5-zap.1.in
@@ -167,7 +167,7 @@ DVR interface '/dev/dvb/adapter0/dvr0' can now be opened
 The channel can be watched by playing the contents of the DVR interface,
 with some player that recognizes the MPEG\-TS format.
 .PP
-For example, this audio-only channel can be playew with mplayer:
+For example, this audio-only channel can be played with mplayer:
 .PP
 .nf
 $ \fBmplayer \-cache 800 /dev/dvb/adapter0/dvr0\fR
-- 
2.4.10

--
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

PCIe sg dma device used as dma-contig

[Ran Shalit]

Hello,

The following question is not totally in the scope of v4l2, but more
about your advise concering dma alternatives for non-expreciened v4l2
device writer.
We intend to use the fpga for concurrent 3xHD and 3xSD.

We have some dillema regadring the fpga to choose from:
ALTERA fpga which use contiguous dma memory, or Xilinx fpga which is
using scatter-gather architecture.

With xilinx, it seems that the sg architecture can also be used as
contiguous according to the following:
"... While these descriptors are not required to be contiguous, they
should be contained within an 8 megabyte region which corresponds to
the width of the AXI_PCIe_SG port"
it seems according to the above description that sg-list can be used
as single contiguous descriptor (with dma-cotig), though the 8MBytes
seems like a problematic constrain. This constrain make it difficult
to be used with dma-contig solution in v4l2.

Our current direction is try to imeplement it as simple as possible.
Therefore we prefer the dma contiguous solution (I think that together
with CMA and a strong cpu like 64-bit i7 it can handle contigious
memory for 3xHD and 3xSD allocation).

Any feedback is appreciated,
Ran
--
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

Re: [Cocci] [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq

[SF Markus Elfring]

>> https://cwe.mitre.org/data/definitions/252.html
> 
> The value is not unchecked.

Would you like to express any stronger relationship between
the function call example and the occurrence of an if statement
by the discussed SmPL script?


> I made a specific rule because the specific problem is quite common.

Can it become also interesting to generalise this search pattern?

Regards,
Markus
--
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

[media] af9013: Checking for register accesses?

[SF Markus Elfring]

Hello,

I have looked at the implementations of functions like the following once more.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/media/dvb-frontends/af9013.c?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n124
* af9013_rd_regs
* af9013_wr_regs

Both functions will always return zero so far. Should they eventually forward
an error code from other function calls?

Regards,
Markus
--
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

Re: [PATCH v3 00/23] Unrestricted media entity ID range support

[Laurent Pinchart]

Hi Mauro,

On Wednesday 23 December 2015 10:32:42 Mauro Carvalho Chehab wrote:
> Em Wed, 16 Dec 2015 16:03:01 +0200 Sakari Ailus escreveu:
> > On Wed, Dec 16, 2015 at 03:32:15PM +0200, Sakari Ailus wrote:
> > > This is the third version of the unrestricted media entity ID range
> > > support set. I've taken Mauro's comments into account and fixed a number
> > > of bugs as well (omap3isp memory leak and omap4iss stream start).
> > 
> > Javier: Mauro told me you might have OMAP4 hardware. Would you be able to
> > test the OMAP4 ISS with these patches?
> > 
> > Thanks.
> 
> Sakari,
> 
> Testing with OMAP4 is not possible. The driver is broken: it doesn't
> support DT, and the required pdata definition is missing.

What do you mean by missing ? struct iss_platform_data is defined in 
include/media/omap4iss.h.

> Both Javier and I tried to fix it in the last couple days, in order to test
> it with a PandaBoard. We came with the enclosed patch, but it is still
> incomplete. Based on what's written on this e-mail:
>https://www.mail-archive.com/linux-media@vger.kernel.org/msg89247.html
> 
> It seems that this is an already known issue.
> 
> So, I'm considering this driver as BROKEN. Not much sense on doing any
> tests on it, while this doesn't get fixed.
> 
> Regards,
> Mauro
> 
> PS.: With the enclosed patch, I got this error:
>   [0.267639] platform omap4iss: failed to claim resource 2
> 
> But, even if I comment out the platform code that returns this error,
> there are still other missing things:
>   [7.131622] omap4iss omap4iss: Unable to get iss_fck clock info
>   [7.137878] omap4iss omap4iss: Unable to get clocks
> 
> ---
> 
> ARM: add a pdata quirks for OMAP4 panda camera
> 
> This is a hack to make it to believe that the pandaboard
> has a camera.
> 
> 
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c
> b/arch/arm/mach-omap2/pdata-quirks.c index 1dfe34654c43..998bb6936dc0
> 100644
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -36,6 +36,8 @@
>  #include "soc.h"
>  #include "hsmmc.h"
> 
> +#include "../../../drivers/staging/media/omap4iss/iss.h"
> +
>  struct pdata_init {
>   const char *compatible;
>   void (*fn)(void);
> @@ -408,6 +410,124 @@ static void __init t410_abort_init(void)
>  }
>  #endif
> 
> +#ifdef CONFIG_ARCH_OMAP4
> +
> +static struct resource panda_iss_resource[] = {
> + {
> + .start = 0x5200,
> + .end = 0x5200 + 0x100,
> + .name = "top",
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = 0x52001000,
> + .end = 0x52001000 + 0x170,
> + .name = "csi2_a_regs1",
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = 0x52001170,
> + .end = 0x52001170 + 0x020,
> + .name = "camerarx_core1",
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = 0x52001400,
> + .end = 0x52001400 + 0x170,
> + .name = "csi2_b_regs1",
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = 0x52001570,
> + .end = 0x52001570 + 0x020,
> + .name = "camerarx_core2",
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = 0x52002000,
> + .end = 0x52002000 + 0x200,
> + .name = "bte",
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = 0x5201,
> + .end = 0x5201 + 0x0a0,
> + .name = "isp_sys1",
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = 0x52010400,
> + .end = 0x52010400 + 0x400,
> + .name = "isp_resizer",
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = 0x52010800,
> + .end = 0x52010800 + 0x800,
> + .name = "isp_ipipe",
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = 0x52011000,
> + .end = 0x52011000 + 0x200,
> + .name = "isp_isif",
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = 0x52011200,
> + .end = 0x52011200 + 0x080,
> + .name = "isp_ipipeif",
> + .flags = IORESOURCE_MEM,
> + }
> +};
> +
> +static struct i2c_board_info panda_camera_i2c_device = {
> + I2C_BOARD_INFO("smia", 0x10),
> +};
> +
> +static struct iss_subdev_i2c_board_info panda_camera_subdevs[] = {
> + {
> + .board_info = _camera_i2c_device,
> + .i2c_adapter_id = 3,
> + },
> +};
> +
> +static struct iss_v4l2_subdevs_group iss_subdevs[] = {
> + {
> + .subdevs = panda_camera_subdevs,
> + .interface = ISS_INTERFACE_CSI2A_PHY1,
> + .bus = {
> + .csi2 = {
> + .lanecfg = {
> + .clk = {
> + .pol = 0,
> +   

[PATCH] [media] bttv: Returning only value constants in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 27 Dec 2015 22:02:21 +0100

Return constant integer values without storing them in the local
variable "err" or "rc".

Signed-off-by: Markus Elfring 
---
 drivers/media/pci/bt8xx/bttv-driver.c | 25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/drivers/media/pci/bt8xx/bttv-driver.c 
b/drivers/media/pci/bt8xx/bttv-driver.c
index 9400e99..cd7d6ef 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -1726,22 +1726,15 @@ static int bttv_s_std(struct file *file, void *priv, 
v4l2_std_id id)
struct bttv_fh *fh  = priv;
struct bttv *btv = fh->btv;
unsigned int i;
-   int err = 0;
 
for (i = 0; i < BTTV_TVNORMS; i++)
if (id & bttv_tvnorms[i].v4l2_id)
break;
-   if (i == BTTV_TVNORMS) {
-   err = -EINVAL;
-   goto err;
-   }
-
+   if (i == BTTV_TVNORMS)
+   return -EINVAL;
btv->std = id;
set_tvnorm(btv, i);
-
-err:
-
-   return err;
+   return 0;
 }
 
 static int bttv_g_std(struct file *file, void *priv, v4l2_std_id *id)
@@ -1770,12 +1763,9 @@ static int bttv_enum_input(struct file *file, void *priv,
 {
struct bttv_fh *fh = priv;
struct bttv *btv = fh->btv;
-   int rc = 0;
 
-   if (i->index >= bttv_tvcards[btv->c.type].video_inputs) {
-   rc = -EINVAL;
-   goto err;
-   }
+   if (i->index >= bttv_tvcards[btv->c.type].video_inputs)
+   return -EINVAL;
 
i->type = V4L2_INPUT_TYPE_CAMERA;
i->audioset = 0;
@@ -1799,10 +1789,7 @@ static int bttv_enum_input(struct file *file, void *priv,
}
 
i->std = BTTV_NORMS;
-
-err:
-
-   return rc;
+   return 0;
 }
 
 static int bttv_g_input(struct file *file, void *priv, unsigned int *i)
-- 
2.6.3

--
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

[PATCH] media: dvb_ringbuffer: Add memory barriers

[Soeren Moch]

Implement memory barriers according to Documentation/circular-buffers.txt:
- use smp_store_release() to update ringbuffer read/write pointers
- use smp_load_acquire() to load write pointer on reader side
- use ACCESS_ONCE() to load read pointer on writer side

This fixes data stream corruptions observed e.g. on an ARM Cortex-A9
quad core system with different types (PCI, USB) of DVB tuners.

Signed-off-by: Soeren Moch 
Cc: sta...@vger.kernel.org # 3.14+
---
Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org

Since smp_store_release() and smp_load_acquire() were introduced in linux-3.14,
a 3.14+ stable tag was added. Is it desired to apply a similar patch to older
stable kernels?
---
 drivers/media/dvb-core/dvb_ringbuffer.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_ringbuffer.c 
b/drivers/media/dvb-core/dvb_ringbuffer.c
index 1100e98..58b5968 100644
--- a/drivers/media/dvb-core/dvb_ringbuffer.c
+++ b/drivers/media/dvb-core/dvb_ringbuffer.c
@@ -55,7 +55,7 @@ void dvb_ringbuffer_init(struct dvb_ringbuffer *rbuf, void 
*data, size_t len)
 
 int dvb_ringbuffer_empty(struct dvb_ringbuffer *rbuf)
 {
-   return (rbuf->pread==rbuf->pwrite);
+   return (rbuf->pread == smp_load_acquire(>pwrite));
 }
 
 
@@ -64,7 +64,7 @@ ssize_t dvb_ringbuffer_free(struct dvb_ringbuffer *rbuf)
 {
ssize_t free;
 
-   free = rbuf->pread - rbuf->pwrite;
+   free = ACCESS_ONCE(rbuf->pread) - rbuf->pwrite;
if (free <= 0)
free += rbuf->size;
return free-1;
@@ -76,7 +76,7 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
 {
ssize_t avail;
 
-   avail = rbuf->pwrite - rbuf->pread;
+   avail = smp_load_acquire(>pwrite) - rbuf->pread;
if (avail < 0)
avail += rbuf->size;
return avail;
@@ -86,14 +86,15 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
 
 void dvb_ringbuffer_flush(struct dvb_ringbuffer *rbuf)
 {
-   rbuf->pread = rbuf->pwrite;
+   smp_store_release(>pread, smp_load_acquire(>pwrite));
rbuf->error = 0;
 }
 EXPORT_SYMBOL(dvb_ringbuffer_flush);
 
 void dvb_ringbuffer_reset(struct dvb_ringbuffer *rbuf)
 {
-   rbuf->pread = rbuf->pwrite = 0;
+   smp_store_release(>pread, 0);
+   smp_store_release(>pwrite, 0);
rbuf->error = 0;
 }
 
@@ -119,12 +120,12 @@ ssize_t dvb_ringbuffer_read_user(struct dvb_ringbuffer 
*rbuf, u8 __user *buf, si
return -EFAULT;
buf += split;
todo -= split;
-   rbuf->pread = 0;
+   smp_store_release(>pread, 0);
}
if (copy_to_user(buf, rbuf->data+rbuf->pread, todo))
return -EFAULT;
 
-   rbuf->pread = (rbuf->pread + todo) % rbuf->size;
+   smp_store_release(>pread, (rbuf->pread + todo) % rbuf->size);
 
return len;
 }
@@ -139,11 +140,11 @@ void dvb_ringbuffer_read(struct dvb_ringbuffer *rbuf, u8 
*buf, size_t len)
memcpy(buf, rbuf->data+rbuf->pread, split);
buf += split;
todo -= split;
-   rbuf->pread = 0;
+   smp_store_release(>pread, 0);
}
memcpy(buf, rbuf->data+rbuf->pread, todo);
 
-   rbuf->pread = (rbuf->pread + todo) % rbuf->size;
+   smp_store_release(>pread, (rbuf->pread + todo) % rbuf->size);
 }
 
 
@@ -158,10 +159,10 @@ ssize_t dvb_ringbuffer_write(struct dvb_ringbuffer *rbuf, 
const u8 *buf, size_t
memcpy(rbuf->data+rbuf->pwrite, buf, split);
buf += split;
todo -= split;
-   rbuf->pwrite = 0;
+   smp_store_release(>pwrite, 0);
}
memcpy(rbuf->data+rbuf->pwrite, buf, todo);
-   rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size;
+   smp_store_release(>pwrite, (rbuf->pwrite + todo) % rbuf->size);
 
return len;
 }
@@ -181,12 +182,12 @@ ssize_t dvb_ringbuffer_write_user(struct dvb_ringbuffer 
*rbuf,
return len - todo;
buf += split;
todo -= split;
-   rbuf->pwrite = 0;
+   smp_store_release(>pwrite, 0);
}
status = copy_from_user(rbuf->data+rbuf->pwrite, buf, todo);
if (status)
return len - todo;
-   rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size;
+   smp_store_release(>pwrite, (rbuf->pwrite + todo) % rbuf->size);
 
return len;
 }
-- 
1.9.1

--
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

[PATCH] [media] si2165: Refactoring for si2165_writereg_mask8()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 27 Dec 2015 18:23:57 +0100

This issue was detected by using the Coccinelle software.

1. Let us return directly if a call of the si2165_readreg8()
   function failed.

2. Reduce the scope for the local variables "ret" and "tmp" to one branch
   of an if statement.

3. Delete the jump label "err" then.

4. Return the value from a call of the si2165_writereg8() function
   without using an extra assignment for the variable "ret" at the end.

Signed-off-by: Markus Elfring 
---
 drivers/media/dvb-frontends/si2165.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 2b93241..e8518ae 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -225,22 +225,18 @@ static int si2165_writereg32(struct si2165_state *state, 
const u16 reg, u32 val)
 static int si2165_writereg_mask8(struct si2165_state *state, const u16 reg,
 u8 val, u8 mask)
 {
-   int ret;
-   u8 tmp;
-
if (mask != 0xff) {
-   ret = si2165_readreg8(state, reg, );
+   u8 tmp;
+   int ret = si2165_readreg8(state, reg, );
+
if (ret < 0)
-   goto err;
+   return ret;
 
val &= mask;
tmp &= ~mask;
val |= tmp;
}
-
-   ret = si2165_writereg8(state, reg, val);
-err:
-   return ret;
+   return si2165_writereg8(state, reg, val);
 }
 
 #define REG16(reg, val) { (reg), (val) & 0xff }, { (reg)+1, (val)>>8 & 0xff }
-- 
2.6.3

--
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

Re: [Cocci] [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq

[SF Markus Elfring]

> The error return value of platform_get_irq seems to often get dropped.

How do you think about any more fine-tuning here?

Commit message:
* … of the platform_get_irq() function seems to get dropped too often.

* Why do you concentrate on a single function name?
  Do you plan to extend this source code analysis approach?


> +@script:python r_report depends on report@
> +j0 << r.j0;
> +j1 << r.j1;
> +@@
> +
> +msg = "Propagate return value of platform_get_irq around line %s." % 
> (j1[0].line)

Are there more unchecked return values which are interesting
for further considerations?
https://cwe.mitre.org/data/definitions/252.html

Regards,
Markus
--
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

Re: [PATCH 1/1] v4l: subdev: Register the entity before calling subdev's registered op

[kbuild test robot]

[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]
Hi Sakari,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.4-rc6 next-20151223]

url:
https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-subdev-Register-the-entity-before-calling-subdev-s-registered-op/20151228-074927
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-x016-201552 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/v4l2-core/v4l2-device.c: In function 
'v4l2_device_register_subdev':
>> drivers/media/v4l2-core/v4l2-device.c:210:33: error: 'entity' undeclared 
>> (first use in this function)
 media_device_unregister_entity(entity);
^
   drivers/media/v4l2-core/v4l2-device.c:210:33: note: each undeclared 
identifier is reported only once for each function it appears in

vim +/entity +210 drivers/media/v4l2-core/v4l2-device.c

   204  list_add_tail(>list, _dev->subdevs);
   205  spin_unlock(_dev->lock);
   206  
   207  return 0;
   208  
   209  error_unregister:
 > 210  media_device_unregister_entity(entity);
   211  error_module:
   212  if (!sd->owner_v4l2_dev)
   213  module_put(sd->owner);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 2/2] [media] media: move MEDIA_LNK_FL_INTERFACE_LINK logic to link creation

[Sakari Ailus]

Hi Mauro,

(Resending, there was an error in handling the cc field.)

On Fri, Dec 11, 2015 at 06:17:53PM -0200, Mauro Carvalho Chehab wrote:
> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index 181ca0de6e52..7895e17aeee9 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -526,7 +526,7 @@ media_create_pad_link(struct media_entity *source, u16 
> source_pad,
>  
>   link->source = >pads[source_pad];
>   link->sink = >pads[sink_pad];
> - link->flags = flags;
> + link->flags = flags && ~MEDIA_LNK_FL_INTERFACE_LINK;

s/&&/&/

>  
>   /* Initialize graph object embedded at the new link */
>   media_gobj_create(source->graph_obj.mdev, MEDIA_GRAPH_LINK,
> @@ -756,7 +756,7 @@ struct media_link *media_create_intf_link(struct 
> media_entity *entity,
>  
>   link->intf = intf;
>   link->entity = entity;
> - link->flags = flags;
> + link->flags = flags | MEDIA_LNK_FL_INTERFACE_LINK;
>  
>   /* Initialize graph object embedded at the new link */
>   media_gobj_create(intf->graph_obj.mdev, MEDIA_GRAPH_LINK,

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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

[PATCH 1/1] v4l: subdev: Register the entity before calling subdev's registered op

[Sakari Ailus]

Registering a V4L2 sub-device includes, among other things, registering
the related media entity and calling the sub-device's registered op. Since
patch "media: convert links from array to list", creating a link between
two pads requires registering the entity first. If the registered() op
involves link creation, the link list head will not be initialised before
it is used.

Resolve this by first registering the entity, then calling its
registered() op.

Signed-off-by: Sakari Ailus 
---
Hi Mauro,

You seem to be missing this patch from your media-controller-rc4 branch.
Not having it breaks at least the smiapp driver. I was pretty sure to have
sent it but I can't find it on linux-media. Oh well.

Speaking of the entity function warnings --- I'd omit them until we've
agreed that this is what we should really have (I don't think so). I can
submit a patch to remove them if you like.

--8<
[  108.919189] omap3isp 480bc000.isp: Entity type for entity jt8ew9 binner 
1-0010 was not initialized!
[  108.929046] Unable to handle kernel NULL pointer dereference at virtual 
address 
[  108.937652] pgd = ed0b8000
[  108.940521] [] *pgd=aefc3831, *pte=, *ppte=
[  108.947204] Internal error: Oops: 817 [#1] ARM
[  108.951904] Modules linked in: smiapp(+) smiapp_pll omap3_isp 
videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common 
videodev media
[  108.966735] CPU: 0 PID: 1163 Comm: modprobe Not tainted 
4.4.0-rc2-00328-g40e950d #507
[  108.975006] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[  108.981597] task: eeb91340 ti: eec6e000 task.ti: eec6e000
[  108.987335] PC is at media_add_link+0x34/0x44 [media]
[  108.992645] LR is at 0x0
[  108.995330] pc : []lr : [<>]psr: a013
[  108.995330] sp : eec6fc78  ip :   fp : 
[  109.007415] r10:   r9 : 0003  r8 : 1c40
[  109.012939] r7 :   r6 : 001c  r5 : ee9a7248  r4 : ee9a70c4
[  109.019805] r3 :   r2 : 1c10  r1 : ee8000c0  r0 : 1c00
[  109.026672] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  109.034210] Control: 10c5387d  Table: ad0b8019  DAC: 0051
[  109.040252] Process modprobe (pid: 1163, stack limit = 0xeec6e208)
[  109.046752] Stack: (0xeec6fc78 to 0xeec7)
[  109.051361] fc60:   
ee9a7098 bf0021b4
[  109.059997] fc80:  ee9a7010 eec6fcbc eea1fc00 ee9a7248  
eec6fcc0 ee9a7098
[  109.068634] fca0: 0136 bf09c520 0003 ee9a7140 eeb91340 ee9a7098 
ee9a7248 ee9a73f8
[  109.077270] fcc0: ee9a7010 ee9a7098 eefd0010 ed08f620  bf024d8c 
035a 1dc13000
[  109.085906] fce0:  bf014488 eefd0084 ee9a7098 ed08f620  
bf024d8c bf01d384
[  109.094543] fd00: ee9a7140 eefd0090 ed08f620 bf024d48 ee9a7098 eefd0084 
ee9a7140 bf01d444
[  109.103179] fd20: 6650 eea1fc00 ee9a7010 66c0 0003 bf09c3f8 
1dc13000 
[  109.111785] fd40: 0002 c02bab44 ef7e2994  eea1fc00 bf09c13c 
bf09eba4 eea1fc04
[  109.120422] fd60:  eea1fc20 eec6ff0c c028b7dc eea1fc20 bf09ebc0 
 c0dce564
[  109.129058] fd80: 0002   c02112dc bf09ebc0 eea1fc20 
 0002
[  109.137695] fda0: eea1fc20 eea1fc54 bf09ebc0  c05908e0 c02115c8 
bf09ebc0 eec6fdc8
[  109.146331] fdc0: c0211560 c020f8ac ee92c6a4 eea78410 bf09ebc0 bf09ebc0 
ee9ec240 c05d1e74
[  109.154968] fde0: c05908e0 c0210110 bf09d8ec eec6fd90 bf09ebc0 bf0a3000 
 c0211cc4
[  109.163604] fe00: bf09eba4 bf0a3000  c028bd94 6780 bf0a3000 
 c0009784
[  109.172241] fe20: efdd6ca0 efdd6cc0  0001  c009709c 
eeb91340 efdd6ca0
[  109.180877] fe40:  c0063428   eeb91340 0001 
c00c4f1c eedb13c0
[  109.189514] fe60: 0018 c005fdc8 024000c0 ee8000c0 6013 bf09f340 
eec6ff48 eedb13c0
[  109.198150] fe80: 0001 0018   eec6ff0c c008ac94 
bf09f340 
[  109.206756] fea0: efd99ff4 bf09f340 eec6ff48 bf09f34c 0001 c008c634 
8000 7fff
[  109.215393] fec0:  c008a8f4 f163a300 f163a448 07d0 0186 
0001cfc0 f16b9e80
[  109.224029] fee0:       
bf09f344 eec6ff1c
[  109.232666] ff00: 1c02 c019cf24 2013 c050e0b8 0055 0001 
0001 b6dfdea8
[  109.241302] ff20: 6ea8 0001cfc0  f16b9ea8 eec6e000 0051 
0001cf48 c008cb04
[  109.249938] ff40: 6013 c005dcf4 f1633000 00086ea8 f16b96b0 f1697f05 
f1699958 7560
[  109.258575] ff60: 8670 bf09ef90 0025  0031 0032 
0017 001b
[  109.267211] ff80: 0010  0001b070 0001b070   
0080 c000fa44
[  109.275848] ffa0:  c000f8a0 0001b070  b6d77000 00086ea8 
0001cfc0 
[  109.284484] ffc0: 0001b070   0080  0001cfe0 
 0001cf48
[  

Re: [PATCH 2/2] [media] media-device: split media initialization and registration

[Sakari Ailus]

Hi Mauro,

On Tue, Dec 15, 2015 at 09:13:42AM -0200, Mauro Carvalho Chehab wrote:
> Em Thu, 10 Sep 2015 20:14:04 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Javier,
> > 
> > Thanks for the set! A few comments below.
> > 
> > Javier Martinez Canillas wrote:
> > > The media device node is registered and so made visible to user-space
> > > before entities are registered and links created which means that the
> > > media graph obtained by user-space could be only partially enumerated
> > > if that happens too early before all the graph has been created.
> > > 
> > > To avoid this race condition, split the media init and registration
> > > in separate functions and only register the media device node when
> > > all the pending subdevices have been registered, either explicitly
> > > by the driver or asynchronously using v4l2_async_register_subdev().
> > > 
> > > Also, add a media_entity_cleanup() function that will destroy the
> > > graph_mutex that is initialized in media_entity_init().
> > > 
> > > Suggested-by: Sakari Ailus 
> > > Signed-off-by: Javier Martinez Canillas 
> > > 
> > > ---
> > > 
> > >  drivers/media/common/siano/smsdvb-main.c  |  1 +
> > >  drivers/media/media-device.c  | 38 
> > > +++
> > >  drivers/media/platform/exynos4-is/media-dev.c | 12 ++---
> > >  drivers/media/platform/omap3isp/isp.c | 11 +---
> > >  drivers/media/platform/s3c-camif/camif-core.c | 13 ++---
> > >  drivers/media/platform/vsp1/vsp1_drv.c| 19 ++
> > >  drivers/media/platform/xilinx/xilinx-vipp.c   | 11 +---
> > >  drivers/media/usb/au0828/au0828-core.c| 26 +-
> > >  drivers/media/usb/cx231xx/cx231xx-cards.c | 22 +++-
> > >  drivers/media/usb/dvb-usb-v2/dvb_usb_core.c   | 11 +---
> > >  drivers/media/usb/dvb-usb/dvb-usb-dvb.c   | 13 ++---
> > >  drivers/media/usb/siano/smsusb.c  | 14 --
> > >  drivers/media/usb/uvc/uvc_driver.c|  9 +--
> > >  include/media/media-device.h  |  2 ++
> > >  14 files changed, 156 insertions(+), 46 deletions(-)
> > > 
> > > diff --git a/drivers/media/common/siano/smsdvb-main.c 
> > > b/drivers/media/common/siano/smsdvb-main.c
> > > index ab345490a43a..8a1ea2192439 100644
> > > --- a/drivers/media/common/siano/smsdvb-main.c
> > > +++ b/drivers/media/common/siano/smsdvb-main.c
> > > @@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct 
> > > smsdvb_client_t *client)
> > >   if (!coredev->media_dev)
> > >   return;
> > >   media_device_unregister(coredev->media_dev);
> > > + media_device_cleanup(coredev->media_dev);
> > >   kfree(coredev->media_dev);
> > >   coredev->media_dev = NULL;
> > >  #endif
> > > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> > > index 745defb34b33..a8beb0b445a6 100644
> > > --- a/drivers/media/media-device.c
> > > +++ b/drivers/media/media-device.c
> > > @@ -526,7 +526,7 @@ static void media_device_release(struct media_devnode 
> > > *mdev)
> > >  }
> > >  
> > >  /**
> > > - * media_device_register - register a media device
> > > + * media_device_init() - initialize a media device
> > >   * @mdev:The media device
> > >   *
> > >   * The caller is responsible for initializing the media device before
> > > @@ -534,12 +534,11 @@ static void media_device_release(struct 
> > > media_devnode *mdev)
> > >   *
> > >   * - dev must point to the parent device
> > >   * - model must be filled with the device model name
> > > + *
> > > + * returns zero on success or a negative error code.
> > >   */
> > > -int __must_check __media_device_register(struct media_device *mdev,
> > > -  struct module *owner)
> > > +int __must_check media_device_init(struct media_device *mdev)
> > 
> > I think I suggested making media_device_init() return void as the only
> > remaining source of errors would be driver bugs.
> > 
> > I'd simply replace the WARN_ON() below with BUG().
> 
> That sounds like bad idea to me, and it is against the current
> Kernel policy of using BUG() only when there's no other way, e. g. on
> event so severe that the Kernel has no other thing to do except to
> stop running.
> 
> For sure, this is not the case here. Also, all drivers have already
> a logic that checks if the device init happened. So, they should already
> be doing the right thing.

My point is that it's simply counter-productive to require the caller to
perform error handling in cases such as the only possible source of the
error being a NULL argument passed to the callee.

To give you some examples, device_register(), device_add() nor mutex_lock()
perform such checks. Some functions in V4L2 do, but I understand that's
sometimes for historical reasons where NULL arguments were allowed. Or that
there are other possible sources for errors in 

Re: [PATCH v3 00/23] Unrestricted media entity ID range support

[Javier Martinez Canillas]

Hello Laurent,

On 12/27/2015 02:11 PM, Laurent Pinchart wrote:
> Hi Mauro,
> 
> On Wednesday 23 December 2015 10:32:42 Mauro Carvalho Chehab wrote:
>> Em Wed, 16 Dec 2015 16:03:01 +0200 Sakari Ailus escreveu:
>>> On Wed, Dec 16, 2015 at 03:32:15PM +0200, Sakari Ailus wrote:
 This is the third version of the unrestricted media entity ID range
 support set. I've taken Mauro's comments into account and fixed a number
 of bugs as well (omap3isp memory leak and omap4iss stream start).
>>>
>>> Javier: Mauro told me you might have OMAP4 hardware. Would you be able to
>>> test the OMAP4 ISS with these patches?
>>>
>>> Thanks.
>>
>> Sakari,
>>
>> Testing with OMAP4 is not possible. The driver is broken: it doesn't
>> support DT, and the required pdata definition is missing.
> 
> What do you mean by missing ? struct iss_platform_data is defined in 
> include/media/omap4iss.h.
>

That's true but at the very least the omap4iss hwmod is broken in mainline
as you mentioned in the linux-media thread that Mauro shared below.

I think what Mauro meant is that there isn't an omap4 board supported in
mainline that makes use of the iss platform data structures. So testing the
driver in a popular omap4 board such as the pandaboard isn't possible without
adding plumbing board code. And even in that case, the driver fails to probe
due a missing iss_fck clock as Mauro mentioned in his boot log below as well.

I know is not a requirement for a driver to have mainline users but without
DT bindings, using this driver will not be possible sooner rather than later
once the mach-omap2 pdata-quirks.c workaround is removed from mainline since
the omap4 board files were deleted almost 3 years ago (3.11 according to git).
 
>> Both Javier and I tried to fix it in the last couple days, in order to test
>> it with a PandaBoard. We came with the enclosed patch, but it is still
>> incomplete. Based on what's written on this e-mail:
>>   https://www.mail-archive.com/linux-media@vger.kernel.org/msg89247.html
>>
>> It seems that this is an already known issue.
>>
>> So, I'm considering this driver as BROKEN. Not much sense on doing any
>> tests on it, while this doesn't get fixed.
>>
>> Regards,
>> Mauro
>>
>> PS.: With the enclosed patch, I got this error:
>>  [0.267639] platform omap4iss: failed to claim resource 2
>>
>> But, even if I comment out the platform code that returns this error,
>> there are still other missing things:
>>  [7.131622] omap4iss omap4iss: Unable to get iss_fck clock info
>>  [7.137878] omap4iss omap4iss: Unable to get clocks
>>
>> ---
>>
>> ARM: add a pdata quirks for OMAP4 panda camera
>>
>> This is a hack to make it to believe that the pandaboard
>> has a camera.
>>
>>
>> diff --git a/arch/arm/mach-omap2/pdata-quirks.c
>> b/arch/arm/mach-omap2/pdata-quirks.c index 1dfe34654c43..998bb6936dc0
>> 100644
>> --- a/arch/arm/mach-omap2/pdata-quirks.c
>> +++ b/arch/arm/mach-omap2/pdata-quirks.c
>> @@ -36,6 +36,8 @@
>>  #include "soc.h"
>>  #include "hsmmc.h"
>>
>> +#include "../../../drivers/staging/media/omap4iss/iss.h"
>> +
>>  struct pdata_init {
>>  const char *compatible;
>>  void (*fn)(void);
>> @@ -408,6 +410,124 @@ static void __init t410_abort_init(void)
>>  }
>>  #endif
>>
>> +#ifdef CONFIG_ARCH_OMAP4
>> +
>> +static struct resource panda_iss_resource[] = {
>> +{
>> +.start = 0x5200,
>> +.end = 0x5200 + 0x100,
>> +.name = "top",
>> +.flags = IORESOURCE_MEM,
>> +}, {
>> +.start = 0x52001000,
>> +.end = 0x52001000 + 0x170,
>> +.name = "csi2_a_regs1",
>> +.flags = IORESOURCE_MEM,
>> +}, {
>> +.start = 0x52001170,
>> +.end = 0x52001170 + 0x020,
>> +.name = "camerarx_core1",
>> +.flags = IORESOURCE_MEM,
>> +}, {
>> +.start = 0x52001400,
>> +.end = 0x52001400 + 0x170,
>> +.name = "csi2_b_regs1",
>> +.flags = IORESOURCE_MEM,
>> +}, {
>> +.start = 0x52001570,
>> +.end = 0x52001570 + 0x020,
>> +.name = "camerarx_core2",
>> +.flags = IORESOURCE_MEM,
>> +}, {
>> +.start = 0x52002000,
>> +.end = 0x52002000 + 0x200,
>> +.name = "bte",
>> +.flags = IORESOURCE_MEM,
>> +}, {
>> +.start = 0x5201,
>> +.end = 0x5201 + 0x0a0,
>> +.name = "isp_sys1",
>> +.flags = IORESOURCE_MEM,
>> +}, {
>> +.start = 0x52010400,
>> +.end = 0x52010400 + 0x400,
>> +.name = "isp_resizer",
>> +.flags = IORESOURCE_MEM,
>> +}, {
>> +.start = 0x52010800,
>> +.end = 0x52010800 + 0x800,
>> +.name = "isp_ipipe",
>> +.flags = IORESOURCE_MEM,
>> +}, {
>> +.start = 0x52011000,
>> +.end = 0x52011000 + 0x200,
>> +

cron job: media_tree daily build: OK

[Hans Verkuil]

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 Dec 28 04:00:15 CET 2015
git branch: test
git hash:   768acf46e1320d6c41ed1b7c4952bab41c1cde79
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-51-ga53cea2
smatch version: v0.5.0-3228-g5cf65ab
host hardware:  x86_64
host os:4.3.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-rc1-i686: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
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

Your company import from China, we help in logistics field.

[Alfred]

Dear Sirs:

Glad to write you!

Does your company have imported goods from China?If so, please send your 
packing list to me.I can give you a quotation for reference.

Hope our years of experience in the logistics field and good service can 
give you help.

Happy new year.


---

Alfred


Shenzhen Dongda Freight agency CO., LTD

---

Tel:86-755-61961370
Mob：86-18929393836
Fax：86-755-29196661
Email：alfred_wei...@sina.comsal...@ddhy168.com
SKYPE:ddhy168  QQ:1559489526
Web：www.ddhy168.com
Address: 516 Baishiwei Logistics Park Fuwei
 Community Fuyong Street
 Bao'an District,
 Shenzhen，518103 
ChinaN�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{���bj)��骅w*jg�报�茛j/�赇z罐���2���ㄨ��&�)摺�a囤���G���h��j:+v���w��佶