date:20180320

Re: [PATCH v3 2/2] staging: media: davinci_vpfe: add kfree() on goto err statement

2018-03-20 Thread Dan Carpenter

Looks good.  Thanks!

regards,
dan carpenter

cron job: media_tree daily build: WARNINGS

2018-03-20 Thread 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:   Wed Mar 21 05:00:11 CET 2018
media-tree git hash:e68854a2588a923b31eebce348f8020374843f8e
media_build git hash:   e95b7e6bfea396f9dfb1ff7d4d6b95ecacd53d3d
v4l-utils git hash: 14ce03c18ef67aa7a3d5781f015be855fd43839c
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: v0.5.0-3994-g45eb2282
smatch version: v0.5.0-3994-g45eb2282
host hardware:  x86_64
host os:4.14.0-3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: 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.36.4-i686: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.101-i686: WARNINGS
linux-3.0.101-x86_64: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.100-i686: WARNINGS
linux-3.2.100-x86_64: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.113-i686: WARNINGS
linux-3.4.113-x86_64: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.10-i686: WARNINGS
linux-3.7.10-x86_64: WARNINGS
linux-3.8.13-i686: WARNINGS
linux-3.8.13-x86_64: WARNINGS
linux-3.9.11-i686: WARNINGS
linux-3.9.11-x86_64: WARNINGS
linux-3.10.108-i686: WARNINGS
linux-3.10.108-x86_64: WARNINGS
linux-3.11.10-i686: WARNINGS
linux-3.11.10-x86_64: WARNINGS
linux-3.12.74-i686: WARNINGS
linux-3.12.74-x86_64: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.79-i686: WARNINGS
linux-3.14.79-x86_64: WARNINGS
linux-3.15.10-i686: WARNINGS
linux-3.15.10-x86_64: WARNINGS
linux-3.16.55-i686: WARNINGS
linux-3.16.55-x86_64: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.100-i686: WARNINGS
linux-3.18.100-x86_64: WARNINGS
linux-3.19.8-i686: WARNINGS
linux-3.19.8-x86_64: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.50-i686: WARNINGS
linux-4.1.50-x86_64: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.99-i686: OK
linux-4.4.99-x86_64: OK
linux-4.5.7-i686: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: WARNINGS
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: WARNINGS
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: WARNINGS
linux-4.9.87-i686: WARNINGS
linux-4.9.87-x86_64: WARNINGS
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: WARNINGS
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: WARNINGS
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: OK
linux-4.13.16-i686: OK
linux-4.13.16-x86_64: OK
linux-4.14.27-i686: OK
linux-4.14.27-x86_64: OK
linux-4.15.10-i686: OK
linux-4.15.10-x86_64: OK
linux-4.16-rc5-i686: OK
linux-4.16-rc5-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

[PATCH v3 2/2] staging: media: davinci_vpfe: add kfree() on goto err statement

2018-03-20 Thread Ji-Hun Kim

It needs to free of allocated params value in the goto error statement.

Signed-off-by: Ji-Hun Kim 
---
Changes since v2:
  - add kfree(params) on the error case of the function
  - rename unclear goto statement name
  - declare the params value at start of the function, so it can be free
end of the function

 drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index ffcd86d..735d8b5 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1263,6 +1263,7 @@ static int ipipe_get_cgs_params(struct vpfe_ipipe_device 
*ipipe, void *param)
 static int ipipe_s_config(struct v4l2_subdev *sd, struct vpfe_ipipe_config 
*cfg)
 {
struct vpfe_ipipe_device *ipipe = v4l2_get_subdevdata(sd);
+   struct ipipe_module_params *params;
unsigned int i;
int rval = 0;
 
@@ -1272,7 +1273,6 @@ static int ipipe_s_config(struct v4l2_subdev *sd, struct 
vpfe_ipipe_config *cfg)
if (cfg->flag & bit) {
const struct ipipe_module_if *module_if =
&ipipe_modules[i];
-   struct ipipe_module_params *params;
void __user *from = *(void * __user *)
((void *)cfg + module_if->config_offset);
size_t size;
@@ -1289,26 +1289,30 @@ static int ipipe_s_config(struct v4l2_subdev *sd, 
struct vpfe_ipipe_config *cfg)
if (to && from && size) {
if (copy_from_user(to, from, size)) {
rval = -EFAULT;
-   break;
+   goto err_free_params;
}
rval = module_if->set(ipipe, to);
if (rval)
-   goto error;
+   goto err_free_params;
} else if (to && !from && size) {
rval = module_if->set(ipipe, NULL);
if (rval)
-   goto error;
+   goto err_free_params;
}
kfree(params);
}
}
-error:
+   return 0;
+
+err_free_params:
+   kfree(params);
return rval;
 }
 
 static int ipipe_g_config(struct v4l2_subdev *sd, struct vpfe_ipipe_config 
*cfg)
 {
struct vpfe_ipipe_device *ipipe = v4l2_get_subdevdata(sd);
+   struct ipipe_module_params *params;
unsigned int i;
int rval = 0;
 
@@ -1318,7 +1322,6 @@ static int ipipe_g_config(struct v4l2_subdev *sd, struct 
vpfe_ipipe_config *cfg)
if (cfg->flag & bit) {
const struct ipipe_module_if *module_if =
&ipipe_modules[i];
-   struct ipipe_module_params *params;
void __user *to = *(void * __user *)
((void *)cfg + module_if->config_offset);
size_t size;
@@ -1335,16 +1338,19 @@ static int ipipe_g_config(struct v4l2_subdev *sd, 
struct vpfe_ipipe_config *cfg)
if (to && from && size) {
rval = module_if->get(ipipe, from);
if (rval)
-   goto error;
+   goto err_free_params;
if (copy_to_user(to, from, size)) {
rval = -EFAULT;
-   break;
+   goto err_free_params;
}
}
kfree(params);
}
}
-error:
+   return 0;
+
+err_free_params:
+   kfree(params);
return rval;
 }
 
-- 
1.9.1

[PATCH v3 1/2] staging: media: davinci_vpfe: add error handling on kmalloc failure

2018-03-20 Thread Ji-Hun Kim

There is no failure checking on the param value which will be allocated
memory by kmalloc. Add a null pointer checking statement. Then goto error:
and return -ENOMEM error code when kmalloc is failed.

Signed-off-by: Ji-Hun Kim 
---
Changes since v1:
  - Return with -ENOMEM directly, instead of goto error: then return.
  - [Patch v3 1/2] is same with [patch v2]

 drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 6a3434c..ffcd86d 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1280,6 +1280,9 @@ static int ipipe_s_config(struct v4l2_subdev *sd, struct 
vpfe_ipipe_config *cfg)
 
params = kmalloc(sizeof(struct ipipe_module_params),
 GFP_KERNEL);
+   if (!params)
+   return -ENOMEM;
+
to = (void *)params + module_if->param_offset;
size = module_if->param_size;
 
@@ -1323,6 +1326,9 @@ static int ipipe_g_config(struct v4l2_subdev *sd, struct 
vpfe_ipipe_config *cfg)
 
params =  kmalloc(sizeof(struct ipipe_module_params),
GFP_KERNEL);
+   if (!params)
+   return -ENOMEM;
+
from = (void *)params + module_if->param_offset;
size = module_if->param_size;
 
-- 
1.9.1

Re: uvcvideo: Unknown video format,00000032-0002-0010-8000-00aa00389b71

2018-03-20 Thread Nicolas Dufresne

Le mardi 20 mars 2018 à 20:04 +0200, Laurent Pinchart a écrit :
> Hi Nicolas,
> 
> On Tuesday, 20 March 2018 19:45:51 EET Nicolas Dufresne wrote:
> > Le mardi 20 mars 2018 à 13:20 +0100, Paul Menzel a écrit :
> > > Dear Linux folks,
> > > 
> > > 
> > > On the Dell XPS 13 9370, Linux 4.16-rc6 outputs the messages below.
> > > 
> > > ```
> > > [2.338094] calling  uvc_init+0x0/0x1000 [uvcvideo] @ 295
> > > [2.338569] calling  iTCO_wdt_init_module+0x0/0x1000 [iTCO_wdt] @ 280
> > > [2.338570] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
> > > [2.338713] iTCO_wdt: Found a Intel PCH TCO device (Version=4,
> > > TCOBASE=0x0400)
> > > [2.338755] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD
> > > (0bda:58f4)
> > > [2.338827] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
> > > [2.338851] initcall iTCO_wdt_init_module+0x0/0x1000 [iTCO_wdt]
> > > returned 0 after 271 usecs
> > > [2.340669] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was
> > > not initialized!
> > > [2.340670] uvcvideo 1-5:1.0: Entity type for entity Extension 7 was
> > > not initialized!
> > > [2.340672] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was
> > > not initialized!
> > > [2.340673] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not
> > > initialized!
> > > [2.340736] input: Integrated_Webcam_HD: Integrate as
> > > /devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input9
> > > [2.341447] uvcvideo: Unknown video format
> > > 0032-0002-0010-8000-00aa00389b71
> > 
> > While the 0002 is suspicious, this is pretty close to a color format.
> > I've recently come across of similar format using D3DFORMAT instead of
> > GUID. According to the vendor*, this camera module includes an infrared
> > camera (340x340), so I suspect this is to specify the format it
> > outputs. A good guess to start with would be that this is
> > D3DFMT_X8L8V8U8 (0x32).
> 
> Isn't 0x32 D3DFMT_L8, not D3DFMT_X8L8V8U8 ?

You are right, sorry about that, I totally miss-translate. It felt
weird. This is much more likely yes. So maybe it's the same mapping
(but with the -2- instead) as what I added for the HoloLense
Camera.
> 
> > To test it, you could map this
> > V4L2_PIX_FMT_YUV32/xRGB and see if the driver is happy with the buffer
> > size.
> 
> VideoStreaming Interface Descriptor:
> bLength30
> bDescriptorType36
> bDescriptorSubtype  5 (FRAME_UNCOMPRESSED)
> bFrameIndex 1
> bmCapabilities   0x00
>   Still image unsupported
> wWidth340
> wHeight   340
> dwMinBitRate 55488000
> dwMaxBitRate 55488000
> dwMaxVideoFrameBufferSize  115600
> dwDefaultFrameInterval 16
> bFrameIntervalType  1
> dwFrameInterval( 0)16
> 
> 340*340 is 115600, so this should be a 8-bit format.

Indeed, that matches.

> 
> > Then render it to make sure it looks some image of some sort. A
> > new format will need to be defined as this format is in the wrong
> > order, and is ambiguous (it may mean AYUV or xYUV). I'm not sure if we
> > need specific formats to differentiate infrared data from YUV images,
> > need to be discussed.
> 
> If the format is indeed D3DFMT_L8, it should map to V4L2_PIX_FMT_GREY (8-bit 
> luminance). I suspect the camera transmits a depth map though.

I wonder if we should think of a way to tell userspace this is fnfrared
data rather then black and white ?

> 
> > *https://dustinweb.azureedge.net/media/338953/xps-13-9370.pdf
> > 
> > > [2.341450] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD
> > > (0bda:58f4)
> > > [2.343371] uvcvideo: Unable to create debugfs 1-2 directory.
> > > [2.343420] uvcvideo 1-5:1.2: Entity type for entity Extension 10 was
> > > not initialized!
> > > [2.343422] uvcvideo 1-5:1.2: Entity type for entity Extension 12 was
> > > not initialized!
> > > [2.343423] uvcvideo 1-5:1.2: Entity type for entity Processing 9 was
> > > not initialized!
> > > [2.343424] uvcvideo 1-5:1.2: Entity type for entity Camera 11 was
> > > not initialized!
> > > [2.343472] input: Integrated_Webcam_HD: Integrate as
> > > /devices/pci:00/:00:14.0/usb1/1-5/1-5:1.2/input/input10
> > > [2.343496] usbcore: registered new interface driver uvcvideo
> > > [2.343496] USB Video Class driver (1.1.1)
> > > [2.343501] initcall uvc_init+0x0/0x1000 [uvcvideo] returned 0 after
> > > 5275 usecs
> > > ```
> > > 
> > > Please tell me, what I can do to improve the situation.
> 
>

[PATCH v3 12/13] media: staging/imx: Switch to v4l2_async_notifier_add_subdev

2018-03-20 Thread Steve Longerbeam

Switch to v4l2_async_notifier_add_subdev() when adding async subdevs
to the imx-media root notifier. This removes the need to check for
an already added asd, since v4l2_async_notifier_add_subdev() does this
check. Also no need to allocate a subdevs array when registering the
root notifier, or keeping an internal master asd_list, since this is
moved to the notifier's asd_list.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-dev.c | 110 ++
 drivers/staging/media/imx/imx-media-internal-sd.c |   5 +-
 drivers/staging/media/imx/imx-media.h |   4 +-
 3 files changed, 32 insertions(+), 87 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
index dd4702a..f67ec8e 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -33,43 +33,10 @@ static inline struct imx_media_dev *notifier2dev(struct 
v4l2_async_notifier *n)
 }
 
 /*
- * Find an asd by fwnode or device name. This is called during
- * driver load to form the async subdev list and bind them.
- */
-static struct v4l2_async_subdev *
-find_async_subdev(struct imx_media_dev *imxmd,
- struct fwnode_handle *fwnode,
- const char *devname)
-{
-   struct imx_media_async_subdev *imxasd;
-   struct v4l2_async_subdev *asd;
-
-   list_for_each_entry(imxasd, &imxmd->asd_list, list) {
-   asd = &imxasd->asd;
-   switch (asd->match_type) {
-   case V4L2_ASYNC_MATCH_FWNODE:
-   if (fwnode && asd->match.fwnode == fwnode)
-   return asd;
-   break;
-   case V4L2_ASYNC_MATCH_DEVNAME:
-   if (devname && !strcmp(asd->match.device_name,
-  devname))
-   return asd;
-   break;
-   default:
-   break;
-   }
-   }
-
-   return NULL;
-}
-
-
-/*
- * Adds a subdev to the async subdev list. If fwnode is non-NULL, adds
- * the async as a V4L2_ASYNC_MATCH_FWNODE match type, otherwise as
- * a V4L2_ASYNC_MATCH_DEVNAME match type using the dev_name of the
- * given platform_device. This is called during driver load when
+ * Adds a subdev to the root notifier's async subdev list. If fwnode is
+ * non-NULL, adds the async as a V4L2_ASYNC_MATCH_FWNODE match type,
+ * otherwise as a V4L2_ASYNC_MATCH_DEVNAME match type using the dev_name
+ * of the given platform_device. This is called during driver load when
  * forming the async subdev list.
  */
 int imx_media_add_async_subdev(struct imx_media_dev *imxmd,
@@ -80,28 +47,17 @@ int imx_media_add_async_subdev(struct imx_media_dev *imxmd,
struct imx_media_async_subdev *imxasd;
struct v4l2_async_subdev *asd;
const char *devname = NULL;
-   int ret = 0;
+   int ret;
 
-   mutex_lock(&imxmd->mutex);
+   imxasd = kzalloc(sizeof(*imxasd), GFP_KERNEL);
+   if (!imxasd)
+   return -ENOMEM;
+
+   asd = &imxasd->asd;
 
if (pdev)
devname = dev_name(&pdev->dev);
 
-   /* return -EEXIST if this asd already added */
-   if (find_async_subdev(imxmd, fwnode, devname)) {
-   dev_dbg(imxmd->md.dev, "%s: already added %s\n",
-   __func__, np ? np->name : devname);
-   ret = -EEXIST;
-   goto out;
-   }
-
-   imxasd = devm_kzalloc(imxmd->md.dev, sizeof(*imxasd), GFP_KERNEL);
-   if (!imxasd) {
-   ret = -ENOMEM;
-   goto out;
-   }
-   asd = &imxasd->asd;
-
if (fwnode) {
asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
asd->match.fwnode = fwnode;
@@ -111,16 +67,19 @@ int imx_media_add_async_subdev(struct imx_media_dev *imxmd,
imxasd->pdev = pdev;
}
 
-   list_add_tail(&imxasd->list, &imxmd->asd_list);
-
-   imxmd->notifier.num_subdevs++;
+   ret = v4l2_async_notifier_add_subdev(&imxmd->notifier, asd);
+   if (ret < 0) {
+   if (ret == -EEXIST)
+   dev_dbg(imxmd->md.dev, "%s: already added %s\n",
+   __func__, np ? np->name : devname);
+   kfree(imxasd);
+   return ret;
+   }
 
dev_dbg(imxmd->md.dev, "%s: added %s, match type %s\n",
__func__, np ? np->name : devname, np ? "FWNODE" : "DEVNAME");
 
-out:
-   mutex_unlock(&imxmd->mutex);
-   return ret;
+   return 0;
 }
 
 /*
@@ -483,10 +442,8 @@ static int imx_media_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
struct device_node *node = dev->of_node;
-   struct imx_media_async_subdev *imxasd;
-   struct v4l2_async_subdev **subdevs;
struct imx_media_dev *imxmd;
-   int num_subdevs, i,

[PATCH v3 11/13] media: staging/imx: Rename root notifier

2018-03-20 Thread Steve Longerbeam

Rename the imx-media root async notifier from "subdev_notifier" to
simply "notifier", so as not to confuse it with true subdev notifiers.
No functional changes.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-dev.c | 14 +++---
 drivers/staging/media/imx/imx-media.h |  2 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
index 4d00ed3..dd4702a 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -29,7 +29,7 @@
 
 static inline struct imx_media_dev *notifier2dev(struct v4l2_async_notifier *n)
 {
-   return container_of(n, struct imx_media_dev, subdev_notifier);
+   return container_of(n, struct imx_media_dev, notifier);
 }
 
 /*
@@ -113,7 +113,7 @@ int imx_media_add_async_subdev(struct imx_media_dev *imxmd,
 
list_add_tail(&imxasd->list, &imxmd->asd_list);
 
-   imxmd->subdev_notifier.num_subdevs++;
+   imxmd->notifier.num_subdevs++;
 
dev_dbg(imxmd->md.dev, "%s: added %s, match type %s\n",
__func__, np ? np->name : devname, np ? "FWNODE" : "DEVNAME");
@@ -532,7 +532,7 @@ static int imx_media_probe(struct platform_device *pdev)
goto unreg_dev;
}
 
-   num_subdevs = imxmd->subdev_notifier.num_subdevs;
+   num_subdevs = imxmd->notifier.num_subdevs;
 
/* no subdevs? just bail */
if (num_subdevs == 0) {
@@ -552,10 +552,10 @@ static int imx_media_probe(struct platform_device *pdev)
subdevs[i++] = &imxasd->asd;
 
/* prepare the async subdev notifier and register it */
-   imxmd->subdev_notifier.subdevs = subdevs;
-   imxmd->subdev_notifier.ops = &imx_media_subdev_ops;
+   imxmd->notifier.subdevs = subdevs;
+   imxmd->notifier.ops = &imx_media_subdev_ops;
ret = v4l2_async_notifier_register(&imxmd->v4l2_dev,
-  &imxmd->subdev_notifier);
+  &imxmd->notifier);
if (ret) {
v4l2_err(&imxmd->v4l2_dev,
 "v4l2_async_notifier_register failed with %d\n", ret);
@@ -580,7 +580,7 @@ static int imx_media_remove(struct platform_device *pdev)
 
v4l2_info(&imxmd->v4l2_dev, "Removing imx-media\n");
 
-   v4l2_async_notifier_unregister(&imxmd->subdev_notifier);
+   v4l2_async_notifier_unregister(&imxmd->notifier);
imx_media_remove_internal_subdevs(imxmd);
v4l2_device_unregister(&imxmd->v4l2_dev);
media_device_unregister(&imxmd->md);
diff --git a/drivers/staging/media/imx/imx-media.h 
b/drivers/staging/media/imx/imx-media.h
index e945e0e..7edb18a 100644
--- a/drivers/staging/media/imx/imx-media.h
+++ b/drivers/staging/media/imx/imx-media.h
@@ -148,7 +148,7 @@ struct imx_media_dev {
 
/* for async subdev registration */
struct list_head asd_list;
-   struct v4l2_async_notifier subdev_notifier;
+   struct v4l2_async_notifier notifier;
 };
 
 enum codespace_sel {
-- 
2.7.4

[PATCH v3 10/13] media: staging/imx: Loop through all registered subdevs for media links

2018-03-20 Thread Steve Longerbeam

The root imx-media notifier no longer sees all bound subdevices because
some of them will be bound to subdev notifiers. So imx_media_create_links()
now needs to loop through all subdevices registered with the v4l2-device,
not just the ones in the root notifier's done list. This should be safe
because imx_media_create_of_links() checks if a fwnode link already
exists before creating.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-dev.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
index 289d775..4d00ed3 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -175,7 +175,7 @@ static int imx_media_subdev_bound(struct 
v4l2_async_notifier *notifier,
 }
 
 /*
- * create the media links for all subdevs that registered async.
+ * Create the media links for all subdevs that registered.
  * Called after all async subdevs have bound.
  */
 static int imx_media_create_links(struct v4l2_async_notifier *notifier)
@@ -184,14 +184,7 @@ static int imx_media_create_links(struct 
v4l2_async_notifier *notifier)
struct v4l2_subdev *sd;
int ret;
 
-   /*
-* Only links are created between subdevices that are known
-* to the async notifier. If there are other non-async subdevices,
-* they were created internally by some subdevice (smiapp is one
-* example). In those cases it is expected the subdevice is
-* responsible for creating those internal links.
-*/
-   list_for_each_entry(sd, ¬ifier->done, async_list) {
+   list_for_each_entry(sd, &imxmd->v4l2_dev.subdevs, list) {
switch (sd->grp_id) {
case IMX_MEDIA_GRP_ID_VDIC:
case IMX_MEDIA_GRP_ID_IC_PRP:
@@ -211,7 +204,10 @@ static int imx_media_create_links(struct 
v4l2_async_notifier *notifier)
imx_media_create_csi_of_links(imxmd, sd);
break;
default:
-   /* this is an external fwnode subdev */
+   /*
+* if this subdev has fwnode links, create media
+* links for them.
+*/
imx_media_create_of_links(imxmd, sd);
break;
}
-- 
2.7.4

[PATCH v3 13/13] media: staging/imx: TODO: Remove one assumption about OF graph parsing

2018-03-20 Thread Steve Longerbeam

The move to subdev notifiers fixes one assumption of OF graph parsing.
If a subdevice has non-video related ports, the subdev driver knows not
to follow those ports when adding remote devices to its subdev notifier.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/TODO | 29 +++--
 1 file changed, 7 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/media/imx/TODO b/drivers/staging/media/imx/TODO
index 9eb7326..aeeb154 100644
--- a/drivers/staging/media/imx/TODO
+++ b/drivers/staging/media/imx/TODO
@@ -17,29 +17,15 @@
   decided whether this feature is useful enough to make it generally
   available by exporting to v4l2-core.
 
-- The OF graph is walked at probe time to form the list of fwnodes to
-  be passed to v4l2_async_notifier_register(), starting from the IPU
-  CSI ports. And after all async subdevices have been bound,
-  v4l2_fwnode_parse_link() is used to form the media links between
-  the entities discovered by walking the OF graph.
+- After all async subdevices have been bound, v4l2_fwnode_parse_link()
+  is used to form the media links between the devices discovered in
+  the OF graph.
 
   While this approach allows support for arbitrary OF graphs, there
   are some assumptions for this to work:
 
-  1. All port parent nodes reachable in the graph from the IPU CSI
- ports bind to V4L2 async subdevice drivers.
-
- If a device has mixed-use ports such as video plus audio, the
- endpoints from the audio ports are followed to devices that must
- bind to V4L2 subdevice drivers, and not for example, to an ALSA
- driver or a non-V4L2 media driver. If the device were bound to
- such a driver, imx-media would never get an async completion
- notification because the device fwnode was added to the async
- list, but the driver does not interface with the V4L2 async
- framework.
-
-  2. Every port reachable in the graph is treated as a media pad,
- owned by the V4L2 subdevice that is bound to the port's parent.
+  1. If a port owned by a device in the graph has endpoint nodes, the
+ port is treated as a media pad.
 
  This presents problems for devices that don't make this port = pad
  assumption. Examples are SMIAPP compatible cameras which define only
@@ -54,9 +40,8 @@
  possible long-term solution is to implement a subdev API that
  maps a port id to a media pad index.
 
-  3. Every endpoint of a port reachable in the graph is treated as
- a media link, between V4L2 subdevices that are bound to the
- port parents of the local and remote endpoints.
+  2. Every endpoint of a port owned by a device in the graph is treated
+ as a media link.
 
  Which means a port must not contain mixed-use endpoints, they
  must all refer to media links between V4L2 subdevices.
-- 
2.7.4

[PATCH v3 09/13] media: staging/imx: of: Remove recursive graph walk

2018-03-20 Thread Steve Longerbeam

After moving to subdev notifiers, it's no longer necessary to recursively
walk the OF graph, because the subdev notifiers will discover and add
devices from the graph for us.

So the recursive of_parse_subdev() function is gone, replaced with
of_add_csi() which adds only the CSI port fwnodes to the imx-media
root notifier.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-of.c | 106 +++
 1 file changed, 8 insertions(+), 98 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-of.c 
b/drivers/staging/media/imx/imx-media-of.c
index acde372..1c91754 100644
--- a/drivers/staging/media/imx/imx-media-of.c
+++ b/drivers/staging/media/imx/imx-media-of.c
@@ -20,74 +20,19 @@
 #include 
 #include "imx-media.h"
 
-static int of_get_port_count(const struct device_node *np)
+static int of_add_csi(struct imx_media_dev *imxmd, struct device_node *csi_np)
 {
-   struct device_node *ports, *child;
-   int num = 0;
-
-   /* check if this node has a ports subnode */
-   ports = of_get_child_by_name(np, "ports");
-   if (ports)
-   np = ports;
-
-   for_each_child_of_node(np, child)
-   if (of_node_cmp(child->name, "port") == 0)
-   num++;
-
-   of_node_put(ports);
-   return num;
-}
-
-/*
- * find the remote device node given local endpoint node
- */
-static bool of_get_remote(struct device_node *epnode,
- struct device_node **remote_node)
-{
-   struct device_node *rp, *rpp;
-   struct device_node *remote;
-   bool is_csi_port;
-
-   rp = of_graph_get_remote_port(epnode);
-   rpp = of_graph_get_remote_port_parent(epnode);
-
-   if (of_device_is_compatible(rpp, "fsl,imx6q-ipu")) {
-   /* the remote is one of the CSI ports */
-   remote = rp;
-   of_node_put(rpp);
-   is_csi_port = true;
-   } else {
-   remote = rpp;
-   of_node_put(rp);
-   is_csi_port = false;
-   }
-
-   if (!of_device_is_available(remote)) {
-   of_node_put(remote);
-   *remote_node = NULL;
-   } else {
-   *remote_node = remote;
-   }
-
-   return is_csi_port;
-}
-
-static int
-of_parse_subdev(struct imx_media_dev *imxmd, struct device_node *sd_np,
-   bool is_csi_port)
-{
-   int i, num_ports, ret;
+   int ret;
 
-   if (!of_device_is_available(sd_np)) {
+   if (!of_device_is_available(csi_np)) {
dev_dbg(imxmd->md.dev, "%s: %s not enabled\n", __func__,
-   sd_np->name);
+   csi_np->name);
/* unavailable is not an error */
return 0;
}
 
-   /* register this subdev with async notifier */
-   ret = imx_media_add_async_subdev(imxmd, of_fwnode_handle(sd_np),
-NULL);
+   /* add CSI fwnode to async notifier */
+   ret = imx_media_add_async_subdev(imxmd, of_fwnode_handle(csi_np), NULL);
if (ret) {
if (ret == -EEXIST) {
/* already added, everything is fine */
@@ -98,42 +43,7 @@ of_parse_subdev(struct imx_media_dev *imxmd, struct 
device_node *sd_np,
return ret;
}
 
-   /*
-* the ipu-csi has one sink port. The source pads are not
-* represented in the device tree by port nodes, but are
-* described by the internal pads and links later.
-*/
-   num_ports = is_csi_port ? 1 : of_get_port_count(sd_np);
-
-   for (i = 0; i < num_ports; i++) {
-   struct device_node *epnode = NULL, *port, *remote_np;
-
-   port = is_csi_port ? sd_np : of_graph_get_port_by_id(sd_np, i);
-   if (!port)
-   continue;
-
-   for_each_child_of_node(port, epnode) {
-   bool remote_is_csi;
-
-   remote_is_csi = of_get_remote(epnode, &remote_np);
-   if (!remote_np)
-   continue;
-
-   ret = of_parse_subdev(imxmd, remote_np, remote_is_csi);
-   of_node_put(remote_np);
-   if (ret)
-   break;
-   }
-
-   if (port != sd_np)
-   of_node_put(port);
-   if (ret) {
-   of_node_put(epnode);
-   break;
-   }
-   }
-
-   return ret;
+   return 0;
 }
 
 int imx_media_add_of_subdevs(struct imx_media_dev *imxmd,
@@ -147,7 +57,7 @@ int imx_media_add_of_subdevs(struct imx_media_dev *imxmd,
if (!csi_np)
break;
 
-   ret = of_parse_subdev(imxmd, csi_np, true);
+   ret = of_add_csi(imxmd, csi_np);
of_node_put(csi_np);
if (ret)

[PATCH v3 02/13] media: v4l2: async: Allow searching for asd of any type

2018-03-20 Thread Steve Longerbeam

Generalize v4l2_async_notifier_fwnode_has_async_subdev() to allow
searching for any type of async subdev, not just fwnodes. Rename to
v4l2_async_notifier_has_async_subdev() and pass it an asd pointer.

TODO: support asd compare with CUSTOM match type in asd_equal().

Signed-off-by: Steve Longerbeam 
---
Changes since v2:
- code optimization in asd_equal(), and remove unneeded braces,
  suggested by Sakari Ailus.
Changes since v1:
- none
---
 drivers/media/v4l2-core/v4l2-async.c | 76 ++--
 1 file changed, 46 insertions(+), 30 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 2b08d03..b59bbac 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -124,6 +124,34 @@ static struct v4l2_async_subdev *v4l2_async_find_match(
return NULL;
 }
 
+/* Compare two asd's for equivalence */
+static bool asd_equal(struct v4l2_async_subdev *asd_x,
+ struct v4l2_async_subdev *asd_y)
+{
+   if (asd_x->match_type != asd_y->match_type)
+   return false;
+
+   switch (asd_x->match_type) {
+   case V4L2_ASYNC_MATCH_DEVNAME:
+   return strcmp(asd_x->match.device_name,
+ asd_y->match.device_name) == 0;
+   case V4L2_ASYNC_MATCH_I2C:
+   return asd_x->match.i2c.adapter_id ==
+   asd_y->match.i2c.adapter_id &&
+   asd_x->match.i2c.address ==
+   asd_y->match.i2c.address;
+   case V4L2_ASYNC_MATCH_FWNODE:
+   return asd_x->match.fwnode == asd_y->match.fwnode;
+   case V4L2_ASYNC_MATCH_CUSTOM:
+   /* TODO */
+   return false;
+   default:
+   break;
+   }
+
+   return false;
+}
+
 /* Find the sub-device notifier registered by a sub-device driver. */
 static struct v4l2_async_notifier *v4l2_async_find_subdev_notifier(
struct v4l2_subdev *sd)
@@ -308,29 +336,22 @@ static void v4l2_async_notifier_unbind_all_subdevs(
notifier->parent = NULL;
 }
 
-/* See if an fwnode can be found in a notifier's lists. */
-static bool __v4l2_async_notifier_fwnode_has_async_subdev(
-   struct v4l2_async_notifier *notifier, struct fwnode_handle *fwnode)
+/* See if an async sub-device can be found in a notifier's lists. */
+static bool __v4l2_async_notifier_has_async_subdev(
+   struct v4l2_async_notifier *notifier, struct v4l2_async_subdev *asd)
 {
-   struct v4l2_async_subdev *asd;
+   struct v4l2_async_subdev *asd_y;
struct v4l2_subdev *sd;
 
-   list_for_each_entry(asd, ¬ifier->waiting, list) {
-   if (asd->match_type != V4L2_ASYNC_MATCH_FWNODE)
-   continue;
-
-   if (asd->match.fwnode == fwnode)
+   list_for_each_entry(asd_y, ¬ifier->waiting, list)
+   if (asd_equal(asd, asd_y))
return true;
-   }
 
list_for_each_entry(sd, ¬ifier->done, async_list) {
if (WARN_ON(!sd->asd))
continue;
 
-   if (sd->asd->match_type != V4L2_ASYNC_MATCH_FWNODE)
-   continue;
-
-   if (sd->asd->match.fwnode == fwnode)
+   if (asd_equal(asd, sd->asd))
return true;
}
 
@@ -338,32 +359,28 @@ static bool __v4l2_async_notifier_fwnode_has_async_subdev(
 }
 
 /*
- * Find out whether an async sub-device was set up for an fwnode already or
+ * Find out whether an async sub-device was set up already or
  * whether it exists in a given notifier before @this_index.
  */
-static bool v4l2_async_notifier_fwnode_has_async_subdev(
-   struct v4l2_async_notifier *notifier, struct fwnode_handle *fwnode,
+static bool v4l2_async_notifier_has_async_subdev(
+   struct v4l2_async_notifier *notifier, struct v4l2_async_subdev *asd,
unsigned int this_index)
 {
unsigned int j;
 
lockdep_assert_held(&list_lock);
 
-   /* Check that an fwnode is not being added more than once. */
+   /* Check that an asd is not being added more than once. */
for (j = 0; j < this_index; j++) {
-   struct v4l2_async_subdev *asd = notifier->subdevs[this_index];
-   struct v4l2_async_subdev *other_asd = notifier->subdevs[j];
+   struct v4l2_async_subdev *asd_y = notifier->subdevs[j];
 
-   if (other_asd->match_type == V4L2_ASYNC_MATCH_FWNODE &&
-   asd->match.fwnode ==
-   other_asd->match.fwnode)
+   if (asd_equal(asd, asd_y))
return true;
}
 
-   /* Check than an fwnode did not exist in other notifiers. */
+   /* Check that an asd does not exist in other notifiers. */
list_for_each_entry(notifier, ¬ifier_list, list)
-   if (__v4l2_async_notifier_fwnode_has_async_subdev(
-   noti

[PATCH v3 00/13] media: imx: Switch to subdev notifiers

2018-03-20 Thread Steve Longerbeam

This patchset converts the imx-media driver and its dependent
subdevs to use subdev notifiers.

There are a couple shortcomings in v4l2-core that prevented
subdev notifiers from working correctly in imx-media:

1. v4l2_async_notifier_fwnode_parse_endpoint() treats a fwnode
   endpoint that is not connected to a remote device as an error.
   But in the case of the video-mux subdev, this is not an error,
   it is OK if some of the mux inputs have no connection. Also,
   Documentation/devicetree/bindings/media/video-interfaces.txt explicitly
   states that the 'remote-endpoint' property is optional. So the first
   patch is a small modification to ignore empty endpoints in
   v4l2_async_notifier_fwnode_parse_endpoint() and allow
   __v4l2_async_notifier_parse_fwnode_endpoints() to continue to
   parse the remaining port endpoints of the device.

2. In the imx-media graph, multiple subdevs will encounter the same
   upstream subdev (such as the imx6-mipi-csi2 receiver), and so
   v4l2_async_notifier_parse_fwnode_endpoints() will add imx6-mipi-csi2
   multiple times. This is treated as an error by
   v4l2_async_notifier_register() later.

   To get around this problem, add an v4l2_async_notifier_add_subdev()
   which first verifies the provided asd does not already exist in the
   given notifier asd list or in other registered notifiers. If the asd
   exists, the function returns -EEXIST and it's up to the caller to
   decide if that is an error (in imx-media case it is never an error).

   Patches 2-4 deal with adding that support.

3. Patch 5 adds v4l2_async_register_fwnode_subdev(), which is a
   convenience function for parsing a subdev's fwnode port endpoints
   for connected remote subdevs, registering a subdev notifier, and
   then registering the sub-device itself.

The remaining patches update the subdev drivers to register a
subdev notifier with endpoint parsing, and the changes to imx-media
to support that.

Signed-off-by: Steve Longerbeam 
Acked-by: Philipp Zabel 

History:
v3:
- code optimization in asd_equal(), and remove unneeded braces,
  suggested by Sakari Ailus.
- add a NULL asd pointer check to v4l2_async_notifier_asd_valid().
- fix an error-out path in v4l2_async_register_fwnode_subdev() that
  forgot to put device.

v2:
- don't pass an empty endpoint to the parse_endpoint callback, 
  v4l2_async_notifier_fwnode_parse_endpoint() now just ignores them
  and returns success.
- Fix a couple compile warnings and errors seen in i386 and sh archs.


Steve Longerbeam (13):
  media: v4l2-fwnode: ignore endpoints that have no remote port parent
  media: v4l2: async: Allow searching for asd of any type
  media: v4l2: async: Add v4l2_async_notifier_add_subdev
  media: v4l2-fwnode: Switch to v4l2_async_notifier_add_subdev
  media: v4l2-fwnode: Add a convenience function for registering subdevs
with notifiers
  media: platform: video-mux: Register a subdev notifier
  media: imx: csi: Register a subdev notifier
  media: imx: mipi csi-2: Register a subdev notifier
  media: staging/imx: of: Remove recursive graph walk
  media: staging/imx: Loop through all registered subdevs for media
links
  media: staging/imx: Rename root notifier
  media: staging/imx: Switch to v4l2_async_notifier_add_subdev
  media: staging/imx: TODO: Remove one assumption about OF graph parsing

 drivers/media/pci/intel/ipu3/ipu3-cio2.c  |  10 +-
 drivers/media/platform/video-mux.c|  36 ++-
 drivers/media/v4l2-core/v4l2-async.c  | 268 --
 drivers/media/v4l2-core/v4l2-fwnode.c | 231 +++
 drivers/staging/media/imx/TODO|  29 +--
 drivers/staging/media/imx/imx-media-csi.c |  11 +-
 drivers/staging/media/imx/imx-media-dev.c | 134 +++
 drivers/staging/media/imx/imx-media-internal-sd.c |   5 +-
 drivers/staging/media/imx/imx-media-of.c  | 106 +
 drivers/staging/media/imx/imx-media.h |   6 +-
 drivers/staging/media/imx/imx6-mipi-csi2.c|  31 ++-
 include/media/v4l2-async.h|  24 +-
 include/media/v4l2-fwnode.h   |  65 +-
 13 files changed, 534 insertions(+), 422 deletions(-)

-- 
2.7.4

[PATCH v3 03/13] media: v4l2: async: Add v4l2_async_notifier_add_subdev

2018-03-20 Thread Steve Longerbeam

v4l2_async_notifier_add_subdev() adds an asd to the notifier. It checks
that the asd's match_type is valid and that no other equivalent asd's
have already been added to this notifier's asd list, or to other
registered notifier's waiting or done lists, and increments num_subdevs.

v4l2_async_notifier_add_subdev() does not make use of the notifier subdevs
array, otherwise it would have to re-allocate the array every time the
function was called. In place of the subdevs array, the function adds
the asd to a new master asd_list. The function will return error with a
WARN() if it is ever called with the subdevs array allocated.

In v4l2_async_notifier_has_async_subdev(), __v4l2_async_notifier_register(),
and v4l2_async_notifier_cleanup(), alternatively operate on the subdevs
array or a non-empty notifier->asd_list.

Signed-off-by: Steve Longerbeam 
---
Changes since v2:
- add a NULL asd pointer check to v4l2_async_notifier_asd_valid().
Changes since v1:
- none
---
 drivers/media/v4l2-core/v4l2-async.c | 206 +++
 include/media/v4l2-async.h   |  22 
 2 files changed, 184 insertions(+), 44 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index b59bbac..7b7f7e2 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -366,16 +366,26 @@ static bool v4l2_async_notifier_has_async_subdev(
struct v4l2_async_notifier *notifier, struct v4l2_async_subdev *asd,
unsigned int this_index)
 {
+   struct v4l2_async_subdev *asd_y;
unsigned int j;
 
lockdep_assert_held(&list_lock);
 
/* Check that an asd is not being added more than once. */
-   for (j = 0; j < this_index; j++) {
-   struct v4l2_async_subdev *asd_y = notifier->subdevs[j];
-
-   if (asd_equal(asd, asd_y))
-   return true;
+   if (notifier->subdevs) {
+   for (j = 0; j < this_index; j++) {
+   asd_y = notifier->subdevs[j];
+   if (asd_equal(asd, asd_y))
+   return true;
+   }
+   } else {
+   j = 0;
+   list_for_each_entry(asd_y, ¬ifier->asd_list, asd_list) {
+   if (j++ >= this_index)
+   break;
+   if (asd_equal(asd, asd_y))
+   return true;
+   }
}
 
/* Check that an asd does not exist in other notifiers. */
@@ -386,10 +396,46 @@ static bool v4l2_async_notifier_has_async_subdev(
return false;
 }
 
-static int __v4l2_async_notifier_register(struct v4l2_async_notifier *notifier)
+static int v4l2_async_notifier_asd_valid(struct v4l2_async_notifier *notifier,
+struct v4l2_async_subdev *asd,
+unsigned int this_index)
 {
struct device *dev =
notifier->v4l2_dev ? notifier->v4l2_dev->dev : NULL;
+
+   if (!asd)
+   return -EINVAL;
+
+   switch (asd->match_type) {
+   case V4L2_ASYNC_MATCH_CUSTOM:
+   case V4L2_ASYNC_MATCH_DEVNAME:
+   case V4L2_ASYNC_MATCH_I2C:
+   case V4L2_ASYNC_MATCH_FWNODE:
+   if (v4l2_async_notifier_has_async_subdev(notifier, asd,
+this_index))
+   return -EEXIST;
+   break;
+   default:
+   dev_err(dev, "Invalid match type %u on %p\n",
+   asd->match_type, asd);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static void __v4l2_async_notifier_init(struct v4l2_async_notifier *notifier)
+{
+   lockdep_assert_held(&list_lock);
+
+   INIT_LIST_HEAD(¬ifier->asd_list);
+   INIT_LIST_HEAD(¬ifier->waiting);
+   INIT_LIST_HEAD(¬ifier->done);
+   notifier->lists_initialized = true;
+}
+
+static int __v4l2_async_notifier_register(struct v4l2_async_notifier *notifier)
+{
struct v4l2_async_subdev *asd;
int ret;
int i;
@@ -397,34 +443,40 @@ static int __v4l2_async_notifier_register(struct 
v4l2_async_notifier *notifier)
if (notifier->num_subdevs > V4L2_MAX_SUBDEVS)
return -EINVAL;
 
-   INIT_LIST_HEAD(¬ifier->waiting);
-   INIT_LIST_HEAD(¬ifier->done);
-
mutex_lock(&list_lock);
 
-   for (i = 0; i < notifier->num_subdevs; i++) {
-   asd = notifier->subdevs[i];
+   if (!notifier->lists_initialized)
+   __v4l2_async_notifier_init(notifier);
 
-   switch (asd->match_type) {
-   case V4L2_ASYNC_MATCH_CUSTOM:
-   case V4L2_ASYNC_MATCH_DEVNAME:
-   case V4L2_ASYNC_MATCH_I2C:
-   case V4L2_ASYNC_MATCH_FWNODE:
-   if (v4l2_async_notifier_has_async_subdev(
-   notifier, asd, i))

[PATCH v3 05/13] media: v4l2-fwnode: Add a convenience function for registering subdevs with notifiers

2018-03-20 Thread Steve Longerbeam

Adds v4l2_async_register_fwnode_subdev(), which is a convenience function
for parsing a sub-device's fwnode port endpoints for connected remote
sub-devices, registering a sub-device notifier, and then registering
the sub-device itself.

Signed-off-by: Steve Longerbeam 
---
Changes since v2:
- fix error-out path in v4l2_async_register_fwnode_subdev() that forgot
  to put device.
Changes since v1:
- add #include  to v4l2-fwnode.h for
  'struct v4l2_subdev' declaration.
---
 drivers/media/v4l2-core/v4l2-fwnode.c | 101 ++
 include/media/v4l2-fwnode.h   |  43 +++
 2 files changed, 144 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index 99198b9..d42024d 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -880,6 +880,107 @@ int v4l2_async_register_subdev_sensor_common(struct 
v4l2_subdev *sd)
 }
 EXPORT_SYMBOL_GPL(v4l2_async_register_subdev_sensor_common);
 
+int v4l2_async_register_fwnode_subdev(
+   struct v4l2_subdev *sd, size_t asd_struct_size,
+   unsigned int *ports, unsigned int num_ports,
+   int (*parse_endpoint)(struct device *dev,
+ struct v4l2_fwnode_endpoint *vep,
+ struct v4l2_async_subdev *asd))
+{
+   struct v4l2_async_notifier *notifier;
+   struct device *dev = sd->dev;
+   struct fwnode_handle *fwnode;
+   unsigned int subdev_port;
+   bool is_port;
+   int ret;
+
+   if (WARN_ON(!dev))
+   return -ENODEV;
+
+   fwnode = dev_fwnode(dev);
+   if (!fwnode_device_is_available(fwnode))
+   return -ENODEV;
+
+   is_port = (is_of_node(fwnode) &&
+  of_node_cmp(to_of_node(fwnode)->name, "port") == 0);
+
+   /*
+* If the sub-device is a port, only parse fwnode endpoints from
+* this sub-device's single port id.
+*/
+   if (is_port) {
+   /* verify the caller did not provide a ports array */
+   if (ports)
+   return -EINVAL;
+
+   ret = fwnode_property_read_u32(fwnode, "reg", &subdev_port);
+   if (ret < 0)
+   return ret;
+
+   /*
+* the device given to the fwnode endpoint parsing
+* must be the port sub-device's parent.
+*/
+   dev = get_device(sd->dev->parent);
+
+   if (WARN_ON(!dev))
+   return -ENODEV;
+
+   ports = &subdev_port;
+   num_ports = 1;
+   }
+
+   notifier = kzalloc(sizeof(*notifier), GFP_KERNEL);
+   if (!notifier) {
+   ret = -ENOMEM;
+   goto out_putdev;
+   }
+
+   if (!ports) {
+   ret = v4l2_async_notifier_parse_fwnode_endpoints(
+   dev, notifier, asd_struct_size, parse_endpoint);
+   if (ret < 0)
+   goto out_cleanup;
+   } else {
+   unsigned int i;
+
+   for (i = 0; i < num_ports; i++) {
+   ret = 
v4l2_async_notifier_parse_fwnode_endpoints_by_port(
+   dev, notifier, asd_struct_size,
+   ports[i], parse_endpoint);
+   if (ret < 0)
+   goto out_cleanup;
+   }
+   }
+
+   ret = v4l2_async_subdev_notifier_register(sd, notifier);
+   if (ret < 0)
+   goto out_cleanup;
+
+   ret = v4l2_async_register_subdev(sd);
+   if (ret < 0)
+   goto out_unregister;
+
+   sd->subdev_notifier = notifier;
+
+   if (is_port)
+   put_device(dev);
+
+   return 0;
+
+out_unregister:
+   v4l2_async_notifier_unregister(notifier);
+out_cleanup:
+   v4l2_async_notifier_cleanup(notifier);
+   kfree(notifier);
+out_putdev:
+   if (is_port)
+   put_device(dev);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(v4l2_async_register_fwnode_subdev);
+
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Sakari Ailus ");
 MODULE_AUTHOR("Sylwester Nawrocki ");
diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h
index 9a4b3f8..4de0ac2 100644
--- a/include/media/v4l2-fwnode.h
+++ b/include/media/v4l2-fwnode.h
@@ -23,6 +23,7 @@
 #include 
 
 #include 
+#include 
 
 struct fwnode_handle;
 struct v4l2_async_notifier;
@@ -360,4 +361,46 @@ int v4l2_async_notifier_parse_fwnode_endpoints_by_port(
 int v4l2_async_notifier_parse_fwnode_sensor_common(
struct device *dev, struct v4l2_async_notifier *notifier);
 
+/**
+ * v4l2_async_register_fwnode_subdev - registers a sub-device to the
+ * asynchronous sub-device framework
+ * and parses fwnode endpoints
+ *
+ * @sd: pointer to struct &v4l2_subdev
+ * @asd_struct_size: size of the driver'

[PATCH v3 07/13] media: imx: csi: Register a subdev notifier

2018-03-20 Thread Steve Longerbeam

Parse neighbor remote devices on the CSI port, add them to a subdev
notifier, and register the subdev notifier for the CSI, by calling
v4l2_async_register_fwnode_subdev().

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-csi.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 5a195f8..87cf277 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1736,6 +1736,13 @@ static const struct v4l2_subdev_internal_ops 
csi_internal_ops = {
.unregistered = csi_unregistered,
 };
 
+static int imx_csi_parse_endpoint(struct device *dev,
+ struct v4l2_fwnode_endpoint *vep,
+ struct v4l2_async_subdev *asd)
+{
+   return fwnode_device_is_available(asd->match.fwnode) ? 0 : -EINVAL;
+}
+
 static int imx_csi_probe(struct platform_device *pdev)
 {
struct ipu_client_platformdata *pdata;
@@ -1802,7 +1809,9 @@ static int imx_csi_probe(struct platform_device *pdev)
goto free;
}
 
-   ret = v4l2_async_register_subdev(&priv->sd);
+   ret = v4l2_async_register_fwnode_subdev(
+   &priv->sd, sizeof(struct v4l2_async_subdev),
+   NULL, 0, imx_csi_parse_endpoint);
if (ret)
goto free;
 
-- 
2.7.4

[PATCH v3 01/13] media: v4l2-fwnode: ignore endpoints that have no remote port parent

2018-03-20 Thread Steve Longerbeam

Documentation/devicetree/bindings/media/video-interfaces.txt states that
the 'remote-endpoint' property is optional.

So v4l2_async_notifier_fwnode_parse_endpoint() should not return error
if the endpoint has no remote port parent. Just ignore the endpoint,
skip adding an asd to the notifier and return 0.
__v4l2_async_notifier_parse_fwnode_endpoints() will then continue
parsing the remaining port endpoints of the device.

Signed-off-by: Steve Longerbeam 
---
Changes since v2:
- none
Changes since v1:
- don't pass an empty endpoint to the parse_endpoint callback,
  v4l2_async_notifier_fwnode_parse_endpoint() now just ignores them
  and returns success. The current users of
  v4l2_async_notifier_parse_fwnode_endpoints() (omap3isp, rcar-vin,
  intel-ipu3) no longer need modification.
---
 drivers/media/v4l2-core/v4l2-fwnode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index d630640..b8afbac 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -363,7 +363,7 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
fwnode_graph_get_remote_port_parent(endpoint);
if (!asd->match.fwnode) {
dev_warn(dev, "bad remote port parent\n");
-   ret = -EINVAL;
+   ret = -ENOTCONN;
goto out_err;
}
 
-- 
2.7.4

[PATCH v3 06/13] media: platform: video-mux: Register a subdev notifier

2018-03-20 Thread Steve Longerbeam

Parse neighbor remote devices on the video muxes input ports, add them to a
subdev notifier, and register the subdev notifier for the video mux, by
calling v4l2_async_register_fwnode_subdev().

Signed-off-by: Steve Longerbeam 
---
Changes since v2:
- none
Changes since v1:
- add #include  for kcalloc() declaration.
---
 drivers/media/platform/video-mux.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/video-mux.c 
b/drivers/media/platform/video-mux.c
index ee89ad7..b93b0af 100644
--- a/drivers/media/platform/video-mux.c
+++ b/drivers/media/platform/video-mux.c
@@ -21,8 +21,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 struct video_mux {
@@ -193,6 +195,38 @@ static const struct v4l2_subdev_ops video_mux_subdev_ops = 
{
.video = &video_mux_subdev_video_ops,
 };
 
+static int video_mux_parse_endpoint(struct device *dev,
+   struct v4l2_fwnode_endpoint *vep,
+   struct v4l2_async_subdev *asd)
+{
+   /*
+* it's not an error if remote is missing on a video-mux
+* input port, return -ENOTCONN to skip this endpoint with
+* no error.
+*/
+   return fwnode_device_is_available(asd->match.fwnode) ? 0 : -ENOTCONN;
+}
+
+static int video_mux_async_register(struct video_mux *vmux,
+   unsigned int num_pads)
+{
+   unsigned int i, *ports;
+   int ret;
+
+   ports = kcalloc(num_pads - 1, sizeof(*ports), GFP_KERNEL);
+   if (!ports)
+   return -ENOMEM;
+   for (i = 0; i < num_pads - 1; i++)
+   ports[i] = i;
+
+   ret = v4l2_async_register_fwnode_subdev(
+   &vmux->subdev, sizeof(struct v4l2_async_subdev),
+   ports, num_pads - 1, video_mux_parse_endpoint);
+
+   kfree(ports);
+   return ret;
+}
+
 static int video_mux_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
@@ -258,7 +292,7 @@ static int video_mux_probe(struct platform_device *pdev)
 
vmux->subdev.entity.ops = &video_mux_ops;
 
-   return v4l2_async_register_subdev(&vmux->subdev);
+   return video_mux_async_register(vmux, num_pads);
 }
 
 static int video_mux_remove(struct platform_device *pdev)
-- 
2.7.4

[PATCH v3 04/13] media: v4l2-fwnode: Switch to v4l2_async_notifier_add_subdev

2018-03-20 Thread Steve Longerbeam

The fwnode endpoint and reference parsing functions in v4l2-fwnode.c
are modified to make use of v4l2_async_notifier_add_subdev(). As a
result the notifier->subdevs array is no longer allocated or
re-allocated, and by extension the max_subdevs value is also no
longer needed.

Since the notifier->subdevs array is no longer allocated in the
fwnode endpoint and reference parsing functions, the callers of
those functions must never reference that array, since it is now
NULL. Of the drivers that make use of the fwnode/ref parsing,
only the intel-ipu3 driver references the ->subdevs[] array,
(in the notifier completion callback), so that driver has been
modified to iterate through the notifier->asd_list instead.

Signed-off-by: Steve Longerbeam 
---
 drivers/media/pci/intel/ipu3/ipu3-cio2.c |  10 +--
 drivers/media/v4l2-core/v4l2-async.c |   4 -
 drivers/media/v4l2-core/v4l2-fwnode.c| 128 ---
 include/media/v4l2-async.h   |   2 -
 include/media/v4l2-fwnode.h  |  22 +++---
 5 files changed, 51 insertions(+), 115 deletions(-)

diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c 
b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
index 7d768ec..b0cadc8 100644
--- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
@@ -1423,13 +1423,13 @@ static int cio2_notifier_complete(struct 
v4l2_async_notifier *notifier)
struct cio2_device *cio2 = container_of(notifier, struct cio2_device,
notifier);
struct sensor_async_subdev *s_asd;
+   struct v4l2_async_subdev *asd;
struct cio2_queue *q;
-   unsigned int i, pad;
+   unsigned int pad;
int ret;
 
-   for (i = 0; i < notifier->num_subdevs; i++) {
-   s_asd = container_of(cio2->notifier.subdevs[i],
-struct sensor_async_subdev, asd);
+   list_for_each_entry(asd, &cio2->notifier.asd_list, asd_list) {
+   s_asd = container_of(asd, struct sensor_async_subdev, asd);
q = &cio2->queue[s_asd->csi2.port];
 
for (pad = 0; pad < q->sensor->entity.num_pads; pad++)
@@ -1451,7 +1451,7 @@ static int cio2_notifier_complete(struct 
v4l2_async_notifier *notifier)
if (ret) {
dev_err(&cio2->pci_dev->dev,
"failed to create link for %s\n",
-   cio2->queue[i].sensor->name);
+   q->sensor->name);
return ret;
}
}
diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 7b7f7e2..7fa5de0 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -575,9 +575,6 @@ static void __v4l2_async_notifier_cleanup(struct 
v4l2_async_notifier *notifier)
return;
 
if (notifier->subdevs) {
-   if (!notifier->max_subdevs)
-   return;
-
for (i = 0; i < notifier->num_subdevs; i++) {
asd = notifier->subdevs[i];
 
@@ -592,7 +589,6 @@ static void __v4l2_async_notifier_cleanup(struct 
v4l2_async_notifier *notifier)
kfree(asd);
}
 
-   notifier->max_subdevs = 0;
kvfree(notifier->subdevs);
notifier->subdevs = NULL;
} else if (notifier->lists_initialized) {
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index b8afbac..99198b9 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -316,33 +316,6 @@ void v4l2_fwnode_put_link(struct v4l2_fwnode_link *link)
 }
 EXPORT_SYMBOL_GPL(v4l2_fwnode_put_link);
 
-static int v4l2_async_notifier_realloc(struct v4l2_async_notifier *notifier,
-  unsigned int max_subdevs)
-{
-   struct v4l2_async_subdev **subdevs;
-
-   if (max_subdevs <= notifier->max_subdevs)
-   return 0;
-
-   subdevs = kvmalloc_array(
-   max_subdevs, sizeof(*notifier->subdevs),
-   GFP_KERNEL | __GFP_ZERO);
-   if (!subdevs)
-   return -ENOMEM;
-
-   if (notifier->subdevs) {
-   memcpy(subdevs, notifier->subdevs,
-  sizeof(*subdevs) * notifier->num_subdevs);
-
-   kvfree(notifier->subdevs);
-   }
-
-   notifier->subdevs = subdevs;
-   notifier->max_subdevs = max_subdevs;
-
-   return 0;
-}
-
 static int v4l2_async_notifier_fwnode_parse_endpoint(
struct device *dev, struct v4l2_async_notifier *notifier,
struct fwnode_handle *endpoint, unsigned int asd_struct_size,
@@ -387,8 +360,13 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
if (ret < 0)
goto out_err;
 
-   notifier->subdevs[notifier->num_subdevs] = asd;
-

[PATCH v3 08/13] media: imx: mipi csi-2: Register a subdev notifier

2018-03-20 Thread Steve Longerbeam

Parse neighbor remote devices on the MIPI CSI-2 input port, add
them to a subdev notifier, and register the subdev notifier for the
MIPI CSI-2 receiver, by calling v4l2_async_register_fwnode_subdev().

csi2_parse_endpoints() is modified to be the parse_endpoint callback.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx6-mipi-csi2.c | 31 ++
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c 
b/drivers/staging/media/imx/imx6-mipi-csi2.c
index ceeeb30..94eb9a1 100644
--- a/drivers/staging/media/imx/imx6-mipi-csi2.c
+++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
@@ -551,35 +551,34 @@ static const struct v4l2_subdev_internal_ops 
csi2_internal_ops = {
.registered = csi2_registered,
 };
 
-static int csi2_parse_endpoints(struct csi2_dev *csi2)
+static int csi2_parse_endpoint(struct device *dev,
+  struct v4l2_fwnode_endpoint *vep,
+  struct v4l2_async_subdev *asd)
 {
-   struct device_node *node = csi2->dev->of_node;
-   struct device_node *epnode;
-   struct v4l2_fwnode_endpoint ep;
+   struct v4l2_subdev *sd = dev_get_drvdata(dev);
+   struct csi2_dev *csi2 = sd_to_dev(sd);
 
-   epnode = of_graph_get_endpoint_by_regs(node, 0, -1);
-   if (!epnode) {
-   v4l2_err(&csi2->sd, "failed to get sink endpoint node\n");
+   if (!fwnode_device_is_available(asd->match.fwnode)) {
+   v4l2_err(&csi2->sd, "remote is not available\n");
return -EINVAL;
}
 
-   v4l2_fwnode_endpoint_parse(of_fwnode_handle(epnode), &ep);
-   of_node_put(epnode);
-
-   if (ep.bus_type != V4L2_MBUS_CSI2) {
+   if (vep->bus_type != V4L2_MBUS_CSI2) {
v4l2_err(&csi2->sd, "invalid bus type, must be MIPI CSI2\n");
return -EINVAL;
}
 
-   csi2->bus = ep.bus.mipi_csi2;
+   csi2->bus = vep->bus.mipi_csi2;
 
dev_dbg(csi2->dev, "data lanes: %d\n", csi2->bus.num_data_lanes);
dev_dbg(csi2->dev, "flags: 0x%08x\n", csi2->bus.flags);
+
return 0;
 }
 
 static int csi2_probe(struct platform_device *pdev)
 {
+   unsigned int sink_port = 0;
struct csi2_dev *csi2;
struct resource *res;
int ret;
@@ -601,10 +600,6 @@ static int csi2_probe(struct platform_device *pdev)
csi2->sd.entity.function = MEDIA_ENT_F_VID_IF_BRIDGE;
csi2->sd.grp_id = IMX_MEDIA_GRP_ID_CSI2;
 
-   ret = csi2_parse_endpoints(csi2);
-   if (ret)
-   return ret;
-
csi2->pllref_clk = devm_clk_get(&pdev->dev, "ref");
if (IS_ERR(csi2->pllref_clk)) {
v4l2_err(&csi2->sd, "failed to get pll reference clock\n");
@@ -654,7 +649,9 @@ static int csi2_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, &csi2->sd);
 
-   ret = v4l2_async_register_subdev(&csi2->sd);
+   ret = v4l2_async_register_fwnode_subdev(
+   &csi2->sd, sizeof(struct v4l2_async_subdev),
+   &sink_port, 1, csi2_parse_endpoint);
if (ret)
goto dphy_off;
 
-- 
2.7.4

(Relief Coordinator, United Nations)

2018-03-20 Thread UNCU

United Nations Compensation Unit, Emergency Relief Coordinator, United Nations.




Congratulations Beneficiary,




We have been having a meeting for quit sometime now and we just came to a 
logical conclusion 72 hours ago in affiliation with the World Bank president. 
Your email was listed among those that are yet to receive their compensation 
payment. The United Nations in Affiliation with World Bank have agreed to 
compensate them with the sum of USD1,500, 000.00 (One Million Five Hundred 
Thousand United States Dollars) only.


For this reason, you are to receive your payment through a certified ATM MASTER 
CARD. Note, with this Master Card you can withdraw money from any part of the 
World without being disturbed or delay and please for no reason should you 
disclose your account information as your account information is not and can 
never be needed before you receive your card payment. All that is required of 
your now is to contact our 100% trust officials by the Name of Mrs. Sarah 
Nonye. Below is her contact information:


Name: Mrs. Sarah Nonye
Email: sarahnony...@gmail.com


Please ensure that you follow the directives and instructions of Mrs. Sarah 
Nonye so that within 72 hours you would have received your card payment and 
your secret pin code issued directly to you for security reasons. We apologize 
on behalf of the United Nation Organization for any delay you might have 
encountered in receiving your fund in the past. Congratulations, and I look 
forward to hear from you as soon as you confirm your payment making the world a 
better place.


Yours Faithfully,


Dave Skellorn
Emergency Relief Coordinator, United Nations.

[PATCH 4/5] [media] ddbridge: add SPDX license headers

2018-03-20 Thread Daniel Scheller

From: Daniel Scheller 

Add SPDX license headers in all ddbridge driver files and fix
MODULE_LICENSE accordingly. Also, apply some cosmetics to the file
headers.

Signed-off-by: Daniel Scheller 
---
 drivers/media/pci/ddbridge/Makefile| 2 +-
 drivers/media/pci/ddbridge/ddbridge-ci.c   | 6 ++
 drivers/media/pci/ddbridge/ddbridge-ci.h   | 6 ++
 drivers/media/pci/ddbridge/ddbridge-core.c | 8 ++--
 drivers/media/pci/ddbridge/ddbridge-hw.c   | 4 ++--
 drivers/media/pci/ddbridge/ddbridge-hw.h   | 4 ++--
 drivers/media/pci/ddbridge/ddbridge-i2c.c  | 4 ++--
 drivers/media/pci/ddbridge/ddbridge-i2c.h  | 4 ++--
 drivers/media/pci/ddbridge/ddbridge-io.h   | 4 ++--
 drivers/media/pci/ddbridge/ddbridge-main.c | 8 
 drivers/media/pci/ddbridge/ddbridge-max.c  | 4 ++--
 drivers/media/pci/ddbridge/ddbridge-max.h  | 4 ++--
 drivers/media/pci/ddbridge/ddbridge-regs.h | 7 ++-
 drivers/media/pci/ddbridge/ddbridge.h  | 7 ++-
 14 files changed, 29 insertions(+), 43 deletions(-)

diff --git a/drivers/media/pci/ddbridge/Makefile 
b/drivers/media/pci/ddbridge/Makefile
index 745b37d07558..c79bbc6d6276 100644
--- a/drivers/media/pci/ddbridge/Makefile
+++ b/drivers/media/pci/ddbridge/Makefile
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: GPL-2.0-only
 #
 # Makefile for the ddbridge device driver
 #
diff --git a/drivers/media/pci/ddbridge/ddbridge-ci.c 
b/drivers/media/pci/ddbridge/ddbridge-ci.c
index cfe23d02e561..99a2d36e93b3 100644
--- a/drivers/media/pci/ddbridge/ddbridge-ci.c
+++ b/drivers/media/pci/ddbridge/ddbridge-ci.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * ddbridge-ci.c: Digital Devices bridge CI (DuoFlex, CI Bridge) support
  *
@@ -11,11 +12,8 @@
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
- *
- * To obtain the license, point your browser to
- * http://www.gnu.org/copyleft/gpl.html
  */
 
 #include "ddbridge.h"
diff --git a/drivers/media/pci/ddbridge/ddbridge-ci.h 
b/drivers/media/pci/ddbridge/ddbridge-ci.h
index 35a39182dd83..1458b38d82e7 100644
--- a/drivers/media/pci/ddbridge/ddbridge-ci.h
+++ b/drivers/media/pci/ddbridge/ddbridge-ci.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*
  * ddbridge-ci.h: Digital Devices bridge CI (DuoFlex, CI Bridge) support
  *
@@ -11,11 +12,8 @@
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
- *
- * To obtain the license, point your browser to
- * http://www.gnu.org/copyleft/gpl.html
  */
 
 #ifndef __DDBRIDGE_CI_H__
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 90687eff5909..2ec84ca516f1 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * ddbridge-core.c: Digital Devices bridge core functions
  *
@@ -5,19 +6,14 @@
  * Marcus Metzler 
  * Ralph Metzler 
  *
- *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
  * version 2 only, as published by the Free Software Foundation.
  *
- *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
- *
- * To obtain the license, point your browser to
- * http://www.gnu.org/copyleft/gpl.html
  */
 
 #include 
diff --git a/drivers/media/pci/ddbridge/ddbridge-hw.c 
b/drivers/media/pci/ddbridge/ddbridge-hw.c
index c6d14925e2fc..be3eaf682455 100644
--- a/drivers/media/pci/ddbridge/ddbridge-hw.c
+++ b/drivers/media/pci/ddbridge/ddbridge-hw.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * ddbridge-hw.c: Digital Devices bridge hardware maps
  *
@@ -11,9 +12,8 @@
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
- *
  */
 
 #include "ddbridge.h"
diff --git a/drivers/media/pci/ddbridge/ddbridge-hw.h 
b/drivers/media/pci/ddbridge/ddbridge-hw.h
index 7c142419419c..79e76bf

[PATCH 2/5] [media] dvb-frontends/mxl5xx: add SPDX license headers

2018-03-20 Thread Daniel Scheller

From: Daniel Scheller 

Add SPDX license headers to the mxl5xx DVB frontend driver and it's
related includes, and fix MODULE_LICENSE while at it.

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/mxl5xx.c  |  6 +++---
 drivers/media/dvb-frontends/mxl5xx.h  | 13 +
 drivers/media/dvb-frontends/mxl5xx_defs.h |  1 +
 drivers/media/dvb-frontends/mxl5xx_regs.h |  4 ++--
 4 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb-frontends/mxl5xx.c 
b/drivers/media/dvb-frontends/mxl5xx.c
index 483ee7d6198e..57ea61f53dbe 100644
--- a/drivers/media/dvb-frontends/mxl5xx.c
+++ b/drivers/media/dvb-frontends/mxl5xx.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * Driver for the MaxLinear MxL5xx family of tuners/demods
  *
@@ -15,9 +16,8 @@
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
- *
  */
 
 #include 
@@ -1895,4 +1895,4 @@ EXPORT_SYMBOL_GPL(mxl5xx_attach);
 
 MODULE_DESCRIPTION("MaxLinear MxL5xx DVB-S/S2 tuner-demodulator driver");
 MODULE_AUTHOR("Ralph and Marcus Metzler, Metzler Brothers Systementwicklung 
GbR");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/dvb-frontends/mxl5xx.h 
b/drivers/media/dvb-frontends/mxl5xx.h
index ad4c21846800..34e786dc7bb9 100644
--- a/drivers/media/dvb-frontends/mxl5xx.h
+++ b/drivers/media/dvb-frontends/mxl5xx.h
@@ -1,3 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Driver for the MaxLinear MxL5xx family of tuners/demods
+ *
+ * Copyright (C) 2014-2015 Ralph Metzler 
+ * Marcus Metzler 
+ * developed for Digital Devices GmbH
+ *
+ * based on code:
+ * Copyright (c) 2011-2013 MaxLinear, Inc. All rights reserved
+ * which was released under GPL V2
+ */
+
 #ifndef _MXL5XX_H_
 #define _MXL5XX_H_
 
diff --git a/drivers/media/dvb-frontends/mxl5xx_defs.h 
b/drivers/media/dvb-frontends/mxl5xx_defs.h
index fd9e61e0188f..a6062b4b39cb 100644
--- a/drivers/media/dvb-frontends/mxl5xx_defs.h
+++ b/drivers/media/dvb-frontends/mxl5xx_defs.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*
  * Defines for the Maxlinear MX58x family of tuners/demods
  *
diff --git a/drivers/media/dvb-frontends/mxl5xx_regs.h 
b/drivers/media/dvb-frontends/mxl5xx_regs.h
index 5001dafe1ba8..d231151c437f 100644
--- a/drivers/media/dvb-frontends/mxl5xx_regs.h
+++ b/drivers/media/dvb-frontends/mxl5xx_regs.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*
  * Copyright (c) 2011-2013 MaxLinear, Inc. All rights reserved
  *
@@ -9,11 +10,10 @@
  *
  * This program is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
FITNESS
- * FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more 
details.
+ * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more 
details.
  *
  * This program may alternatively be licensed under a proprietary license from
  * MaxLinear, Inc.
- *
  */
 
 #ifndef __MXL58X_REGISTERS_H__
-- 
2.16.1

[PATCH 5/5] [media] ngene: add SPDX license headers

2018-03-20 Thread Daniel Scheller

From: Daniel Scheller 

Add SPDX license headers in all ngene driver files and fix MODULE_LICENSE
accordingly.

Signed-off-by: Daniel Scheller 
---
 drivers/media/pci/ngene/Makefile  |  2 +-
 drivers/media/pci/ngene/ngene-cards.c | 10 +++---
 drivers/media/pci/ngene/ngene-core.c  |  8 ++--
 drivers/media/pci/ngene/ngene-dvb.c   |  8 ++--
 drivers/media/pci/ngene/ngene-i2c.c   |  8 ++--
 drivers/media/pci/ngene/ngene.h   |  7 ++-
 6 files changed, 12 insertions(+), 31 deletions(-)

diff --git a/drivers/media/pci/ngene/Makefile b/drivers/media/pci/ngene/Makefile
index ec450ad19281..115152c96d50 100644
--- a/drivers/media/pci/ngene/Makefile
+++ b/drivers/media/pci/ngene/Makefile
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: GPL-2.0-only
 #
 # Makefile for the nGene device driver
 #
diff --git a/drivers/media/pci/ngene/ngene-cards.c 
b/drivers/media/pci/ngene/ngene-cards.c
index 65fc8f23ad86..23fb6f33fa49 100644
--- a/drivers/media/pci/ngene/ngene-cards.c
+++ b/drivers/media/pci/ngene/ngene-cards.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * ngene-cards.c: nGene PCIe bridge driver - card specific info
  *
@@ -8,19 +9,14 @@
  * support for EEPROM-copying,
  * support for new dual DVB-S2 card prototype
  *
- *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
  * version 2 only, as published by the Free Software Foundation.
  *
- *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
- *
- * To obtain the license, point your browser to
- * http://www.gnu.org/copyleft/gpl.html
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -1265,4 +1261,4 @@ module_exit(module_exit_ngene);
 
 MODULE_DESCRIPTION("nGene");
 MODULE_AUTHOR("Micronas, Ralph Metzler, Manfred Voelkel");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/pci/ngene/ngene-core.c 
b/drivers/media/pci/ngene/ngene-core.c
index 3b9a1bfaf6c0..5da1c2b9732f 100644
--- a/drivers/media/pci/ngene/ngene-core.c
+++ b/drivers/media/pci/ngene/ngene-core.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * ngene.c: nGene PCIe bridge driver
  *
@@ -8,19 +9,14 @@
  * support for EEPROM-copying,
  * support for new dual DVB-S2 card prototype
  *
- *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
  * version 2 only, as published by the Free Software Foundation.
  *
- *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
- *
- * To obtain the license, point your browser to
- * http://www.gnu.org/copyleft/gpl.html
  */
 
 #include 
diff --git a/drivers/media/pci/ngene/ngene-dvb.c 
b/drivers/media/pci/ngene/ngene-dvb.c
index fee89b9ed9c1..fe250f4d37de 100644
--- a/drivers/media/pci/ngene/ngene-dvb.c
+++ b/drivers/media/pci/ngene/ngene-dvb.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * ngene-dvb.c: nGene PCIe bridge driver - DVB functions
  *
@@ -8,19 +9,14 @@
  * support for EEPROM-copying,
  * support for new dual DVB-S2 card prototype
  *
- *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
  * version 2 only, as published by the Free Software Foundation.
  *
- *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
- *
- * To obtain the license, point your browser to
- * http://www.gnu.org/copyleft/gpl.html
  */
 
 #include 
diff --git a/drivers/media/pci/ngene/ngene-i2c.c 
b/drivers/media/pci/ngene/ngene-i2c.c
index 092d46c2a3a9..f023a6764dd4 100644
--- a/drivers/media/pci/ngene/ngene-i2c.c
+++ b/drivers/media/pci/ngene/ngene-i2c.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * ngene-i2c.c: nGene PCIe bridge driver i2c functions
  *
@@ -8,19 +9,14 @@
  * support for EEPROM-copying,
  * support for new dual DVB-S2 card prototype
  *
- *
  * This program is free software; you can redistribute it and/or
  *

[PATCH 0/5] SPDX license identifiers in all DD drivers

2018-03-20 Thread Daniel Scheller

From: Daniel Scheller 

This series adds SPDX license identifiers to all source files which are
copyright by either Digital Devices GmbH or Metzlerbros GbR, who are
the original authors of the ddbridge, ngene, cxd2099, mxl5xx, stv0910
and stv6111 bridge/demod/tuner drivers, with the mxl5xx driver being
based on source code released by MaxLinear.

All source code either carries the license text "redistribute and/or
modify it under the terms of the GNU GPL version 2 only as published
by the FSF", or simply "... GPL version 2" in the case of the mxl5xx
driver, which all should equal to the SPDX License Identifier
"GPL-2.0-only" as of SPDX License List Version 3.0 published on
December the 28th, 2017, which is applied as license tag to all files
of the mentioned drivers by this series.

During checking of those modules I noticed that the module info carries
the "GPL" version tag, which, according to include/linux/module.h, equals
to "GPL version 2 or later", which (I believe) in turn is a mismatch to
what is written in the file header's license boilerplates. This series
corrects this by setting all MODULE_LICENSE() descriptors to "GPL v2",
which equals to the "GNU GPL version 2 only" phrase.

Besides that, this fixes some whitespace cosmetics in the headers, and
removes the link to gnu.org (if existing), which points to the GPLv3
license anyway.

The original intention was to fully replace all the licensing headers
with only the SPDX License Identifiers as it is done in a lot of other
in-tree drivers nowadays. However, Digital Devices disagreed to do this
and expressed major concerns regarding this, in that a machine readable
license tag instead of a full license boilerplate won't hold up equally,
so we agreed to keep the license boilerplate text as is right now.

Greg, I'm Cc'ing you on this due to the last paragraph, as AFAIK you're
one of the initiators of the SPDX tagging initiative, and you even added
tags to 10k+ files all over the tree :-) so we maybe can discuss this
further, also with DD, in the hopes you're fine with this - sorry in
advance if not.

Ralph, Manfred, I'm Cc'ing you on these five patches aswell, so if there
are any concerns left regarding the changes proposed by these patches,
please raise them.

Daniel Scheller (5):
  [media] stv0910/stv6111: add SPDX license headers
  [media] dvb-frontends/mxl5xx: add SPDX license headers
  [media] dvb-frontends/cxd2099: add SPDX license headers
  [media] ddbridge: add SPDX license headers
  [media] ngene: add SPDX license headers

 drivers/media/dvb-frontends/cxd2099.c  |  5 +++--
 drivers/media/dvb-frontends/cxd2099.h  |  3 ++-
 drivers/media/dvb-frontends/mxl5xx.c   |  6 +++---
 drivers/media/dvb-frontends/mxl5xx.h   | 13 +
 drivers/media/dvb-frontends/mxl5xx_defs.h  |  1 +
 drivers/media/dvb-frontends/mxl5xx_regs.h  |  4 ++--
 drivers/media/dvb-frontends/stv0910.c  |  5 +++--
 drivers/media/dvb-frontends/stv0910.h  |  9 +
 drivers/media/dvb-frontends/stv6111.c  |  6 +++---
 drivers/media/dvb-frontends/stv6111.h  |  7 +++
 drivers/media/pci/ddbridge/Makefile|  2 +-
 drivers/media/pci/ddbridge/ddbridge-ci.c   |  6 ++
 drivers/media/pci/ddbridge/ddbridge-ci.h   |  6 ++
 drivers/media/pci/ddbridge/ddbridge-core.c |  8 ++--
 drivers/media/pci/ddbridge/ddbridge-hw.c   |  4 ++--
 drivers/media/pci/ddbridge/ddbridge-hw.h   |  4 ++--
 drivers/media/pci/ddbridge/ddbridge-i2c.c  |  4 ++--
 drivers/media/pci/ddbridge/ddbridge-i2c.h  |  4 ++--
 drivers/media/pci/ddbridge/ddbridge-io.h   |  4 ++--
 drivers/media/pci/ddbridge/ddbridge-main.c |  8 
 drivers/media/pci/ddbridge/ddbridge-max.c  |  4 ++--
 drivers/media/pci/ddbridge/ddbridge-max.h  |  4 ++--
 drivers/media/pci/ddbridge/ddbridge-regs.h |  7 ++-
 drivers/media/pci/ddbridge/ddbridge.h  |  7 ++-
 drivers/media/pci/ngene/Makefile   |  2 +-
 drivers/media/pci/ngene/ngene-cards.c  | 10 +++---
 drivers/media/pci/ngene/ngene-core.c   |  8 ++--
 drivers/media/pci/ngene/ngene-dvb.c|  8 ++--
 drivers/media/pci/ngene/ngene-i2c.c|  8 ++--
 drivers/media/pci/ngene/ngene.h|  7 ++-
 30 files changed, 87 insertions(+), 87 deletions(-)

-- 
2.16.1

[PATCH 3/5] [media] dvb-frontends/cxd2099: add SPDX license headers

2018-03-20 Thread Daniel Scheller

From: Daniel Scheller 

Add SPDX license headers in the cxd2099 driver files and fix MODULE_LICENSE
accordingly.

Cc: Jasmin Jessich 
Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/cxd2099.c | 5 +++--
 drivers/media/dvb-frontends/cxd2099.h | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2099.c 
b/drivers/media/dvb-frontends/cxd2099.c
index 4a0ce3037fd6..6b5f7fdde77b 100644
--- a/drivers/media/dvb-frontends/cxd2099.c
+++ b/drivers/media/dvb-frontends/cxd2099.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * cxd2099.c: Driver for the Sony CXD2099AR Common Interface Controller
  *
@@ -9,7 +10,7 @@
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
  */
 
@@ -701,4 +702,4 @@ module_i2c_driver(cxd2099_driver);
 
 MODULE_DESCRIPTION("Sony CXD2099AR Common Interface controller driver");
 MODULE_AUTHOR("Ralph Metzler");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/dvb-frontends/cxd2099.h 
b/drivers/media/dvb-frontends/cxd2099.h
index ec1910dec3f3..094bf4ffe2a8 100644
--- a/drivers/media/dvb-frontends/cxd2099.h
+++ b/drivers/media/dvb-frontends/cxd2099.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*
  * cxd2099.h: Driver for the Sony CXD2099AR Common Interface Controller
  *
@@ -9,7 +10,7 @@
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
  */
 
-- 
2.16.1

[PATCH 1/5] [media] stv0910/stv6111: add SPDX license headers

2018-03-20 Thread Daniel Scheller

From: Daniel Scheller 

Add SPDX license headers to the stv0910 and stv6111 DVB frontend
drivers. Both drivers are licensed as GPL-2.0-only, so fix this in the
MODULE_LICENSE while at it. Also, the includes were lacking any license
headers at all, so add them now.

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0910.c | 5 +++--
 drivers/media/dvb-frontends/stv0910.h | 9 +
 drivers/media/dvb-frontends/stv6111.c | 6 +++---
 drivers/media/dvb-frontends/stv6111.h | 7 +++
 4 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0910.c 
b/drivers/media/dvb-frontends/stv0910.c
index 52355c14fd64..ce82264e99ef 100644
--- a/drivers/media/dvb-frontends/stv0910.c
+++ b/drivers/media/dvb-frontends/stv0910.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * Driver for the ST STV0910 DVB-S/S2 demodulator.
  *
@@ -11,7 +12,7 @@
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
  */
 
@@ -1836,4 +1837,4 @@ EXPORT_SYMBOL_GPL(stv0910_attach);
 
 MODULE_DESCRIPTION("ST STV0910 multistandard frontend driver");
 MODULE_AUTHOR("Ralph and Marcus Metzler, Manfred Voelkel");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/dvb-frontends/stv0910.h 
b/drivers/media/dvb-frontends/stv0910.h
index fccd8d9b665f..93de08540ce4 100644
--- a/drivers/media/dvb-frontends/stv0910.h
+++ b/drivers/media/dvb-frontends/stv0910.h
@@ -1,3 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Driver for the ST STV0910 DVB-S/S2 demodulator.
+ *
+ * Copyright (C) 2014-2015 Ralph Metzler 
+ * Marcus Metzler 
+ * developed for Digital Devices GmbH
+ */
+
 #ifndef _STV0910_H_
 #define _STV0910_H_
 
diff --git a/drivers/media/dvb-frontends/stv6111.c 
b/drivers/media/dvb-frontends/stv6111.c
index 9b715b6fe152..47f4da2e577c 100644
--- a/drivers/media/dvb-frontends/stv6111.c
+++ b/drivers/media/dvb-frontends/stv6111.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * Driver for the ST STV6111 tuner
  *
@@ -9,9 +10,8 @@
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
- *
  */
 
 #include 
@@ -688,4 +688,4 @@ EXPORT_SYMBOL_GPL(stv6111_attach);
 
 MODULE_DESCRIPTION("ST STV6111 satellite tuner driver");
 MODULE_AUTHOR("Ralph Metzler, Manfred Voelkel");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/dvb-frontends/stv6111.h 
b/drivers/media/dvb-frontends/stv6111.h
index 5bc1228dc9bd..d2552040eddd 100644
--- a/drivers/media/dvb-frontends/stv6111.h
+++ b/drivers/media/dvb-frontends/stv6111.h
@@ -1,3 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Driver for the ST STV6111 tuner
+ *
+ * Copyright (C) 2014 Digital Devices GmbH
+ */
+
 #ifndef _STV6111_H_
 #define _STV6111_H_
 
-- 
2.16.1

[no subject]

2018-03-20 Thread Scott Tisdale

hi Linuxhttps://goo.gl/764kVN   Scott Tisdale

Re: uvcvideo: Unknown video format,00000032-0002-0010-8000-00aa00389b71

2018-03-20 Thread Laurent Pinchart

Hi Nicolas,

On Tuesday, 20 March 2018 19:45:51 EET Nicolas Dufresne wrote:
> Le mardi 20 mars 2018 à 13:20 +0100, Paul Menzel a écrit :
> > Dear Linux folks,
> > 
> > 
> > On the Dell XPS 13 9370, Linux 4.16-rc6 outputs the messages below.
> > 
> > ```
> > [2.338094] calling  uvc_init+0x0/0x1000 [uvcvideo] @ 295
> > [2.338569] calling  iTCO_wdt_init_module+0x0/0x1000 [iTCO_wdt] @ 280
> > [2.338570] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
> > [2.338713] iTCO_wdt: Found a Intel PCH TCO device (Version=4,
> > TCOBASE=0x0400)
> > [2.338755] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD
> > (0bda:58f4)
> > [2.338827] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
> > [2.338851] initcall iTCO_wdt_init_module+0x0/0x1000 [iTCO_wdt]
> > returned 0 after 271 usecs
> > [2.340669] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was
> > not initialized!
> > [2.340670] uvcvideo 1-5:1.0: Entity type for entity Extension 7 was
> > not initialized!
> > [2.340672] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was
> > not initialized!
> > [2.340673] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not
> > initialized!
> > [2.340736] input: Integrated_Webcam_HD: Integrate as
> > /devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input9
> > [2.341447] uvcvideo: Unknown video format
> > 0032-0002-0010-8000-00aa00389b71
> 
> While the 0002 is suspicious, this is pretty close to a color format.
> I've recently come across of similar format using D3DFORMAT instead of
> GUID. According to the vendor*, this camera module includes an infrared
> camera (340x340), so I suspect this is to specify the format it
> outputs. A good guess to start with would be that this is
> D3DFMT_X8L8V8U8 (0x32).

Isn't 0x32 D3DFMT_L8, not D3DFMT_X8L8V8U8 ?

> To test it, you could map this
> V4L2_PIX_FMT_YUV32/xRGB and see if the driver is happy with the buffer
> size.

VideoStreaming Interface Descriptor:
bLength30
bDescriptorType36
bDescriptorSubtype  5 (FRAME_UNCOMPRESSED)
bFrameIndex 1
bmCapabilities   0x00
  Still image unsupported
wWidth340
wHeight   340
dwMinBitRate 55488000
dwMaxBitRate 55488000
dwMaxVideoFrameBufferSize  115600
dwDefaultFrameInterval 16
bFrameIntervalType  1
dwFrameInterval( 0)16

340*340 is 115600, so this should be a 8-bit format.

> Then render it to make sure it looks some image of some sort. A
> new format will need to be defined as this format is in the wrong
> order, and is ambiguous (it may mean AYUV or xYUV). I'm not sure if we
> need specific formats to differentiate infrared data from YUV images,
> need to be discussed.

If the format is indeed D3DFMT_L8, it should map to V4L2_PIX_FMT_GREY (8-bit 
luminance). I suspect the camera transmits a depth map though.

> *https://dustinweb.azureedge.net/media/338953/xps-13-9370.pdf
> 
> > [2.341450] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD
> > (0bda:58f4)
> > [2.343371] uvcvideo: Unable to create debugfs 1-2 directory.
> > [2.343420] uvcvideo 1-5:1.2: Entity type for entity Extension 10 was
> > not initialized!
> > [2.343422] uvcvideo 1-5:1.2: Entity type for entity Extension 12 was
> > not initialized!
> > [2.343423] uvcvideo 1-5:1.2: Entity type for entity Processing 9 was
> > not initialized!
> > [2.343424] uvcvideo 1-5:1.2: Entity type for entity Camera 11 was
> > not initialized!
> > [2.343472] input: Integrated_Webcam_HD: Integrate as
> > /devices/pci:00/:00:14.0/usb1/1-5/1-5:1.2/input/input10
> > [2.343496] usbcore: registered new interface driver uvcvideo
> > [2.343496] USB Video Class driver (1.1.1)
> > [2.343501] initcall uvc_init+0x0/0x1000 [uvcvideo] returned 0 after
> > 5275 usecs
> > ```
> > 
> > Please tell me, what I can do to improve the situation.

-- 
Regards,

Laurent Pinchart

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

2018-03-20 Thread Christian König


Am 20.03.2018 um 15:08 schrieb Daniel Vetter:

[SNIP]
For the in-driver reservation path (CS) having a slow-path that grabs a
temporary reference, drops the vram lock and then locks the reservation
normally (using the acquire context used already for the entire CS) is a
bit tricky, but totally feasible. Ttm doesn't do that though.


That is exactly what we do in amdgpu as well, it's just not very 
efficient nor reliable to retry getting the right pages for a submission 
over and over again.



[SNIP]
Note that there are 2 paths for i915 userptr. One is the mmu notifier, the
other one is the root-only hack we have for dubious reasons (or that I
really don't see the point in myself).


Well I'm referring to i915_gem_userptr.c, if that isn't what you are 
exposing then just feel free to ignore this whole discussion.



For coherent usage you need to install some lock to prevent concurrent
get_user_pages(), command submission and
invalidate_range_start/invalidate_range_end from the MMU notifier.

Otherwise you can't guarantee that you are actually accessing the right page
in the case of a fork() or mprotect().

Yeah doing that with a full lock will create endless amounts of issues,
but I don't see why we need that. Userspace racing stuff with itself gets
to keep all the pieces. This is like racing DIRECT_IO against mprotect and
fork.


First of all I strongly disagree on that. A thread calling fork() 
because it wants to run a command is not something we can forbid just 
because we have a gfx stack loaded. That the video driver is not capable 
of handling that correct is certainly not the problem of userspace.


Second it's not only userspace racing here, you can get into this kind 
of issues just because of transparent huge page support where the 
background daemon tries to reallocate the page tables into bigger chunks.


And if I'm not completely mistaken you can also open up quite a bunch of 
security problems if you suddenly access the wrong page.



Leaking the IOMMU mappings otoh means rogue userspace could do a bunch of
stray writes (I don't see anywhere code in amdgpu_mn.c to unmap at least
the gpu side PTEs to make stuff inaccessible) and wreak the core kernel's
book-keeping.

In i915 we guarantee that we call set_page_dirty/mark_page_accessed only
after all the mappings are really gone (both GPU PTEs and sg mapping),
guaranteeing that any stray writes from either the GPU or IOMMU will
result in faults (except bugs in the IOMMU, but can't have it all, "IOMMU
actually works" is an assumption behind device isolation).
Well exactly that's the point, the handling in i915 looks incorrect to 
me. You need to call set_page_dirty/mark_page_accessed way before the 
mapping is destroyed.


To be more precise for userptrs it must be called from the 
invalidate_range_start, but i915 seems to delegate everything into a 
background worker to avoid the locking problems.



Felix and I hammered for quite some time on amdgpu until all of this was
handled correctly, see drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c.

Maybe we should have more shared code in this, it seems to be a source of
endless amounts of fun ...


I can try to gather the lockdep splat from my mail history, but it
essentially took us multiple years to get rid of all of them.

I'm very much interested in specifically the splat that makes it
impossible for you folks to remove the sg mappings. That one sounds bad.
And would essentially make mmu_notifiers useless for their primary use
case, which is handling virtual machines where you really have to make
sure the IOMMU mapping is gone before you claim it's gone, because there's
no 2nd level of device checks (like GPU PTEs, or command checker) catching
stray writes.


Well to be more precise the problem is not that we can't destroy the sg 
table, but rather that we can't grab the locks to do so.


See when you need to destroy the sg table you usually need to grab the 
same lock you grabbed when you created it.


And all locks taken while in an MMU notifier can only depend on memory 
allocation with GFP_NOIO, which is not really feasible for gfx drivers.


Regards,
Christian.

Re: uvcvideo: Unknown video format,00000032-0002-0010-8000-00aa00389b71

2018-03-20 Thread Nicolas Dufresne

Le mardi 20 mars 2018 à 13:20 +0100, Paul Menzel a écrit :
> Dear Linux folks,
> 
> 
> On the Dell XPS 13 9370, Linux 4.16-rc6 outputs the messages below.
> 
> ```
> [2.338094] calling  uvc_init+0x0/0x1000 [uvcvideo] @ 295
> [2.338569] calling  iTCO_wdt_init_module+0x0/0x1000 [iTCO_wdt] @ 280
> [2.338570] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
> [2.338713] iTCO_wdt: Found a Intel PCH TCO device (Version=4,
> TCOBASE=0x0400)
> [2.338755] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD 
> (0bda:58f4)
> [2.338827] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
> [2.338851] initcall iTCO_wdt_init_module+0x0/0x1000 [iTCO_wdt] 
> returned 0 after 271 usecs
> [2.340669] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was 
> not initialized!
> [2.340670] uvcvideo 1-5:1.0: Entity type for entity Extension 7 was 
> not initialized!
> [2.340672] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was 
> not initialized!
> [2.340673] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not
> initialized!
> [2.340736] input: Integrated_Webcam_HD: Integrate as
> /devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input9
> [2.341447] uvcvideo: Unknown video format
> 0032-0002-0010-8000-00aa00389b71

While the 0002 is suspicious, this is pretty close to a color format.
I've recently come across of similar format using D3DFORMAT instead of
GUID. According to the vendor*, this camera module includes an infrared
camera (340x340), so I suspect this is to specify the format it
outputs. A good guess to start with would be that this is
D3DFMT_X8L8V8U8 (0x32). To test it, you could map this
V4L2_PIX_FMT_YUV32/xRGB and see if the driver is happy with the buffer
size. Then render it to make sure it looks some image of some sort. A
new format will need to be defined as this format is in the wrong
order, and is ambiguous (it may mean AYUV or xYUV). I'm not sure if we
need specific formats to differentiate infrared data from YUV images,
need to be discussed.

*https://dustinweb.azureedge.net/media/338953/xps-13-9370.pdf

> [2.341450] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD 
> (0bda:58f4)
> [2.343371] uvcvideo: Unable to create debugfs 1-2 directory.
> [2.343420] uvcvideo 1-5:1.2: Entity type for entity Extension 10 was 
> not initialized!
> [2.343422] uvcvideo 1-5:1.2: Entity type for entity Extension 12 was 
> not initialized!
> [2.343423] uvcvideo 1-5:1.2: Entity type for entity Processing 9 was 
> not initialized!
> [2.343424] uvcvideo 1-5:1.2: Entity type for entity Camera 11 was 
> not initialized!
> [2.343472] input: Integrated_Webcam_HD: Integrate as
> /devices/pci:00/:00:14.0/usb1/1-5/1-5:1.2/input/input10
> [2.343496] usbcore: registered new interface driver uvcvideo
> [2.343496] USB Video Class driver (1.1.1)
> [2.343501] initcall uvc_init+0x0/0x1000 [uvcvideo] returned 0 after 
> 5275 usecs
> ```
> 
> Please tell me, what I can do to improve the situation.
> 
> 
> Kind regards,
> 
> Paul
> 

signature.asc
Description: This is a digitally signed message part

Re: uvcvideo: Unknown video format,00000032-0002-0010-8000-00aa00389b71

2018-03-20 Thread Paul Menzel


Dear Laurent,


On 03/20/18 14:30, Laurent Pinchart wrote:


On Tuesday, 20 March 2018 14:20:14 EET Paul Menzel wrote:



On the Dell XPS 13 9370, Linux 4.16-rc6 outputs the messages below.

```


[…]


[2.340736] input: Integrated_Webcam_HD: Integrate as
/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input9
[2.341447] uvcvideo: Unknown video format
0032-0002-0010-8000-00aa00389b71 >> [2.341450] uvcvideo: Found UVC 1.00 
device Integrated_Webcam_HD
(0bda:58f4)


[…]


```

Please tell me, what I can do to improve the situation.


Some vendors routinely implement new formats without bothering to send a patch
for the uvcvideo driver. It would be easy to do so, but it requires knowing
which format is meant by the GUID. Most format GUIDs are of the form
32595559--0010-8000-00aa00389b71 that starts with a 4CC, but that's not
the case here.


I am adding Mario to the receiver list, though he is currently on vacation.


Could you send me the output of

lsusb -v -d 0bda:58f4

running as root if possible ?


Sure, please find it attached.


Kind regards,

Paul

Bus 001 Device 002: ID 0bda:58f4 Realtek Semiconductor Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.10
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x0bda Realtek Semiconductor Corp.
  idProduct  0x58f4 
  bcdDevice   76.05
  iManufacturer   3 CN0FFMHCLOG0081JBA49A00
  iProduct1 Integrated_Webcam_HD
  iSerial 2 200901010001
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 1047
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  4 USB Camera
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
** UNRECOGNIZED:  28 ff 42 49 53 54 00 01 06 07 10 00 00 00 00 00 01 08 f4 
01 02 09 f4 01 03 0a f4 01 04 0b f4 01 05 0c f4 01 06 0d e8 03
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 0
  bInterfaceCount 2
  bFunctionClass 14 Video
  bFunctionSubClass   3 Video Interface Collection
  bFunctionProtocol   0 
  iFunction   5 Integrated Webcam
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass14 Video
  bInterfaceSubClass  1 Video Control
  bInterfaceProtocol  0 
  iInterface  5 Integrated Webcam
  VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdUVC   1.00
wTotalLength  107
dwClockFrequency   15.00MHz
bInCollection   1
baInterfaceNr( 0)   1
  VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype  2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType  0x0201 Camera Sensor
bAssocTerminal  0
iTerminal   0 
wObjectiveFocalLengthMin  0
wObjectiveFocalLengthMax  0
wOcularFocalLength0
bControlSize  3
bmControls   0x000e
  Auto-Exposure Mode
  Auto-Exposure Priority
  Exposure Time (Absolute)
  VideoControl Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype  5 (PROCESSING_UNIT)
  Warning: Descriptor too short
bUnitID 2
bSourceID   1
wMaxMultiplier  0
bControlSize2
bmControls 0x177f
  Brightness
  Contrast
  Hue
  Saturation
  Sharpness
  Gamma
  White Balance Temperature
  Backlight Compensation
  Gain
  Power Line Frequency
  White Balance Temperature, Auto
iProcessing 0 
bmVideoStandards 0x 9
  None
  SECAM - 625/50
  VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType  0x0101 USB Streaming
bAssocTerminal  0
bSourceID   4
iTerminal   0 
  VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubty

Re: [PATCH] media: uvcvideo: Fix minor spelling

2018-03-20 Thread Laurent Pinchart

Hi Kieran,

Thank you for the patch.

On Tuesday, 20 March 2018 17:43:08 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Provide the missing 't' from straightforward.
> 
> Signed-off-by: Kieran Bingham 

Acked-by: Laurent Pinchart 

and applied to my tree.

> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> b/drivers/media/usb/uvc/uvc_ctrl.c index 102594ec3e97..1daf444371be 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1125,7 +1125,7 @@ int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
> }
> 
>  /*
> - * Mapping V4L2 controls to UVC controls can be straighforward if done
> well. + * Mapping V4L2 controls to UVC controls can be straightforward if
> done well. * Most of the UVC controls exist in V4L2, and can be mapped
> directly. Some * must be grouped (for instance the Red Balance, Blue
> Balance and Do White * Balance V4L2 controls use the White Balance
> Component UVC control) or


-- 
Regards,

Laurent Pinchart

[PATCH] media: uvcvideo: Fix minor spelling

2018-03-20 Thread Kieran Bingham

From: Kieran Bingham 

Provide the missing 't' from straightforward.

Signed-off-by: Kieran Bingham 
---
 drivers/media/usb/uvc/uvc_ctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 102594ec3e97..1daf444371be 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -1125,7 +1125,7 @@ int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
 }
 
 /*
- * Mapping V4L2 controls to UVC controls can be straighforward if done well.
+ * Mapping V4L2 controls to UVC controls can be straightforward if done well.
  * Most of the UVC controls exist in V4L2, and can be mapped directly. Some
  * must be grouped (for instance the Red Balance, Blue Balance and Do White
  * Balance V4L2 controls use the White Balance Component UVC control) or
-- 
2.7.4

Issue with sharp protocol on ite-cir due to high idle timeout

2018-03-20 Thread Matthias Reichl

Hi Sean,

yesterday we received an interesting bug report that might
help to motivate using a lower idle timeout on ite-cir:

https://forum.libreelec.tv/thread/11951-sharp-ir-remote-on-intel-nuc-2820-double-presses/

The rather long message time of the sharp protocol (about 86ms)
in combination with the 200ms default idle timeout of ite-cir
leads to the last message being received after the current 250ms
"keyup" timeout. This results in an additional keyup/keydown
event being generated from the last message. Even a short button
press results in 2 keydown events.

I dont't have any ite-cir hardware here but could reproduce it
with gpio-ir-recv set to 200ms idle timeout. Lowering the
timeout to 100 or 125ms fixed the issue both here and on the
reporter's hardware.

so long,

Hias

Re: Double-free in /drivers/media/usb/hackrf driver

2018-03-20 Thread Dan Carpenter

Hi Linux Media Devs,

This is similar to the one before.  Please give reported-by credit to
Reported-by: "Yavuz, Tuba" 
Or maybe flip the names around?

The hackrf_probe() function has a double free on error after we set up:
dev->v4l2_dev.release = hackrf_video_release;
then the calls to:
video_unregister_device(&dev->rx_vdev);
and
kfree(dev);
are a double free.

regards,
dan carpenter

On Tue, Mar 20, 2018 at 01:48:17PM +, Yavuz, Tuba wrote:
> Hello,
> 
> 
> It looks like there is a double-free vulnerability on an error path in the 
> hackrf_probe function of the hackrf driver.
> 
> err_video_unregister_device_rx:
>video_unregister_device(&dev->rx_vdev);
>=>
>   v4l2_device_disconnect
>   =>
>   put_device
>   =>
>  kobject_put
>  =>
> kref_put
>  =>
> v4l2_device_release
> =>
> hackrf_video_release (CALLBACK)
> =>
> kfree(dev)
> ...
> err_kfree:
> kfree(dev);
> 
> The vulnerability has been introduced with commit 
> 8bc4a9ed85046c214458c9e82aea75d2f46cfffd, which added support for 
> transmitter.
> 
> 
> Best,
> 
> Tuba Yavuz, Ph.D.
> Assistant Professor
> Electrical and Computer Engineering Department
> University of Florida
> Gainesville, FL 32611
> Webpage: http://www.tuba.ece.ufl.edu/
> Email: t...@ece.ufl.edu
> Phone: (352) 846 0202

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

2018-03-20 Thread Daniel Vetter

On Tue, Mar 20, 2018 at 11:54:18AM +0100, Christian König wrote:
> Am 20.03.2018 um 08:44 schrieb Daniel Vetter:
> > On Mon, Mar 19, 2018 at 5:23 PM, Christian König
> >  wrote:
> > > Am 19.03.2018 um 16:53 schrieb Chris Wilson:
> > > > Quoting Christian König (2018-03-16 14:22:32)
> > > > [snip, probably lost too must context]
> > > > > This allows for full grown pipelining, e.g. the exporter can say I 
> > > > > need
> > > > > to move the buffer for some operation. Then let the move operation 
> > > > > wait
> > > > > for all existing fences in the reservation object and install the 
> > > > > fence
> > > > > of the move operation as exclusive fence.
> > > > Ok, the situation I have in mind is the non-pipelined case: revoking
> > > > dma-buf for mmu_invalidate_range or shrink_slab. I would need a
> > > > completion event that can be waited on the cpu for all the invalidate
> > > > callbacks. (Essentially an atomic_t counter plus struct completion; a
> > > > lighter version of dma_fence, I wonder where I've seen that before ;)
> > > 
> > > Actually that is harmless.
> > > 
> > > When you need to unmap a DMA-buf because of mmu_invalidate_range or
> > > shrink_slab you need to wait for it's reservation object anyway.
> > reservation_object only prevents adding new fences, you still have to
> > wait for all the current ones to signal. Also, we have dma-access
> > without fences in i915. "I hold the reservation_object" does not imply
> > you can just go and nuke the backing storage.
> 
> I was not talking about taking the lock, but rather using
> reservation_object_wait_timeout_rcu().
> 
> To be more precise you actually can't take the reservation object lock in an
> mmu_invalidate_range callback and you can only trylock it in a shrink_slab
> callback.

Ah ok, and yes agreed. Kinda. See below.

> > > This needs to be done to make sure that the backing memory is now idle, it
> > > doesn't matter if the jobs where submitted by DMA-buf importers or your 
> > > own
> > > driver.
> > > 
> > > The sg tables pointing to the now released memory might live a bit longer,
> > > but that is unproblematic and actually intended.
> > I think that's very problematic. One reason for an IOMMU is that you
> > have device access isolation, and a broken device can't access memory
> > it shouldn't be able to access. From that security-in-depth point of
> > view it's not cool that there's some sg tables hanging around still
> > that a broken GPU could use. And let's not pretend hw is perfect,
> > especially GPUs :-)
> 
> I completely agree on that, but there is unfortunately no other way.
> 
> See you simply can't take a reservation object lock in an mmu or slab
> callback, you can only trylock them.
> 
> For example it would require changing all allocations done while holding any
> reservation lock to GFP_NOIO.

Yeah mmu and slab can only trylock, and they need to skip to the next
object when the trylock fails. But once you have the lock you imo should
be able to clean up the entire mess still. We definitely do that for the
i915 shrinkers, and I don't see how going to importers through the
->invalidate_mapping callback changes anything with that.

For the in-driver reservation path (CS) having a slow-path that grabs a
temporary reference, drops the vram lock and then locks the reservation
normally (using the acquire context used already for the entire CS) is a
bit tricky, but totally feasible. Ttm doesn't do that though.

So there's completely feasible ways to make sure the sg list is all
properly released, all DMA gone and the IOMMU mappings torn down. Anything
else is just a bit shoddy device driver programming imo.

> > > When we would try to destroy the sg tables in an mmu_invalidate_range or
> > > shrink_slab callback we would run into a lockdep horror.
> > So I'm no expert on this, but I think this is exactly what we're doing
> > in i915. Kinda no other way to actually free the memory without
> > throwing all the nice isolation aspects of an IOMMU into the wind. Can
> > you please paste the lockdeps you've seen with amdgpu when trying to
> > do that?
> 
> Taking a quick look at i915 I can definitely say that this is actually quite
> buggy what you guys do here.

Note that there are 2 paths for i915 userptr. One is the mmu notifier, the
other one is the root-only hack we have for dubious reasons (or that I
really don't see the point in myself).

> For coherent usage you need to install some lock to prevent concurrent
> get_user_pages(), command submission and
> invalidate_range_start/invalidate_range_end from the MMU notifier.
> 
> Otherwise you can't guarantee that you are actually accessing the right page
> in the case of a fork() or mprotect().

Yeah doing that with a full lock will create endless amounts of issues,
but I don't see why we need that. Userspace racing stuff with itself gets
to keep all the pieces. This is like racing DIRECT_IO against mprotect and
fork.

Leaking the IOMMU mappings otoh means rogue userspace

Re: [PATCH v2] venus: vdec: fix format enumeration

2018-03-20 Thread Stanimir Varbanov

Hi Alex,

Thanks!

On 03/19/2018 11:32 AM, Alexandre Courbot wrote:
> find_format_by_index() stops enumerating formats as soon as the index
> matches, and returns NULL if venus_helper_check_codec() finds out that
> the format is not supported. This prevents formats to be properly
> enumerated if a non-supported format is present, as the enumeration will
> end with it.
> 
> Fix this by moving the call to venus_helper_check_codec() into the loop,
> and keep enumerating when it fails.
> 
> Fixes: 29f0133ec6 media: venus: use helper function to check supported codecs
> 
> Signed-off-by: Alexandre Courbot 
> ---
>  drivers/media/platform/qcom/venus/vdec.c | 13 +++--
>  drivers/media/platform/qcom/venus/venc.c | 13 +++--
>  2 files changed, 14 insertions(+), 12 deletions(-)

Acked-by: Stanimir Varbanov 

-- 
regards,
Stan

Re: uvcvideo: Unknown video format,00000032-0002-0010-8000-00aa00389b71

2018-03-20 Thread Laurent Pinchart

Hi Paul,

On Tuesday, 20 March 2018 14:20:14 EET Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> On the Dell XPS 13 9370, Linux 4.16-rc6 outputs the messages below.
> 
> ```
> [2.338094] calling  uvc_init+0x0/0x1000 [uvcvideo] @ 295
> [2.338569] calling  iTCO_wdt_init_module+0x0/0x1000 [iTCO_wdt] @ 280
> [2.338570] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
> [2.338713] iTCO_wdt: Found a Intel PCH TCO device (Version=4,
> TCOBASE=0x0400)
> [2.338755] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD
> (0bda:58f4)
> [2.338827] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
> [2.338851] initcall iTCO_wdt_init_module+0x0/0x1000 [iTCO_wdt]
> returned 0 after 271 usecs
> [2.340669] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was
> not initialized!
> [2.340670] uvcvideo 1-5:1.0: Entity type for entity Extension 7 was
> not initialized!
> [2.340672] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was
> not initialized!
> [2.340673] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not
> initialized!
> [2.340736] input: Integrated_Webcam_HD: Integrate as
> /devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input9
> [2.341447] uvcvideo: Unknown video format
> 0032-0002-0010-8000-00aa00389b71
> [2.341450] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD
> (0bda:58f4)
> [2.343371] uvcvideo: Unable to create debugfs 1-2 directory.
> [2.343420] uvcvideo 1-5:1.2: Entity type for entity Extension 10 was
> not initialized!
> [2.343422] uvcvideo 1-5:1.2: Entity type for entity Extension 12 was
> not initialized!
> [2.343423] uvcvideo 1-5:1.2: Entity type for entity Processing 9 was
> not initialized!
> [2.343424] uvcvideo 1-5:1.2: Entity type for entity Camera 11 was
> not initialized!
> [2.343472] input: Integrated_Webcam_HD: Integrate as
> /devices/pci:00/:00:14.0/usb1/1-5/1-5:1.2/input/input10
> [2.343496] usbcore: registered new interface driver uvcvideo
> [2.343496] USB Video Class driver (1.1.1)
> [2.343501] initcall uvc_init+0x0/0x1000 [uvcvideo] returned 0 after
> 5275 usecs
> ```
> 
> Please tell me, what I can do to improve the situation.

Some vendors routinely implement new formats without bothering to send a patch 
for the uvcvideo driver. It would be easy to do so, but it requires knowing 
which format is meant by the GUID. Most format GUIDs are of the form 
32595559--0010-8000-00aa00389b71 that starts with a 4CC, but that's not 
the case here.

Could you send me the output of

lsusb -v -d 0bda:58f4

running as root if possible ?

-- 
Regards,

Laurent Pinchart

[no subject]

2018-03-20 Thread Tom Crist




--
Hallo

  Mein Name ist Tom Crist Ich habe eine Spende von €2.100.000,00 für  
Sie. Ich habe die Amerika-Lotterie in Amerika im Wert von 40 Millionen  
Dollar gewonnen und ich gebe einen Teil davon an fünf glückliche Leute  
zum Gedenken an meine verstorbene Frau, die an Krebs gestorben ist.  
Kontaktieren Sie mich für weitere Details

  
  Tom Crist

uvcvideo: Unknown video format,00000032-0002-0010-8000-00aa00389b71

2018-03-20 Thread Paul Menzel


Dear Linux folks,


On the Dell XPS 13 9370, Linux 4.16-rc6 outputs the messages below.

```
[2.338094] calling  uvc_init+0x0/0x1000 [uvcvideo] @ 295
[2.338569] calling  iTCO_wdt_init_module+0x0/0x1000 [iTCO_wdt] @ 280
[2.338570] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[2.338713] iTCO_wdt: Found a Intel PCH TCO device (Version=4,
TCOBASE=0x0400)
[2.338755] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD 
(0bda:58f4)

[2.338827] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[2.338851] initcall iTCO_wdt_init_module+0x0/0x1000 [iTCO_wdt] 
returned 0 after 271 usecs
[2.340669] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was 
not initialized!
[2.340670] uvcvideo 1-5:1.0: Entity type for entity Extension 7 was 
not initialized!
[2.340672] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was 
not initialized!

[2.340673] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not
initialized!
[2.340736] input: Integrated_Webcam_HD: Integrate as
/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input9
[2.341447] uvcvideo: Unknown video format
0032-0002-0010-8000-00aa00389b71
[2.341450] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD 
(0bda:58f4)

[2.343371] uvcvideo: Unable to create debugfs 1-2 directory.
[2.343420] uvcvideo 1-5:1.2: Entity type for entity Extension 10 was 
not initialized!
[2.343422] uvcvideo 1-5:1.2: Entity type for entity Extension 12 was 
not initialized!
[2.343423] uvcvideo 1-5:1.2: Entity type for entity Processing 9 was 
not initialized!
[2.343424] uvcvideo 1-5:1.2: Entity type for entity Camera 11 was 
not initialized!

[2.343472] input: Integrated_Webcam_HD: Integrate as
/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.2/input/input10
[2.343496] usbcore: registered new interface driver uvcvideo
[2.343496] USB Video Class driver (1.1.1)
[2.343501] initcall uvc_init+0x0/0x1000 [uvcvideo] returned 0 after 
5275 usecs

```

Please tell me, what I can do to improve the situation.


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature

[GIT PULL] HEVC V4L2 controls and s5p-mfc update

2018-03-20 Thread Sylwester Nawrocki

Hi Mauro,

The following changes since commit 3f127ce11353fd1071cae9b65bc13add6aec6b90:

  media: em28xx-cards: fix em28xx_duplicate_dev() (2018-03-08 06:06:51 -0500)

are available in the git repository at:

  git://linuxtv.org/snawrocki/samsung.git tags/v4.17-media-samsung

for you to fetch changes up to 8e8ae9fe34ac0611494b0b540476c4b9b52eac5b:

  s5p-mfc: Amend initial min, max values of HEVC hierarchical coding QP 
controls (2018-03-19 17:44:24 +0100)


Support for MFC v10.10 in the s5p-mfc driver and addition
of related HEVC V4L2 controls.


Marek Szyprowski (1):
  media: s5p-mfc: Use real device for request_firmware() call

Smitha T Murthy (12):
  videodev2.h: Add v4l2 definition for HEVC
  v4l2-ioctl: add HEVC format description
  v4l2: Documentation of HEVC compressed format
  v4l2: Add v4l2 control IDs for HEVC encoder
  v4l2: Documentation for HEVC CIDs
  s5p-mfc: Rename IS_MFCV8 macro
  s5p-mfc: Adding initial support for MFC v10.10
  s5p-mfc: Use min scratch buffer size as provided by F/W
  s5p-mfc: Support MFCv10.10 buffer requirements
  s5p-mfc: Add support for HEVC decoder
  s5p-mfc: Add VP9 decoder support
  s5p-mfc: Add support for HEVC encoder

Sylwester Nawrocki (2):
  s5p-mfc: Ensure HEVC QP controls range is properly updated
  s5p-mfc: Amend initial min, max values of HEVC hierarchical coding QP 
controls

 Documentation/devicetree/bindings/media/s5p-mfc.txt |   1 +
 Documentation/media/uapi/v4l/extended-controls.rst  | 410 ++
 Documentation/media/uapi/v4l/pixfmt-compressed.rst  |   5 +
 drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |  87 +++
 drivers/media/platform/s5p-mfc/regs-mfc-v8.h|   2 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c|  28 +
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |   9 +
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  68 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |   8 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|  48 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 597 -
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|  14 +
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 397 --
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |  15 +
 drivers/media/v4l2-core/v4l2-ctrls.c| 119 
 drivers/media/v4l2-core/v4l2-ioctl.c|   1 +
 include/uapi/linux/v4l2-controls.h  |  93 +++-
 include/uapi/linux/videodev2.h  |   1 +
 18 files changed, 1824 insertions(+), 79 deletions(-)
 create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h


-- 
Regards,
Sylwester

Re: RESEND[PATCH v6 2/2] media: dw9807: Add dw9807 vcm driver

2018-03-20 Thread Sakari Ailus

Hi Jacopo,

On Tue, Mar 20, 2018 at 11:28:17AM +0100, jacopo mondi wrote:
...
> > +static int dw9807_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> > +{
> > +   int rval;
> > +
> > +   rval = pm_runtime_get_sync(sd->dev);
> > +   if (rval < 0) {
> > +   pm_runtime_put_noidle(sd->dev);
> 
> If you fail to get pm context, no need to put it back (I presume)

pm_runtime_get() must be followed by pm_runtime_put() whether the former
succeeds or not.

...

> > +static const struct of_device_id dw9807_of_table[] = {
> > +   { .compatible = "dongwoon,dw9807" },
> > +   { { 0 } }
> 
> { } is enough.

{ } is GCC specific while { { 0 } } isn't.

-- 
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com

[RFT] media: hdpvr: Fix Double kfree() error

2018-03-20 Thread Arvind Yadav

Here, double-free is happening on error path of hdpvr_probe.

error_v4l2_unregister:
  v4l2_device_unregister(&dev->v4l2_dev);
   =>
v4l2_device_disconnect
=>
 put_device
 =>
  kobject_put
  =>
   kref_put
   =>
v4l2_device_release
=>
 hdpvr_device_release (CALLBACK)
 =>
 kfree(dev)

error_free_dev:
   kfree(dev)

Signed-off-by: Arvind Yadav 
---
reported by:
   Dan Carpenter

 drivers/media/usb/hdpvr/hdpvr-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/usb/hdpvr/hdpvr-core.c 
b/drivers/media/usb/hdpvr/hdpvr-core.c
index 29ac7fc..cab100a0 100644
--- a/drivers/media/usb/hdpvr/hdpvr-core.c
+++ b/drivers/media/usb/hdpvr/hdpvr-core.c
@@ -395,6 +395,7 @@ static int hdpvr_probe(struct usb_interface *interface,
kfree(dev->usbc_buf);
 error_v4l2_unregister:
v4l2_device_unregister(&dev->v4l2_dev);
+   dev = NULL;
 error_free_dev:
kfree(dev);
 error:
-- 
1.9.1

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

2018-03-20 Thread Christian König


Am 20.03.2018 um 08:44 schrieb Daniel Vetter:

On Mon, Mar 19, 2018 at 5:23 PM, Christian König
 wrote:

Am 19.03.2018 um 16:53 schrieb Chris Wilson:

Quoting Christian König (2018-03-16 14:22:32)
[snip, probably lost too must context]

This allows for full grown pipelining, e.g. the exporter can say I need
to move the buffer for some operation. Then let the move operation wait
for all existing fences in the reservation object and install the fence
of the move operation as exclusive fence.

Ok, the situation I have in mind is the non-pipelined case: revoking
dma-buf for mmu_invalidate_range or shrink_slab. I would need a
completion event that can be waited on the cpu for all the invalidate
callbacks. (Essentially an atomic_t counter plus struct completion; a
lighter version of dma_fence, I wonder where I've seen that before ;)


Actually that is harmless.

When you need to unmap a DMA-buf because of mmu_invalidate_range or
shrink_slab you need to wait for it's reservation object anyway.

reservation_object only prevents adding new fences, you still have to
wait for all the current ones to signal. Also, we have dma-access
without fences in i915. "I hold the reservation_object" does not imply
you can just go and nuke the backing storage.


I was not talking about taking the lock, but rather using 
reservation_object_wait_timeout_rcu().


To be more precise you actually can't take the reservation object lock 
in an mmu_invalidate_range callback and you can only trylock it in a 
shrink_slab callback.



This needs to be done to make sure that the backing memory is now idle, it
doesn't matter if the jobs where submitted by DMA-buf importers or your own
driver.

The sg tables pointing to the now released memory might live a bit longer,
but that is unproblematic and actually intended.

I think that's very problematic. One reason for an IOMMU is that you
have device access isolation, and a broken device can't access memory
it shouldn't be able to access. From that security-in-depth point of
view it's not cool that there's some sg tables hanging around still
that a broken GPU could use. And let's not pretend hw is perfect,
especially GPUs :-)


I completely agree on that, but there is unfortunately no other way.

See you simply can't take a reservation object lock in an mmu or slab 
callback, you can only trylock them.


For example it would require changing all allocations done while holding 
any reservation lock to GFP_NOIO.



When we would try to destroy the sg tables in an mmu_invalidate_range or
shrink_slab callback we would run into a lockdep horror.

So I'm no expert on this, but I think this is exactly what we're doing
in i915. Kinda no other way to actually free the memory without
throwing all the nice isolation aspects of an IOMMU into the wind. Can
you please paste the lockdeps you've seen with amdgpu when trying to
do that?


Taking a quick look at i915 I can definitely say that this is actually 
quite buggy what you guys do here.


For coherent usage you need to install some lock to prevent concurrent 
get_user_pages(), command submission and 
invalidate_range_start/invalidate_range_end from the MMU notifier.


Otherwise you can't guarantee that you are actually accessing the right 
page in the case of a fork() or mprotect().


Felix and I hammered for quite some time on amdgpu until all of this was 
handled correctly, see drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c.


I can try to gather the lockdep splat from my mail history, but it 
essentially took us multiple years to get rid of all of them.


Regards,
Christian.


-Daniel


Regards,
Christian.


Even so, it basically means passing a fence object down to the async
callbacks for them to signal when they are complete. Just to handle the
non-pipelined version. :|
-Chris
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
Linaro-mm-sig mailing list
linaro-mm-...@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-mm-sig

Re: RESEND[PATCH v6 2/2] media: dw9807: Add dw9807 vcm driver

2018-03-20 Thread jacopo mondi

Hi Andy,
   a few comments on you patch below...

On Sat, Mar 17, 2018 at 01:05:26AM +0800, Andy Yeh wrote:
> From: Alan Chiang 
>
> DW9807 is a 10 bit DAC from Dongwoon, designed for linear
> control of voice coil motor.
>
> This driver creates a V4L2 subdevice and
> provides control to set the desired focus.
>
> Signed-off-by: Andy Yeh 
> ---
> since v1:
> - changed author.
> since v2:
> - addressed outstanding comments.
> - enabled sequential write to update 2 registers in a single transaction.
> since v3:
> - addressed comments for v3.
> - Remove redundant codes and declare some variables as constant variable.
> - separate DT binding to another patch
> sicne v4:
> - sent patchset included DT binding with cover page
>
>  MAINTAINERS|   7 +
>  drivers/media/i2c/Kconfig  |  10 ++
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/dw9807.c | 320 
> +
>  4 files changed, 338 insertions(+)
>  create mode 100644 drivers/media/i2c/dw9807.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 845fc25..a339bb5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4385,6 +4385,13 @@ T: git git://linuxtv.org/media_tree.git
>  S:   Maintained
>  F:   drivers/media/i2c/dw9714.c
>
> +DONGWOON DW9807 LENS VOICE COIL DRIVER
> +M:   Sakari Ailus 
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/i2c/dw9807.c
> +
>  DOUBLETALK DRIVER
>  M:   "James R. Van Zandt" 
>  L:   blinux-l...@redhat.com
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index cb5d7ff..fd01842 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -325,6 +325,16 @@ config VIDEO_DW9714
> capability. This is designed for linear control of
> voice coil motors, controlled via I2C serial interface.
>
> +config VIDEO_DW9807
> + tristate "DW9807 lens voice coil support"
> + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   This is a driver for the DW9807 camera lens voice coil.
> +   DW9807 is a 10 bit DAC with 100mA output current sink
> +   capability. This is designed for linear control of
> +   voice coil motors, controlled via I2C serial interface.
> +
>  config VIDEO_SAA7110
>   tristate "Philips SAA7110 video decoder"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 548a9ef..1b62639 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
>  obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
>  obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
>  obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
> +obj-$(CONFIG_VIDEO_DW9807)  += dw9807.o
>  obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
>  obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
>  obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
> diff --git a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c
> new file mode 100644
> index 000..95626e9
> --- /dev/null
> +++ b/drivers/media/i2c/dw9807.c
> @@ -0,0 +1,320 @@
> +// Copyright (C) 2018 Intel Corporation
> +// SPDX-License-Identifier: GPL-2.0
> +

Nit: my understanding is that the SPDX identifier goes first

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DW9807_NAME  "dw9807"
> +#define DW9807_MAX_FOCUS_POS 1023
> +/*
> + * This sets the minimum granularity for the focus positions.
> + * A value of 1 gives maximum accuracy for a desired focus position

Please end comments with a full stop, here and in the rest of the
driver.

> + */
> +#define DW9807_FOCUS_STEPS   1
> +/*
> + * This acts as the minimum granularity of lens movement.
> + * Keep this value power of 2, so the control steps can be
> + * uniformly adjusted for gradual lens movement, with desired
> + * number of control steps.
> + */
> +#define DW9807_CTRL_STEPS16
> +#define DW9807_CTRL_DELAY_US 1000
> +
> +#define DW9807_CTL_ADDR  0x02
> +/*
> + * DW9807 separates two registers to control the VCM position.
> + * One for MSB value, another is LSB value.
> + */
> +#define DW9807_MSB_ADDR  0x03
> +#define DW9807_LSB_ADDR  0x04
> +#define DW9807_STATUS_ADDR   0x05
> +#define DW9807_MODE_ADDR 0x06
> +#define DW9807_RESONANCE_ADDR0x07
> +
> +#define MAX_RETRY10
> +
> +struct dw9807_device {
> + struct v4l2_ctrl_handler ctrls_vcm;
> + struct v4l2_subdev sd;
> + u16 current_val;
> +};
> +
> +static inline struct dw9807_device *sd_to_dw9807_vcm(struct v4l2_subdev 
> *subdev)
> +{
> + return container_of(subdev, struct dw9807_device, sd);
> +}
> +
> +static int dw9807_i2c_check(struct i2c_client *client)
> +{
> + const char status_addr = DW9807_STATUS_ADDR;
> + char status_result = 0x1;

Do you need to intialize this?

> + int ret;
> +
> +

Re: [RFC, libv4l]: Make libv4l2 usable on devices with complex pipeline

2018-03-20 Thread Pavel Machek

Hi!

> > > 2) support for running libv4l2 on mc-based devices. I'd like to do
> > > that.
> > > 
> > > Description file would look like. (# comments would not be not part of 
> > > file).
> > > 
> > > V4L2MEDIADESC
> > > 3 # number of files to open
> > > /dev/video2
> > > /dev/video6
> > > /dev/video3  
> 
> "Easy" file formats usually means maintenance troubles as new
> things are needed, and makes worse for users to write it. 
> You should take a look at lib/libdvbv5/dvb-file.c, mainly at 
> fill_entry() and dvb_read_file().

Well, file formats just need to be maintained.

> > Instead these should be entity names from the media controller.
> 
> Agreed that it should use MC. Yet, IMHO, the best would be to use
> the entity function instead, as entity names might eventually
> change on newer versions of the Kernel.

Kernel interfaces are not supposed to be changing.

> (again, user may specify just name, just function or both)
> 
> > > 3 # number of controls to map. Controls not mentioned here go to
> > >   # device 0 automatically. Sorted by control id.
> > >   # Device 0 
> > > 00980913 1
> > > 009a0003 1
> > > 009a000a 2  
> 
> I would, instead, encode it as:
> 
>   [control white balance]
>   control_id = 0x00980913
>   entity = foo_entity_name

Ok, that's really overly complex. If futrue extensibility is concern
we can do

0x00980913=whatever.

> Allowing both hexadecimal values and control macro names (can easily parsed 
> from the header file, as we already do for other things with "make
> sync").

"Easily" as in "more complex then rest of proposed code combined" :-(.

> It should probably be easy to add a generic pipeline descriptor
> with a format like:
> 
>   [pipeline pipe1]
>   link0 = SGRBG10 640x480: entity1:0 -> entity2:0[1]
>   link1 = SGRBG10 640x480: entity2:2-> entity3:0[1]
>   link2 = UYVY 640x480: entity3:1-> entity4:0[1]
>   link3 = UYVY 640x480: entity4:1-> entity5:0[1]
> 
>   sink0 = UYVY 320x200: entity5:0[1]
>   sink1 = UYVY 640x480: entity3:0[1]

Well, first, this looks like very unsuitable for key=value file. Plus,
it will not be easy to parse.  and control map needs to be
per-pipeline-configuration. Again, proposed Windows-style format can
not easily do that.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

2018-03-20 Thread Daniel Vetter

On Mon, Mar 19, 2018 at 5:23 PM, Christian König
 wrote:
> Am 19.03.2018 um 16:53 schrieb Chris Wilson:
>>
>> Quoting Christian König (2018-03-16 14:22:32)
>> [snip, probably lost too must context]
>>>
>>> This allows for full grown pipelining, e.g. the exporter can say I need
>>> to move the buffer for some operation. Then let the move operation wait
>>> for all existing fences in the reservation object and install the fence
>>> of the move operation as exclusive fence.
>>
>> Ok, the situation I have in mind is the non-pipelined case: revoking
>> dma-buf for mmu_invalidate_range or shrink_slab. I would need a
>> completion event that can be waited on the cpu for all the invalidate
>> callbacks. (Essentially an atomic_t counter plus struct completion; a
>> lighter version of dma_fence, I wonder where I've seen that before ;)
>
>
> Actually that is harmless.
>
> When you need to unmap a DMA-buf because of mmu_invalidate_range or
> shrink_slab you need to wait for it's reservation object anyway.

reservation_object only prevents adding new fences, you still have to
wait for all the current ones to signal. Also, we have dma-access
without fences in i915. "I hold the reservation_object" does not imply
you can just go and nuke the backing storage.

> This needs to be done to make sure that the backing memory is now idle, it
> doesn't matter if the jobs where submitted by DMA-buf importers or your own
> driver.
>
> The sg tables pointing to the now released memory might live a bit longer,
> but that is unproblematic and actually intended.

I think that's very problematic. One reason for an IOMMU is that you
have device access isolation, and a broken device can't access memory
it shouldn't be able to access. From that security-in-depth point of
view it's not cool that there's some sg tables hanging around still
that a broken GPU could use. And let's not pretend hw is perfect,
especially GPUs :-)

> When we would try to destroy the sg tables in an mmu_invalidate_range or
> shrink_slab callback we would run into a lockdep horror.

So I'm no expert on this, but I think this is exactly what we're doing
in i915. Kinda no other way to actually free the memory without
throwing all the nice isolation aspects of an IOMMU into the wind. Can
you please paste the lockdeps you've seen with amdgpu when trying to
do that?
-Daniel

>
> Regards,
> Christian.
>
>>
>> Even so, it basically means passing a fence object down to the async
>> callbacks for them to signal when they are complete. Just to handle the
>> non-pipelined version. :|
>> -Chris
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH v2 1/3] staging: xm2mvscale: Driver support for Xilinx M2M Video Scaler

2018-03-20 Thread Hans Verkuil

On 03/20/2018 02:41 AM, Nicolas Dufresne wrote:
> Le mardi 20 mars 2018 à 00:46 +, Rohit Athavale a écrit :
>> Hi Hans,
>>
>> Thanks for taking the time to take a look at this.
>>
>>> This should definitely use the V4L2 API. I guess it could be added
>>> to staging/media with a big fat TODO that this should be converted
>>> to
>>> the V4L2 mem2mem framework.
>>>
>>> But it makes no sense to re-invent the V4L2 streaming API :-)
>>>
>>> drivers/media/platform/mx2_emmaprp.c does something similar to
>>> this.
>>> It's a little bit outdated (not using the latest m2m helper
>>> functions)
>>> but it is a good starting point.
>>
>> I looked at the mx2_emmaprp.c and the Samsung G-Scaler M2M driver.
>> IMHO, the main difference between
>> the Hardware registers/capabilities is that mx2_emmaprp driver or the
>> gsc driver, have one scaling "channel"
>> if we might call it. Whereas the HW/IP I have in mind has 4-8 scaling
>> channels.
>>
>> By a scaling channel, I mean an entity of the HW or IP, that can take
>> the following parameters :
>>  - Input height, stride , width, color format, input Y and Cb/Cr
>> physically contiguous memory pointers 
>>  - Output height, stride, width, color format, output Y and Cb/Cr
>> physically contiguous  memory pointers
>>
>> Based on the above parameters, when the above are provided and the IP
>> is started, we get an interrupt on completion.
>> I'm sure you are familiar with this model. However, in the case of
>> this IP, there could be 4-8 such channels and a single interrupt
>> on the completion of the all 4-8 scaling operations.
>>
>> In this IP, we are trying to have 4-8 input sources being scaled by
>> this single piece of hardware, by time multiplexing.
>>
>> An example use case is :
>>
>> Four applications (sources) will feed (enqueue) 4 input buffers to
>> the scaler, the scaler driver will synchronize the programming of
>> these buffers, when the number of buffers received  by the driver
>> meets our batch size (say a batch size of 4), it will kick start the
>> IP. The four applications  will poll on the fd, upon receiving an
>> interrupt from the hardware the poll will unblock. And all four
>> applications can dequeue their respective buffers and display them on
>> a sink.
> 
> You should think of a better scheduling model, it will be really hard
> to design userspace that collaborate in order to optimize the IP usage.
> I think a better approach would be to queue while the IP is busy. These
> queues can then be sorted and prioritized.
> 
>>
>> But each "channel" can be set to do accept its own individual input
>> and output formats. When I went through :
>> https://www.kernel.org/doc/html/v4.14/media/uapi/v4l/open.html#multip
>> le-opens
>>
>> It appears, once an application has invoked VIDIOC_REQBUFS or
>> VIDIOC_CREATE_BUFS, other applications cannot VIDIOC_S_FMT on them.
>> However to maximize the available number of channels, it would be
>> necessary to allow several applications to be able to 
>> perform VIDIOC_S_FMT on the device node in the case of this hardware
>> as different channels can be expected to deal with different scaling
>> operations.
> 
> This does not apply to M2M devices. Each time userspace open an M2M
> device, it will get a different instance (unless there is no more
> resource available). What drivers like Samsung FIMC, GSCALER, MFC. etc.
> do, is that they limit the number of instances (open calls) to the
> number of streams they can handle in parallel. They don't seem to share
> an IRQ when doing batch though.
> 
>>
>> One option is to create a logical /dev/videoX node for each such
>> channel, and have a parent driver perform the interrupt handling,
>> batch size setting and other such common functionalities. Is there a
>> way to allow multiple applications talk to the same video device
>> node/file handle without creating logical video nodes for each
>> channel ?
> 
> FIMC used to expose a node per instance and it was terribly hard to
> use. I don't think this is a good idea.

See Nicolas' answers. The mem2mem framework should work well for you,
I think. The job_ready callback can be used to signal when enough
buffers are queued to satisfy your IP requirements.

BTW, those requirements sound really weird. Is this really how Xilinx
wants to implement this? It's not how scalers are used 'in the real world'.
This whole 'batching' thing is strange.

Regards,

Hans

> 
>>
>> Please let me know if the description of HW is not clear. I will look
>> forward to hear comments from you.
>>
>>>
>>> So for this series:
>>>
>>> Nacked-by: Hans Verkuil 
>>>
>>> If this was added to drivers/staging/media instead and with an
>>> updated
>>> TODO, then we can accept it, but we need to see some real effort
>>> afterwards
>>> to switch this to the right API. Otherwise it will be removed again
>>> after a few kernel cycles.
>>>
>>
>> Many thanks for providing a pathway to get this into
>> drivers/staging/media
>>
>> I will drop this series, and r

48 matches

Mail list logo