Re: [PATCH] staging: most: protect potential string overflow

2019-04-25 Thread Bo YU
On Wed, Apr 24, 2019 at 10:55 PM Dan Carpenter  wrote:
>
> On Mon, Apr 22, 2019 at 10:20:18PM -0400, Bo YU wrote:
> > There maybe cause potential string overflow issue due to use
> > strcpy without checking the length
> >
> > Detected By CoversityScan CID# 1444760
> >
> > Fixes: 131ac62253dba:(staging: most: core: use device description as name)
>
> It doesn't really fix anything, it just silences a static checker
> warning.
>
> > Signed-off-by: Bo YU 
> > ---
> >  drivers/staging/most/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/most/core.c b/drivers/staging/most/core.c
> > index 956daf8c3bd2..0f26cebac91a 100644
> > --- a/drivers/staging/most/core.c
> > +++ b/drivers/staging/most/core.c
> > @@ -1431,7 +1431,7 @@ int most_register_interface(struct most_interface 
> > *iface)
> >
> >   INIT_LIST_HEAD(&iface->p->channel_list);
> >   iface->p->dev_id = id;
> > - strcpy(iface->p->name, iface->description);
> > + strlcpy(iface->p->name, iface->description, sizeof(iface->p->name));
>
> We prefer strscpy() more than strlcpy() these days.

 Ok,will try it.
 Thanks,

>
> regards,
> dan carpenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Your Notice

2019-04-25 Thread Mrs Huda Alghoson
Great Opportunity awaits you, reply to my private email below for details. Mrs 
Huda Alghoson (Saudi Aramco)
huda.algho...@gmail.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 6/6] media: staging/imx: Re-organize modules

2019-04-25 Thread Steve Longerbeam
Re-organize modules, and which objects are linked into those modules, so
that:

- imx6-media (renamed from imx-media) is the media driver module for
  imx5/6 only, and has no symbol exports. The IPU internal subdevice
  objects now link directly with imx6-media.

- imx6-media-csi (renamed from imx-media-csi) is the subdev driver
  module for imx5/6 CSI. It is now linked direcly with imx-media-fim,
  since only the imx5/6 CSI makes use of the frame interval monitor.

- imx-media-common now only contains common code between imx5/6 and imx7
  media drivers. It contains imx-media-utils, imx-media-of,
  imx-media-dev-common, and imx-media-capture. In order to acheive that,
  some functions common to imx5/6 and imx7 have been moved out of
  imx-media-dev.c and into imx-media-dev-common.c.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/Makefile|  18 +-
 .../staging/media/imx/imx-media-dev-common.c  | 345 +-
 drivers/staging/media/imx/imx-media-dev.c | 340 +
 drivers/staging/media/imx/imx-media-fim.c |   5 -
 drivers/staging/media/imx/imx-media-of.c  |   3 +
 drivers/staging/media/imx/imx-media.h |  16 +-
 drivers/staging/media/imx/imx7-media-csi.c|   4 +-
 7 files changed, 370 insertions(+), 361 deletions(-)

diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index d2d909a36239..aa6c4b4ad37e 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -1,16 +1,16 @@
 # SPDX-License-Identifier: GPL-2.0
-imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o
-imx-media-objs += imx-media-dev-common.o
-imx-media-common-objs := imx-media-utils.o imx-media-fim.o
-imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o
+imx6-media-objs := imx-media-dev.o imx-media-internal-sd.o \
+   imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o imx-media-vdic.o
 
-obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
+imx-media-common-objs := imx-media-capture.o imx-media-dev-common.o \
+   imx-media-of.o imx-media-utils.o
+
+imx6-media-csi-objs := imx-media-csi.o imx-media-fim.o
+
+obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx6-media.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
-obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-capture.o
-obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-vdic.o
-obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-ic.o
 
-obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
+obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-media-csi.o
 obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o
 
 obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o
diff --git a/drivers/staging/media/imx/imx-media-dev-common.c 
b/drivers/staging/media/imx/imx-media-dev-common.c
index 6cd93419b81d..89dc4ec8dadb 100644
--- a/drivers/staging/media/imx/imx-media-dev-common.c
+++ b/drivers/staging/media/imx/imx-media-dev-common.c
@@ -8,9 +8,342 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include "imx-media.h"
 
-static const struct v4l2_async_notifier_operations imx_media_subdev_ops = {
+static inline struct imx_media_dev *notifier2dev(struct v4l2_async_notifier *n)
+{
+   return container_of(n, struct imx_media_dev, notifier);
+}
+
+/* async subdev bound notifier */
+static int imx_media_subdev_bound(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *sd,
+ struct v4l2_async_subdev *asd)
+{
+   v4l2_info(sd->v4l2_dev, "subdev %s bound\n", sd->name);
+
+   return 0;
+}
+
+/*
+ * 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)
+{
+   struct imx_media_dev *imxmd = notifier2dev(notifier);
+   struct v4l2_subdev *sd;
+
+   list_for_each_entry(sd, &imxmd->v4l2_dev.subdevs, list) {
+   switch (sd->grp_id) {
+   case IMX_MEDIA_GRP_ID_IPU_VDIC:
+   case IMX_MEDIA_GRP_ID_IPU_IC_PRP:
+   case IMX_MEDIA_GRP_ID_IPU_IC_PRPENC:
+   case IMX_MEDIA_GRP_ID_IPU_IC_PRPVF:
+   /*
+* links have already been created for the
+* sync-registered subdevs.
+*/
+   break;
+   case IMX_MEDIA_GRP_ID_IPU_CSI0:
+   case IMX_MEDIA_GRP_ID_IPU_CSI1:
+   case IMX_MEDIA_GRP_ID_CSI:
+   imx_media_create_csi_of_links(imxmd, sd);
+   break;
+   default:
+   /*
+* if this subdev has fwnode links, create media
+* links for them.
+*/
+   imx_media_create_of_links(imxmd, sd);
+   break;
+   }
+   }
+
+   return 0;
+}
+
+/*
+ * adds given video device to given imx-media source pad vdev li

[PATCH 5/6] media: staging/imx: Remove capture_device_set_format

2019-04-25 Thread Steve Longerbeam
Don't propagate the source pad format to the connected capture device.
It's now the responsibility of userspace to call VIDIOC_S_FMT on the
capture device to ensure the capture format and compose rectangle
are compatible with the connected source. To check this, validate
the capture format with the source before streaming starts.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-ic-prpencvf.c   | 16 +
 drivers/staging/media/imx/imx-media-capture.c | 64 +--
 drivers/staging/media/imx/imx-media-csi.c | 16 +
 drivers/staging/media/imx/imx-media.h |  2 -
 drivers/staging/media/imx/imx7-media-csi.c| 18 +-
 5 files changed, 50 insertions(+), 66 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index afaa3a8b15e9..63334fd61492 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -906,9 +906,7 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
   struct v4l2_subdev_format *sdformat)
 {
struct prp_priv *priv = sd_to_priv(sd);
-   struct imx_media_video_dev *vdev = priv->vdev;
const struct imx_media_pixfmt *cc;
-   struct v4l2_pix_format vdev_fmt;
struct v4l2_mbus_framefmt *fmt;
int ret = 0;
 
@@ -945,19 +943,9 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
priv->cc[PRPENCVF_SRC_PAD] = outcc;
}
 
-   if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY)
-   goto out;
-
-   priv->cc[sdformat->pad] = cc;
+   if (sdformat->which == V4L2_SUBDEV_FORMAT_ACTIVE)
+   priv->cc[sdformat->pad] = cc;
 
-   /* propagate output pad format to capture device */
-   imx_media_mbus_fmt_to_pix_fmt(&vdev_fmt,
- &priv->format_mbus[PRPENCVF_SRC_PAD],
- priv->cc[PRPENCVF_SRC_PAD]);
-   mutex_unlock(&priv->lock);
-   imx_media_capture_device_set_format(vdev, &vdev_fmt);
-
-   return 0;
 out:
mutex_unlock(&priv->lock);
return ret;
diff --git a/drivers/staging/media/imx/imx-media-capture.c 
b/drivers/staging/media/imx/imx-media-capture.c
index 555f6204660b..b77a67bda47c 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -205,7 +205,8 @@ static int capture_g_fmt_vid_cap(struct file *file, void 
*fh,
 
 static int __capture_try_fmt_vid_cap(struct capture_priv *priv,
 struct v4l2_subdev_format *fmt_src,
-struct v4l2_format *f)
+struct v4l2_format *f,
+struct v4l2_rect *compose)
 {
const struct imx_media_pixfmt *cc, *cc_src;
 
@@ -247,6 +248,13 @@ static int __capture_try_fmt_vid_cap(struct capture_priv 
*priv,
 
imx_media_mbus_fmt_to_pix_fmt(&f->fmt.pix, &fmt_src->format, cc);
 
+   if (compose) {
+   compose->left = 0;
+   compose->top = 0;
+   compose->width = fmt_src->format.width;
+   compose->height = fmt_src->format.height;
+   }
+
return 0;
 }
 
@@ -263,7 +271,7 @@ static int capture_try_fmt_vid_cap(struct file *file, void 
*fh,
if (ret)
return ret;
 
-   return __capture_try_fmt_vid_cap(priv, &fmt_src, f);
+   return __capture_try_fmt_vid_cap(priv, &fmt_src, f, NULL);
 }
 
 static int capture_s_fmt_vid_cap(struct file *file, void *fh,
@@ -271,6 +279,7 @@ static int capture_s_fmt_vid_cap(struct file *file, void 
*fh,
 {
struct capture_priv *priv = video_drvdata(file);
struct v4l2_subdev_format fmt_src;
+   struct v4l2_rect compose;
int ret;
 
if (vb2_is_busy(&priv->q)) {
@@ -284,17 +293,14 @@ static int capture_s_fmt_vid_cap(struct file *file, void 
*fh,
if (ret)
return ret;
 
-   ret = __capture_try_fmt_vid_cap(priv, &fmt_src, f);
+   ret = __capture_try_fmt_vid_cap(priv, &fmt_src, f, &compose);
if (ret)
return ret;
 
priv->vdev.fmt.fmt.pix = f->fmt.pix;
priv->vdev.cc = imx_media_find_format(f->fmt.pix.pixelformat,
  CS_SEL_ANY, true);
-   priv->vdev.compose.left = 0;
-   priv->vdev.compose.top = 0;
-   priv->vdev.compose.width = fmt_src.format.width;
-   priv->vdev.compose.height = fmt_src.format.height;
+   priv->vdev.compose = compose;
 
return 0;
 }
@@ -524,6 +530,33 @@ static void capture_buf_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(&priv->q_lock, flags);
 }
 
+static int capture_validate_fmt(struct capture_priv *priv)
+{
+   struct v4l2_subdev_format fmt_src;
+   struct v4l2_rect compose;
+   struct v4l2_format f;
+   int ret;
+
+   fmt_src.pad = priv->src_sd_pad;
+   fmt_src.which = V4L2

[PATCH 1/6] media: staging/imx: Switch to sync registration for IPU subdevs

2019-04-25 Thread Steve Longerbeam
Because the IPU sub-devices VDIC and IC are not present in the
device-tree, platform devices were created for them instead. This
allowed these sub-devices to be added to the media device's async
notifier and registered asynchronously along with the other
sub-devices that do have a device-tree presence (CSI and devices
external to the IPU and SoC).

But that approach isn't really necessary. The IPU sub-devices don't
actually require a backing device (sd->dev is allowed to be NULL).
And that approach can't get around the fact that the IPU sub-devices
are not part of a device hierarchy, which makes it awkward to retrieve
the parent IPU of these devices.

By registering them synchronously, they can be registered from the CSI
async bound notifier, so the init function for them can be given the CSI
subdev, who's dev->parent is the IPU. That is a somewhat cleaner way
to retrieve the parent IPU.

So convert to synchronous registration for the VDIC and IC task
sub-devices, at the time a CSI sub-device is bound. There is no longer
a backing device for them (sd->dev is NULL), but that's ok. Also
set the VDIC/IC sub-device owner as the IPU, so that a reference can
be taken on the IPU module.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-ic-common.c |  70 ++--
 drivers/staging/media/imx/imx-ic-prp.c|  34 +-
 drivers/staging/media/imx/imx-ic-prpencvf.c   |  70 ++--
 drivers/staging/media/imx/imx-ic.h|   7 +-
 drivers/staging/media/imx/imx-media-capture.c |   7 +-
 drivers/staging/media/imx/imx-media-csi.c |   2 +-
 drivers/staging/media/imx/imx-media-dev.c | 121 +-
 .../staging/media/imx/imx-media-internal-sd.c | 356 --
 drivers/staging/media/imx/imx-media-of.c  |  38 +-
 drivers/staging/media/imx/imx-media-vdic.c|  85 ++---
 drivers/staging/media/imx/imx-media.h |  67 ++--
 drivers/staging/media/imx/imx7-media-csi.c|   3 +-
 12 files changed, 325 insertions(+), 535 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-common.c 
b/drivers/staging/media/imx/imx-ic-common.c
index 1addb0893c57..ad0c291db03c 100644
--- a/drivers/staging/media/imx/imx-ic-common.c
+++ b/drivers/staging/media/imx/imx-ic-common.c
@@ -8,8 +8,6 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  */
-#include 
-#include 
 #include 
 #include 
 #include "imx-media.h"
@@ -24,23 +22,25 @@ static struct imx_ic_ops *ic_ops[IC_NUM_OPS] = {
[IC_TASK_VIEWFINDER] = &imx_ic_prpencvf_ops,
 };
 
-static int imx_ic_probe(struct platform_device *pdev)
+struct v4l2_subdev *imx_media_ic_register(struct imx_media_dev *imxmd,
+ struct device *ipu_dev,
+ struct ipu_soc *ipu,
+ u32 grp_id)
 {
-   struct imx_media_ipu_internal_sd_pdata *pdata;
+   struct v4l2_device *v4l2_dev = &imxmd->v4l2_dev;
struct imx_ic_priv *priv;
int ret;
 
-   priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+   priv = devm_kzalloc(ipu_dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
-   return -ENOMEM;
+   return ERR_PTR(-ENOMEM);
 
-   platform_set_drvdata(pdev, &priv->sd);
-   priv->dev = &pdev->dev;
+   priv->ipu_dev = ipu_dev;
+   priv->ipu = ipu;
+   priv->md = imxmd;
 
-   /* get our ipu_id, grp_id and IC task id */
-   pdata = priv->dev->platform_data;
-   priv->ipu_id = pdata->ipu_id;
-   switch (pdata->grp_id) {
+   /* get our IC task id */
+   switch (grp_id) {
case IMX_MEDIA_GRP_ID_IPU_IC_PRP:
priv->task_id = IC_TASK_PRP;
break;
@@ -51,7 +51,7 @@ static int imx_ic_probe(struct platform_device *pdev)
priv->task_id = IC_TASK_VIEWFINDER;
break;
default:
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
}
 
v4l2_subdev_init(&priv->sd, ic_ops[priv->task_id]->subdev_ops);
@@ -59,55 +59,35 @@ static int imx_ic_probe(struct platform_device *pdev)
priv->sd.internal_ops = ic_ops[priv->task_id]->internal_ops;
priv->sd.entity.ops = ic_ops[priv->task_id]->entity_ops;
priv->sd.entity.function = MEDIA_ENT_F_PROC_VIDEO_SCALER;
-   priv->sd.dev = &pdev->dev;
-   priv->sd.owner = THIS_MODULE;
+   priv->sd.owner = ipu_dev->driver->owner;
priv->sd.flags = V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS;
-   priv->sd.grp_id = pdata->grp_id;
-   strscpy(priv->sd.name, pdata->sd_name, sizeof(priv->sd.name));
+   priv->sd.grp_id = grp_id;
+   imx_media_grp_id_to_sd_name(priv->sd.name, sizeof(priv->sd.name),
+   priv->sd.grp_id, ipu_get_num(ipu));
 
ret = ic_ops[priv->task_id]->init(priv);
if (ret)
-   return ret;
+   return ERR_PTR(ret);
 
-   r

[PATCH 4/6] Revert "media: imx: Set capture compose rectangle in capture_device_set_format"

2019-04-25 Thread Steve Longerbeam
Rvert this commit, as imx_media_capture_device_set_format() will be
removed.

This reverts commit 5964cbd8692252615370b77eb96764dd70c2f837.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-ic-prpencvf.c   |  5 ++--
 drivers/staging/media/imx/imx-media-capture.c | 24 +--
 drivers/staging/media/imx/imx-media-csi.c |  5 ++--
 drivers/staging/media/imx/imx-media-utils.c   | 20 
 drivers/staging/media/imx/imx-media.h |  6 ++---
 5 files changed, 23 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 8242d88dfb82..afaa3a8b15e9 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -910,7 +910,6 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
const struct imx_media_pixfmt *cc;
struct v4l2_pix_format vdev_fmt;
struct v4l2_mbus_framefmt *fmt;
-   struct v4l2_rect vdev_compose;
int ret = 0;
 
if (sdformat->pad >= PRPENCVF_NUM_PADS)
@@ -952,11 +951,11 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
priv->cc[sdformat->pad] = cc;
 
/* propagate output pad format to capture device */
-   imx_media_mbus_fmt_to_pix_fmt(&vdev_fmt, &vdev_compose,
+   imx_media_mbus_fmt_to_pix_fmt(&vdev_fmt,
  &priv->format_mbus[PRPENCVF_SRC_PAD],
  priv->cc[PRPENCVF_SRC_PAD]);
mutex_unlock(&priv->lock);
-   imx_media_capture_device_set_format(vdev, &vdev_fmt, &vdev_compose);
+   imx_media_capture_device_set_format(vdev, &vdev_fmt);
 
return 0;
 out:
diff --git a/drivers/staging/media/imx/imx-media-capture.c 
b/drivers/staging/media/imx/imx-media-capture.c
index 335084a6b0cd..555f6204660b 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -205,8 +205,7 @@ static int capture_g_fmt_vid_cap(struct file *file, void 
*fh,
 
 static int __capture_try_fmt_vid_cap(struct capture_priv *priv,
 struct v4l2_subdev_format *fmt_src,
-struct v4l2_format *f,
-struct v4l2_rect *compose)
+struct v4l2_format *f)
 {
const struct imx_media_pixfmt *cc, *cc_src;
 
@@ -246,8 +245,7 @@ static int __capture_try_fmt_vid_cap(struct capture_priv 
*priv,
}
}
 
-   imx_media_mbus_fmt_to_pix_fmt(&f->fmt.pix, compose,
- &fmt_src->format, cc);
+   imx_media_mbus_fmt_to_pix_fmt(&f->fmt.pix, &fmt_src->format, cc);
 
return 0;
 }
@@ -265,7 +263,7 @@ static int capture_try_fmt_vid_cap(struct file *file, void 
*fh,
if (ret)
return ret;
 
-   return __capture_try_fmt_vid_cap(priv, &fmt_src, f, NULL);
+   return __capture_try_fmt_vid_cap(priv, &fmt_src, f);
 }
 
 static int capture_s_fmt_vid_cap(struct file *file, void *fh,
@@ -273,7 +271,6 @@ static int capture_s_fmt_vid_cap(struct file *file, void 
*fh,
 {
struct capture_priv *priv = video_drvdata(file);
struct v4l2_subdev_format fmt_src;
-   struct v4l2_rect compose;
int ret;
 
if (vb2_is_busy(&priv->q)) {
@@ -287,14 +284,17 @@ static int capture_s_fmt_vid_cap(struct file *file, void 
*fh,
if (ret)
return ret;
 
-   ret = __capture_try_fmt_vid_cap(priv, &fmt_src, f, &compose);
+   ret = __capture_try_fmt_vid_cap(priv, &fmt_src, f);
if (ret)
return ret;
 
priv->vdev.fmt.fmt.pix = f->fmt.pix;
priv->vdev.cc = imx_media_find_format(f->fmt.pix.pixelformat,
  CS_SEL_ANY, true);
-   priv->vdev.compose = compose;
+   priv->vdev.compose.left = 0;
+   priv->vdev.compose.top = 0;
+   priv->vdev.compose.width = fmt_src.format.width;
+   priv->vdev.compose.height = fmt_src.format.height;
 
return 0;
 }
@@ -655,8 +655,7 @@ static struct video_device capture_videodev = {
 };
 
 void imx_media_capture_device_set_format(struct imx_media_video_dev *vdev,
-const struct v4l2_pix_format *pix,
-const struct v4l2_rect *compose)
+struct v4l2_pix_format *pix)
 {
struct capture_priv *priv = to_capture_priv(vdev);
 
@@ -664,7 +663,6 @@ void imx_media_capture_device_set_format(struct 
imx_media_video_dev *vdev,
priv->vdev.fmt.fmt.pix = *pix;
priv->vdev.cc = imx_media_find_format(pix->pixelformat, CS_SEL_ANY,
  true);
-   priv->vdev.compose = *compose;
mutex_unlock(&priv->mutex);
 }
 EXPORT_SYMBOL_GPL(imx_media_capture_device_set_format);
@@ -770,8 +768,10 @@ int imx_media_capture_device_register(s

[PATCH 3/6] media: staging/imx: Move add_video_device into capture_device_register

2019-04-25 Thread Steve Longerbeam
Move imx_media_add_video_device() into imx_media_capture_device_register().
Also the former has no error conditions to convert to void.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-ic-prpencvf.c   |  5 -
 drivers/staging/media/imx/imx-media-capture.c |  3 +++
 drivers/staging/media/imx/imx-media-csi.c |  7 +--
 drivers/staging/media/imx/imx-media-utils.c   |  9 -
 drivers/staging/media/imx/imx-media.h |  4 ++--
 drivers/staging/media/imx/imx7-media-csi.c| 12 +---
 6 files changed, 11 insertions(+), 29 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index ddcd87a17c71..8242d88dfb82 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -1241,7 +1241,6 @@ static int prp_s_frame_interval(struct v4l2_subdev *sd,
 static int prp_registered(struct v4l2_subdev *sd)
 {
struct prp_priv *priv = sd_to_priv(sd);
-   struct imx_ic_priv *ic_priv = priv->ic_priv;
int i, ret;
u32 code;
 
@@ -1271,10 +1270,6 @@ static int prp_registered(struct v4l2_subdev *sd)
if (ret)
return ret;
 
-   ret = imx_media_add_video_device(ic_priv->md, priv->vdev);
-   if (ret)
-   goto unreg;
-
ret = prp_init_controls(priv);
if (ret)
goto unreg;
diff --git a/drivers/staging/media/imx/imx-media-capture.c 
b/drivers/staging/media/imx/imx-media-capture.c
index 211ec4df2066..335084a6b0cd 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -780,6 +780,9 @@ int imx_media_capture_device_register(struct 
imx_media_video_dev *vdev)
 
vfd->ctrl_handler = &priv->ctrl_hdlr;
 
+   /* add vdev to the video device list */
+   imx_media_add_video_device(priv->md, vdev);
+
return 0;
 unreg:
video_unregister_device(vfd);
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index ea3d13103c91..c70fa6b509ae 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1820,13 +1820,8 @@ static int csi_registered(struct v4l2_subdev *sd)
if (ret)
goto free_fim;
 
-   ret = imx_media_add_video_device(priv->md, priv->vdev);
-   if (ret)
-   goto unreg;
-
return 0;
-unreg:
-   imx_media_capture_device_unregister(priv->vdev);
+
 free_fim:
if (priv->fim)
imx_media_fim_free(priv->fim);
diff --git a/drivers/staging/media/imx/imx-media-utils.c 
b/drivers/staging/media/imx/imx-media-utils.c
index c52aa59acd05..8a6e57652402 100644
--- a/drivers/staging/media/imx/imx-media-utils.c
+++ b/drivers/staging/media/imx/imx-media-utils.c
@@ -767,18 +767,17 @@ imx_media_find_subdev_by_devname(struct imx_media_dev 
*imxmd,
 EXPORT_SYMBOL_GPL(imx_media_find_subdev_by_devname);
 
 /*
- * Adds a video device to the master video device list. This is called by
- * an async subdev that owns a video device when it is registered.
+ * Adds a video device to the master video device list. This is called
+ * when a video device is registered.
  */
-int imx_media_add_video_device(struct imx_media_dev *imxmd,
-  struct imx_media_video_dev *vdev)
+void imx_media_add_video_device(struct imx_media_dev *imxmd,
+   struct imx_media_video_dev *vdev)
 {
mutex_lock(&imxmd->mutex);
 
list_add_tail(&vdev->list, &imxmd->vdev_list);
 
mutex_unlock(&imxmd->mutex);
-   return 0;
 }
 EXPORT_SYMBOL_GPL(imx_media_add_video_device);
 
diff --git a/drivers/staging/media/imx/imx-media.h 
b/drivers/staging/media/imx/imx-media.h
index ba2d75bcc4c9..71e20f53ed7b 100644
--- a/drivers/staging/media/imx/imx-media.h
+++ b/drivers/staging/media/imx/imx-media.h
@@ -189,8 +189,8 @@ imx_media_find_subdev_by_fwnode(struct imx_media_dev *imxmd,
 struct v4l2_subdev *
 imx_media_find_subdev_by_devname(struct imx_media_dev *imxmd,
 const char *devname);
-int imx_media_add_video_device(struct imx_media_dev *imxmd,
-  struct imx_media_video_dev *vdev);
+void imx_media_add_video_device(struct imx_media_dev *imxmd,
+   struct imx_media_video_dev *vdev);
 int imx_media_find_mipi_csi2_channel(struct imx_media_dev *imxmd,
 struct media_entity *start_entity);
 struct media_pad *
diff --git a/drivers/staging/media/imx/imx7-media-csi.c 
b/drivers/staging/media/imx/imx7-media-csi.c
index 96d01d8af874..f2037aba6e0e 100644
--- a/drivers/staging/media/imx/imx7-media-csi.c
+++ b/drivers/staging/media/imx/imx7-media-csi.c
@@ -1126,17 +1126,7 @@ static int imx7_csi_registered(struct v4l2_subdev *sd)
if (ret < 0)
return ret;
 
-   ret = imx_media_capture_device_register(c

[PATCH 2/6] media: staging/imx: Pass device to alloc/free_dma_buf

2019-04-25 Thread Steve Longerbeam
Allocate and free a DMA coherent buffer in imx_media_alloc/free_dma_buf()
from the given device. This allows DMA alloc and free using a device
that is backed by real hardware, which for the imx5/6/7 CSI is the CSI
unit, and for the internal IPU sub-devices, is the parent IPU.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-ic-prpencvf.c | 18 +-
 drivers/staging/media/imx/imx-media-csi.c   |  6 +++---
 drivers/staging/media/imx/imx-media-utils.c | 13 ++---
 drivers/staging/media/imx/imx-media.h   |  4 ++--
 drivers/staging/media/imx/imx7-media-csi.c  |  4 ++--
 5 files changed, 22 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 069cce512280..ddcd87a17c71 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -464,13 +464,13 @@ static int prp_setup_rotation(struct prp_priv *priv)
incc = priv->cc[PRPENCVF_SINK_PAD];
outcc = vdev->cc;
 
-   ret = imx_media_alloc_dma_buf(ic_priv->md, &priv->rot_buf[0],
+   ret = imx_media_alloc_dma_buf(ic_priv->ipu_dev, &priv->rot_buf[0],
  outfmt->sizeimage);
if (ret) {
v4l2_err(&ic_priv->sd, "failed to alloc rot_buf[0], %d\n", ret);
return ret;
}
-   ret = imx_media_alloc_dma_buf(ic_priv->md, &priv->rot_buf[1],
+   ret = imx_media_alloc_dma_buf(ic_priv->ipu_dev, &priv->rot_buf[1],
  outfmt->sizeimage);
if (ret) {
v4l2_err(&ic_priv->sd, "failed to alloc rot_buf[1], %d\n", ret);
@@ -543,9 +543,9 @@ static int prp_setup_rotation(struct prp_priv *priv)
 unsetup_vb2:
prp_unsetup_vb2_buf(priv, VB2_BUF_STATE_QUEUED);
 free_rot1:
-   imx_media_free_dma_buf(ic_priv->md, &priv->rot_buf[1]);
+   imx_media_free_dma_buf(ic_priv->ipu_dev, &priv->rot_buf[1]);
 free_rot0:
-   imx_media_free_dma_buf(ic_priv->md, &priv->rot_buf[0]);
+   imx_media_free_dma_buf(ic_priv->ipu_dev, &priv->rot_buf[0]);
return ret;
 }
 
@@ -563,8 +563,8 @@ static void prp_unsetup_rotation(struct prp_priv *priv)
 
ipu_ic_disable(priv->ic);
 
-   imx_media_free_dma_buf(ic_priv->md, &priv->rot_buf[0]);
-   imx_media_free_dma_buf(ic_priv->md, &priv->rot_buf[1]);
+   imx_media_free_dma_buf(ic_priv->ipu_dev, &priv->rot_buf[0]);
+   imx_media_free_dma_buf(ic_priv->ipu_dev, &priv->rot_buf[1]);
 }
 
 static int prp_setup_norotation(struct prp_priv *priv)
@@ -656,7 +656,7 @@ static int prp_start(struct prp_priv *priv)
 
outfmt = &vdev->fmt.fmt.pix;
 
-   ret = imx_media_alloc_dma_buf(ic_priv->md, &priv->underrun_buf,
+   ret = imx_media_alloc_dma_buf(ic_priv->ipu_dev, &priv->underrun_buf,
  outfmt->sizeimage);
if (ret)
goto out_put_ipu;
@@ -726,7 +726,7 @@ static int prp_start(struct prp_priv *priv)
 out_unsetup:
prp_unsetup(priv, VB2_BUF_STATE_QUEUED);
 out_free_underrun:
-   imx_media_free_dma_buf(ic_priv->md, &priv->underrun_buf);
+   imx_media_free_dma_buf(ic_priv->ipu_dev, &priv->underrun_buf);
 out_put_ipu:
prp_put_ipu_resources(priv);
return ret;
@@ -763,7 +763,7 @@ static void prp_stop(struct prp_priv *priv)
 
prp_unsetup(priv, VB2_BUF_STATE_ERROR);
 
-   imx_media_free_dma_buf(ic_priv->md, &priv->underrun_buf);
+   imx_media_free_dma_buf(ic_priv->ipu_dev, &priv->underrun_buf);
 
/* cancel the EOF timeout timer */
del_timer_sync(&priv->eof_timeout_timer);
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 93b107eab5f5..ea3d13103c91 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -612,7 +612,7 @@ static int csi_idmac_start(struct csi_priv *priv)
 
outfmt = &vdev->fmt.fmt.pix;
 
-   ret = imx_media_alloc_dma_buf(priv->md, &priv->underrun_buf,
+   ret = imx_media_alloc_dma_buf(priv->dev, &priv->underrun_buf,
  outfmt->sizeimage);
if (ret)
goto out_put_ipu;
@@ -666,7 +666,7 @@ static int csi_idmac_start(struct csi_priv *priv)
 out_unsetup:
csi_idmac_unsetup(priv, VB2_BUF_STATE_QUEUED);
 out_free_dma_buf:
-   imx_media_free_dma_buf(priv->md, &priv->underrun_buf);
+   imx_media_free_dma_buf(priv->dev, &priv->underrun_buf);
 out_put_ipu:
csi_idmac_put_ipu_resources(priv);
return ret;
@@ -698,7 +698,7 @@ static void csi_idmac_stop(struct csi_priv *priv)
 
csi_idmac_unsetup(priv, VB2_BUF_STATE_ERROR);
 
-   imx_media_free_dma_buf(priv->md, &priv->underrun_buf);
+   imx_media_free_dma_buf(priv->dev, &priv->underrun_buf);
 
/* cancel the EOF timeout timer */
del_timer_sync(&priv->eof_timeout_timer);
diff --git a/drivers/st

Re: [PATCH] staging: xgifb: delete the driver

2019-04-25 Thread Aaro Koskinen
Hi,

On Fri, Jan 18, 2019 at 12:20:28PM +0100, Daniel Vetter wrote:
> On Fri, Jan 18, 2019 at 11:08:28AM +0100, Greg Kroah-Hartman wrote:
> > There has not been any real work done on cleaning this driver up and
> > getting it out of the staging tree in years.  Also, no new fb drivers
> > are being added to the tree, so it should be converted into a drm driver
> > as well.
> > 
> > Due to the lack of interest in this codebase, just drop it.
> > 
> > Cc: Arnaud Patard 
> > Cc: Mauro Carvalho Chehab 
> > Reported-by: Daniel Vetter 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> Acked-by: Daniel Vetter 

Because of this I just lost fb/display on two of my computers...

So I guess to reintroduce the support for this HW I need to write a new
DRM driver and no staging work anymore. Which of the current DRM drivers
would be best to be used as a template/example for a new driver?

A.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8192u: ieee80211: Replace bit shifting with BIT macro

2019-04-25 Thread Gustavo A. R. Silva
Hi Vatsala,

On 4/25/19 1:33 PM, Vatsala Narang wrote:
> Challenge suggested by coccinelle.
> 

I think you mean *change*.

See more comments below...


> Replace bit shifting on 1 with the BIT(x) macro.
> Coccinelle script:
> 
> @@
> expression c;
> @@
> 
> -(1 << c)
> +BIT(c)
> 
> Signed-off-by: Vatsala Narang 
> ---
>  drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
> b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> index fa59c712c74b..c44662f03a6b 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> @@ -86,7 +86,7 @@ static inline char *rtl819x_translate_scan(struct 
> ieee80211_device *ieee,
>   /* Add the protocol name */
>   iwe.cmd = SIOCGIWNAME;
>   for(i=0; i - if(network->mode&(1< + if(network->mode&BIT(i)) {

A space is required before the open parenthesis: 'if ('.  Also, add
spaces around operators, in this case around '&'.

>   
> sprintf(pname,ieee80211_modes[i].mode_string,ieee80211_modes[i].mode_size);
>   pname +=ieee80211_modes[i].mode_size;
>   }
> @@ -394,7 +394,7 @@ int ieee80211_wx_set_encode(struct ieee80211_device *ieee,
>   sec.key_sizes[key] = len;
>   (*crypt)->ops->set_key(sec.keys[key], len, NULL,
>  (*crypt)->priv);
> - sec.flags |= (1 << key);
> + sec.flags |= BIT(key);
>   /* This ensures a key will be activated if no key is
>* explicitely set */

You could send a separate patch to fix the typo in the above
comment: explicitely -> explicitly.

I encourage you to adopt the practice of running checkpatch.pl
on your patches before submitting them.

Thanks
--
Gustavo

>   if (key == sec.active_key)
> @@ -415,7 +415,7 @@ int ieee80211_wx_set_encode(struct ieee80211_device *ieee,
>   (*crypt)->ops->set_key(sec.keys[key], 13, NULL,
>  (*crypt)->priv);
>   sec.key_sizes[key] = 13;
> - sec.flags |= (1 << key);
> + sec.flags |= BIT(key);
>   }
>  
>   /* No key data - just set the default TX key index */
> @@ -636,7 +636,7 @@ int ieee80211_wx_set_encode_ext(struct ieee80211_device 
> *ieee,
>   if (ext->alg != IW_ENCODE_ALG_NONE) {
>   //memcpy(sec.keys[idx], ext->key, ext->key_len);
>   sec.key_sizes[idx] = ext->key_len;
> - sec.flags |= (1 << idx);
> + sec.flags |= BIT(idx);
>   if (ext->alg == IW_ENCODE_ALG_WEP) {
> //  sec.encode_alg[idx] = SEC_ALG_WEP;
>   sec.flags |= SEC_LEVEL;
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Johannes Berg
On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 5:35 PM Al Viro  wrote:
> > 
> > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> > 
> > > If I understand your patch description well, using compat_ptr_ioctl
> > > only works if the driver is not for s390, right?
> > 
> > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > and be done with that; compat_ptr() is a no-op anyway" breaks.  IOW,
> > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > that thing works on all biarch architectures, as long as all stuff
> > handled by ->ioctl() takes pointer to arch-independent object as
> > argument.  IOW,
> > argument ignored => OK
> > any arithmetical type => no go, compat_ptr() would bugger it
> > pointer to int => OK
> > pointer to string => OK
> > pointer to u64 => OK
> > pointer to struct {u64 addr; char s[11];} => OK
> 
> To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> case is also broken on x86, because sizeof (obj) is smaller
> on i386, even though the location of the members are
> the same. i.e. you can copy_from_user() this

Actually, you can't even do that because the struct might sit at the end
of a page and then you'd erroneously fault in this case.

We had this a while ago with struct ifreq, see commit 98406133dd and its
parents.

johannes

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723bs: core: Remove return in void function

2019-04-25 Thread Julia Lawall



On Fri, 26 Apr 2019, Vatsala Narang wrote:

> Remove return in void function to get rid of checkpatch warning.
>
> Signed-off-by: Vatsala Narang 

Acked-by: Julia Lawall 

> ---
>  drivers/staging/rtl8723bs/core/rtw_xmit.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_xmit.c 
> b/drivers/staging/rtl8723bs/core/rtw_xmit.c
> index 094d61bcb469..67b9aeda7f3a 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_xmit.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_xmit.c
> @@ -2861,8 +2861,6 @@ void xmit_delivery_enabled_frames(struct adapter 
> *padapter, struct sta_info *pst
>
>   /* spin_unlock_bh(&psta->sleep_q.lock); */
>   spin_unlock_bh(&pxmitpriv->lock);
> -
> - return;
>  }
>
>  void enqueue_pending_xmitbuf(
> --
> 2.17.1
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: rtl8723bs: core: Remove return in void function

2019-04-25 Thread Vatsala Narang
Remove return in void function to get rid of checkpatch warning.

Signed-off-by: Vatsala Narang 
---
 drivers/staging/rtl8723bs/core/rtw_xmit.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_xmit.c 
b/drivers/staging/rtl8723bs/core/rtw_xmit.c
index 094d61bcb469..67b9aeda7f3a 100644
--- a/drivers/staging/rtl8723bs/core/rtw_xmit.c
+++ b/drivers/staging/rtl8723bs/core/rtw_xmit.c
@@ -2861,8 +2861,6 @@ void xmit_delivery_enabled_frames(struct adapter 
*padapter, struct sta_info *pst
 
/* spin_unlock_bh(&psta->sleep_q.lock); */
spin_unlock_bh(&pxmitpriv->lock);
-
-   return;
 }
 
 void enqueue_pending_xmitbuf(
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 1/2] staging: refer to TODO in Kconfig help text

2019-04-25 Thread Aaro Koskinen
Refer to TODO file instead of driver_name.README that does not seem to be
used.

Signed-off-by: Aaro Koskinen 
---
 drivers/staging/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 62951e836cbc..35aa09ed3972 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -16,8 +16,8 @@ menuconfig STAGING
 
  If you wish to work on these drivers, to help improve them, or
  to report problems you have with them, please see the
- driver_name.README file in the drivers/staging/ directory to
- see what needs to be worked on, and who to contact.
+ drivers/staging//TODO file to see what needs to be
+ worked on, and who to contact.
 
  If in doubt, say N here.
 
-- 
2.17.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 2/2] staging: octeon-ethernet: add TODO

2019-04-25 Thread Aaro Koskinen
Add missing TODO to describe the plan to get this driver out of staging.

Signed-off-by: Aaro Koskinen 
---
 drivers/staging/octeon/TODO | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 drivers/staging/octeon/TODO

diff --git a/drivers/staging/octeon/TODO b/drivers/staging/octeon/TODO
new file mode 100644
index ..67a0a1f6b922
--- /dev/null
+++ b/drivers/staging/octeon/TODO
@@ -0,0 +1,9 @@
+This driver is functional and supports Ethernet on OCTEON+/OCTEON2/OCTEON3
+chips at least up to CN7030.
+
+TODO:
+   - general code review and clean up
+   - make driver self-contained instead of being split between staging and
+ arch/mips/cavium-octeon.
+
+Contact: Aaro Koskinen 
-- 
2.17.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: rtl8192u: ieee80211: Replace bit shifting with BIT macro

2019-04-25 Thread Vatsala Narang
Challenge suggested by coccinelle.

Replace bit shifting on 1 with the BIT(x) macro.
Coccinelle script:

@@
expression c;
@@

-(1 << c)
+BIT(c)

Signed-off-by: Vatsala Narang 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index fa59c712c74b..c44662f03a6b 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -86,7 +86,7 @@ static inline char *rtl819x_translate_scan(struct 
ieee80211_device *ieee,
/* Add the protocol name */
iwe.cmd = SIOCGIWNAME;
for(i=0; imode&(1ops->set_key(sec.keys[key], len, NULL,
   (*crypt)->priv);
-   sec.flags |= (1 << key);
+   sec.flags |= BIT(key);
/* This ensures a key will be activated if no key is
 * explicitely set */
if (key == sec.active_key)
@@ -415,7 +415,7 @@ int ieee80211_wx_set_encode(struct ieee80211_device *ieee,
(*crypt)->ops->set_key(sec.keys[key], 13, NULL,
   (*crypt)->priv);
sec.key_sizes[key] = 13;
-   sec.flags |= (1 << key);
+   sec.flags |= BIT(key);
}
 
/* No key data - just set the default TX key index */
@@ -636,7 +636,7 @@ int ieee80211_wx_set_encode_ext(struct ieee80211_device 
*ieee,
if (ext->alg != IW_ENCODE_ALG_NONE) {
//memcpy(sec.keys[idx], ext->key, ext->key_len);
sec.key_sizes[idx] = ext->key_len;
-   sec.flags |= (1 << idx);
+   sec.flags |= BIT(idx);
if (ext->alg == IW_ENCODE_ALG_WEP) {
  //  sec.encode_alg[idx] = SEC_ALG_WEP;
sec.flags |= SEC_LEVEL;
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: comedi: comedi_isadma: Use a non-NULL device for DMA API

2019-04-25 Thread Greg Kroah-Hartman
On Thu, Apr 25, 2019 at 05:26:44PM +0100, Ian Abbott wrote:
> The "comedi_isadma" module calls `dma_alloc_coherent()` and
> `dma_free_coherent()` with a NULL device pointer which is no longer
> allowed.  If the `hw_dev` member of the `struct comedi_device` has been
> set to a valid device, that can be used instead.  Unfortunately, all the
> current users of the "comedi_isadma" module leave the `hw_dev` member
> set to NULL.  In that case, use a static dummy fallback device structure
> with the coherent DMA mask set to the ISA bus limit of 16MB.
> 
> Signed-off-by: Ian Abbott 
> ---
>  drivers/staging/comedi/drivers/comedi_isadma.c | 15 +--
>  drivers/staging/comedi/drivers/comedi_isadma.h |  3 +++
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/comedi/drivers/comedi_isadma.c 
> b/drivers/staging/comedi/drivers/comedi_isadma.c
> index b77dc8d5d3ff..8929952516a1 100644
> --- a/drivers/staging/comedi/drivers/comedi_isadma.c
> +++ b/drivers/staging/comedi/drivers/comedi_isadma.c
> @@ -14,6 +14,16 @@
>  
>  #include "comedi_isadma.h"
>  
> +/*
> + * Fallback device used when hardware device is NULL.
> + * This can be removed after drivers have been converted to use isa_driver.
> + */
> +static struct device fallback_dev = {
> + .init_name = "comedi_isadma fallback device",
> + .coherent_dma_mask = DMA_BIT_MASK(24),
> + .dma_mask = &fallback_dev.coherent_dma_mask,
> +};

Ick, no, static struct device are a very bad idea as this is a reference
counted structure and making it static can cause odd problems.

Why not just create a "real" one?  Or better yet, use the real device
for the comedi device as all of these drivers should have one now.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Al Viro
On Thu, Apr 25, 2019 at 05:55:23PM +0200, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 5:35 PM Al Viro  wrote:
> >
> > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > If I understand your patch description well, using compat_ptr_ioctl
> > > only works if the driver is not for s390, right?
> >
> > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > and be done with that; compat_ptr() is a no-op anyway" breaks.  IOW,
> > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > that thing works on all biarch architectures, as long as all stuff
> > handled by ->ioctl() takes pointer to arch-independent object as
> > argument.  IOW,
> > argument ignored => OK
> > any arithmetical type => no go, compat_ptr() would bugger it
> > pointer to int => OK
> > pointer to string => OK
> > pointer to u64 => OK
> > pointer to struct {u64 addr; char s[11];} => OK
> 
> To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> case is also broken on x86, because sizeof (obj) is smaller
> on i386, even though the location of the members are
> the same. i.e. you can copy_from_user() this, but not
> copy_to_user(), which overwrites 4 bytes after the end of
> the 20-byte user structure.

D'oh!  FWIW, it might be worth putting into Documentation/ somewhere;
basically, what is and what isn't biarch-neutral.

Or arch-neutral, for that matter - it's very close.  The only real
exception, IIRC, is an extra twist on m68k, where int behaves
like x86 long long - its alignment is only half its size, so
sizeof(struct {char c; int x;}) is 6, not 8 as everywhere
else.  Irrelevant for biarch, thankfully (until somebody gets insane
enough to implement 64bit coldfire, kernel port for it *and* biarch
support for m68k binaries on that thing, that is)...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: comedi: comedi_isadma: Use a non-NULL device for DMA API

2019-04-25 Thread Ian Abbott
The "comedi_isadma" module calls `dma_alloc_coherent()` and
`dma_free_coherent()` with a NULL device pointer which is no longer
allowed.  If the `hw_dev` member of the `struct comedi_device` has been
set to a valid device, that can be used instead.  Unfortunately, all the
current users of the "comedi_isadma" module leave the `hw_dev` member
set to NULL.  In that case, use a static dummy fallback device structure
with the coherent DMA mask set to the ISA bus limit of 16MB.

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/drivers/comedi_isadma.c | 15 +--
 drivers/staging/comedi/drivers/comedi_isadma.h |  3 +++
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/comedi_isadma.c 
b/drivers/staging/comedi/drivers/comedi_isadma.c
index b77dc8d5d3ff..8929952516a1 100644
--- a/drivers/staging/comedi/drivers/comedi_isadma.c
+++ b/drivers/staging/comedi/drivers/comedi_isadma.c
@@ -14,6 +14,16 @@
 
 #include "comedi_isadma.h"
 
+/*
+ * Fallback device used when hardware device is NULL.
+ * This can be removed after drivers have been converted to use isa_driver.
+ */
+static struct device fallback_dev = {
+   .init_name = "comedi_isadma fallback device",
+   .coherent_dma_mask = DMA_BIT_MASK(24),
+   .dma_mask = &fallback_dev.coherent_dma_mask,
+};
+
 /**
  * comedi_isadma_program - program and enable an ISA DMA transfer
  * @desc:  the ISA DMA cookie to program and enable
@@ -172,6 +182,7 @@ struct comedi_isadma *comedi_isadma_alloc(struct 
comedi_device *dev,
goto no_dma;
dma->desc = desc;
dma->n_desc = n_desc;
+   dma->dev = dev->hw_dev ? dev->hw_dev : &fallback_dev;
 
dma_chans[0] = dma_chan1;
if (dma_chan2 == 0 || dma_chan2 == dma_chan1)
@@ -192,7 +203,7 @@ struct comedi_isadma *comedi_isadma_alloc(struct 
comedi_device *dev,
desc = &dma->desc[i];
desc->chan = dma_chans[i];
desc->maxsize = maxsize;
-   desc->virt_addr = dma_alloc_coherent(NULL, desc->maxsize,
+   desc->virt_addr = dma_alloc_coherent(dma->dev, desc->maxsize,
 &desc->hw_addr,
 GFP_KERNEL);
if (!desc->virt_addr)
@@ -224,7 +235,7 @@ void comedi_isadma_free(struct comedi_isadma *dma)
for (i = 0; i < dma->n_desc; i++) {
desc = &dma->desc[i];
if (desc->virt_addr)
-   dma_free_coherent(NULL, desc->maxsize,
+   dma_free_coherent(dma->dev, desc->maxsize,
  desc->virt_addr,
  desc->hw_addr);
}
diff --git a/drivers/staging/comedi/drivers/comedi_isadma.h 
b/drivers/staging/comedi/drivers/comedi_isadma.h
index 2bd1329d727f..9d2b12db7e6e 100644
--- a/drivers/staging/comedi/drivers/comedi_isadma.h
+++ b/drivers/staging/comedi/drivers/comedi_isadma.h
@@ -10,6 +10,7 @@
 #include 
 
 struct comedi_device;
+struct device;
 
 /*
  * These are used to avoid issues when  and the DMA_MODE_
@@ -38,6 +39,7 @@ struct comedi_isadma_desc {
 
 /**
  * struct comedi_isadma - ISA DMA data
+ * @dev:   device to allocate non-coherent memory for
  * @desc:  cookie for each DMA buffer
  * @n_desc:the number of cookies
  * @cur_dma:   the current cookie in use
@@ -45,6 +47,7 @@ struct comedi_isadma_desc {
  * @chan2: the second DMA channel requested
  */
 struct comedi_isadma {
+   struct device *dev;
struct comedi_isadma_desc *desc;
int n_desc;
int cur_dma;
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Al Viro
On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:

> If I understand your patch description well, using compat_ptr_ioctl
> only works if the driver is not for s390, right?

No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
and be done with that; compat_ptr() is a no-op anyway" breaks.  IOW,
s390 is the reason for having compat_ptr_ioctl() in the first place;
that thing works on all biarch architectures, as long as all stuff
handled by ->ioctl() takes pointer to arch-independent object as
argument.  IOW,
argument ignored => OK
any arithmetical type => no go, compat_ptr() would bugger it
pointer to int => OK
pointer to string => OK
pointer to u64 => OK
pointer to struct {u64 addr; char s[11];} => OK
pointer to long => needs explicit handler
pointer to struct {void *addr; char s[11];} => needs explicit handler
pointer to struct {int x; u64 y;} => needs explicit handler on amd64
For "just use ->unlocked_ioctl for ->ioctl" we have
argument ignored => OK
any arithmetical type => OK
any pointer => instant breakage on s390, in addtion to cases that break
with compat_ptr_ioctl().

Probably some form of that ought to go into commit message for 
compat_ptr_ioctl()
introduction...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Arnd Bergmann
On Thu, Apr 25, 2019 at 5:35 PM Al Viro  wrote:
>
> On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
>
> > If I understand your patch description well, using compat_ptr_ioctl
> > only works if the driver is not for s390, right?
>
> No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> and be done with that; compat_ptr() is a no-op anyway" breaks.  IOW,
> s390 is the reason for having compat_ptr_ioctl() in the first place;
> that thing works on all biarch architectures, as long as all stuff
> handled by ->ioctl() takes pointer to arch-independent object as
> argument.  IOW,
> argument ignored => OK
> any arithmetical type => no go, compat_ptr() would bugger it
> pointer to int => OK
> pointer to string => OK
> pointer to u64 => OK
> pointer to struct {u64 addr; char s[11];} => OK

To be extra pedantic, the 'struct {u64 addr; char s[11];} '
case is also broken on x86, because sizeof (obj) is smaller
on i386, even though the location of the members are
the same. i.e. you can copy_from_user() this, but not
copy_to_user(), which overwrites 4 bytes after the end of
the 20-byte user structure.

   Arnd
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Mauro Carvalho Chehab
Em Thu, 25 Apr 2019 16:35:34 +0100
Al Viro  escreveu:

> On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> 
> > If I understand your patch description well, using compat_ptr_ioctl
> > only works if the driver is not for s390, right?  
> 
> No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> and be done with that; compat_ptr() is a no-op anyway" breaks.  IOW,
> s390 is the reason for having compat_ptr_ioctl() in the first place;
> that thing works on all biarch architectures, as long as all stuff
> handled by ->ioctl() takes pointer to arch-independent object as
> argument.  IOW,
>   argument ignored => OK
>   any arithmetical type => no go, compat_ptr() would bugger it
>   pointer to int => OK

That's the case for all LIRC ioctls: they all use a pointer to u32
argument.

>   pointer to string => OK
>   pointer to u64 => OK
>   pointer to struct {u64 addr; char s[11];} => OK
>   pointer to long => needs explicit handler
>   pointer to struct {void *addr; char s[11];} => needs explicit handler
>   pointer to struct {int x; u64 y;} => needs explicit handler on amd64
> For "just use ->unlocked_ioctl for ->ioctl" we have
>   argument ignored => OK
>   any arithmetical type => OK
>   any pointer => instant breakage on s390, in addtion to cases that break
> with compat_ptr_ioctl().
> 
> Probably some form of that ought to go into commit message for 
> compat_ptr_ioctl()
> introduction...

Agreed.

Thanks,
Mauro
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Mauro Carvalho Chehab
Em Tue, 16 Apr 2019 22:25:33 +0200
Arnd Bergmann  escreveu:

> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
> 
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
> 
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
> 
> Acked-by: Jason Gunthorpe 
> Acked-by: Daniel Vetter 
> Acked-by: Mauro Carvalho Chehab 
> Acked-by: Greg Kroah-Hartman 
> Acked-by: David Sterba 
> Acked-by: Darren Hart (VMware) 
> Acked-by: Jonathan Cameron 
> Acked-by: Bjorn Andersson 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/android/binder.c| 2 +-
>  drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +-
>  drivers/dma-buf/dma-buf.c   | 4 +---
>  drivers/dma-buf/sw_sync.c   | 2 +-
>  drivers/dma-buf/sync_file.c | 2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 2 +-
>  drivers/hid/hidraw.c| 4 +---
>  drivers/iio/industrialio-core.c | 2 +-
>  drivers/infiniband/core/uverbs_main.c   | 4 ++--
>  drivers/media/rc/lirc_dev.c | 4 +---

If I understand your patch description well, using compat_ptr_ioctl
only works if the driver is not for s390, right?

In thesis, nothing prevents to use LIRC API on s390 - as this isn't
a driver but, instead, RC core feature to expose raw remote controller
codes to userspace.

Yet, lirc_dev will only work if the system has a remote controller driver.

Well, we don't have any for s390. Despite we don't have such driver, 
I can't possible see why someone would use a remote controller for a
mainframe :-p

Anyway, if someone ever come with such driver/usecase, reverting this
change (or adding an #ifdef to check if arch is 390) should be
pretty straight forward.

So:

Acked-by: Mauro Carvalho Chehab 



>  drivers/mfd/cros_ec_dev.c   | 4 +---
>  drivers/misc/vmw_vmci/vmci_host.c   | 2 +-
>  drivers/nvdimm/bus.c| 4 ++--
>  drivers/nvme/host/core.c| 2 +-
>  drivers/pci/switch/switchtec.c  | 2 +-
>  drivers/platform/x86/wmi.c  | 2 +-
>  drivers/rpmsg/rpmsg_char.c  | 4 ++--
>  drivers/sbus/char/display7seg.c | 2 +-
>  drivers/sbus/char/envctrl.c | 4 +---
>  drivers/scsi/3w-.c  | 4 +---
>  drivers/scsi/cxlflash/main.c| 2 +-
>  drivers/scsi/esas2r/esas2r_main.c   | 2 +-
>  drivers/scsi/pmcraid.c  | 4 +---
>  drivers/staging/android/ion/ion.c   | 4 +---
>  drivers/staging/vme/devices/vme_user.c  | 2 +-
>  drivers/tee/tee_core.c  | 2 +-
>  drivers/usb/class/cdc-wdm.c | 2 +-
>  drivers/usb/class/usbtmc.c  | 4 +---
>  drivers/virt/fsl_hypervisor.c   | 2 +-
>  fs/btrfs/super.c| 2 +-
>  fs/ceph/dir.c   | 2 +-
>  fs/ceph/file.c  | 2 +-
>  fs/fuse/dev.c   | 2 +-
>  fs/notify/fanotify/fanotify_user.c  | 2 +-
>  fs/userfaultfd.c| 2 +-
>  net/rfkill/core.c   | 2 +-
>  36 files changed, 39 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index 4b9c7ca492e6..48109ade7234 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -5998,7 +5998,7 @@ const struct file_operations binder_fops = {
>   .owner = THIS_MODULE,
>   .poll = binder_poll,
>   .unlocked_ioctl = binder_ioctl,
> - .compat_ioctl = binder_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
>   .mmap = binder_mmap,
>   .open = binder_open,
>   .flush = binder_flush,
> diff --git a/drivers/crypto/qat/qat_common/adf_ctl_drv.c 
> b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> index abc7a7f64d64..ef0e482ee04f 100644
> --- a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> +++ b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> @@ -68,7 +68,7 @@ static long adf_ctl_ioctl(struct file *fp, unsigned int 
> cmd, unsigned long arg);
>  static const struct file_operations adf_ctl_ops = {
>   .owner = THIS_MODULE,
>   .unlocked_ioctl = adf_ctl_ioctl,
> - .compat_ioctl = adf_ctl_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
>  };
>  
>  struct adf_ctl_drv_info {
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 7c858020d14b..0cb336fe6324 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/d

[PATCH v3 0/2] MT7621 PCIe PHY

2019-04-25 Thread Sergio Paracuellos
This series adds support for the PCIe PHY found in the Mediatek
MT7621 SoC.

This is the first attempt to get feedback of what is missing in
this driver to be promoted from staging.

There is also a 'mt7621-pci' driver which is the controller part
which is still in staging and is a client of this phy.

Both drivers have been tested together in a gnubee1 board.

Changes in v3:
- Recollect Rob's Reviewed-by of bindings.
- Make Kishon Vijay suggested changes in v2:
(See https://lkml.org/lkml/2019/4/17/53)
- Kconfig:
* Add depends on COMPILE_TEST
* Select REGMAP_MMIO
- Make use of 'soc_device_attribute' and 'soc_device_match'
- Use regmap mmio API instead of directly 'readl' and 'writel'.
- Use 'platform_get_resource' instead of 'of_address_to_resource'.

Changes in v2:
- Reorder patches to get bindings first in the series.
- Don't use child nodes in the device tree. Use #phy-cells=1 instead.
- Update driver code with new 'xlate' function for the new device tree.
- Minor changes in driver's macros changing some spaces to tabs.

Thanks in advance for your time.

Best regards,
Sergio Paracuellos

Sergio Paracuellos (2):
  dt-bindings: phy: Add binding for Mediatek MT7621 PCIe PHY
  phy: ralink: Add PHY driver for MT7621 PCIe PHY

 .../bindings/phy/mediatek,mt7621-pci-phy.txt  |  28 ++
 drivers/phy/ralink/Kconfig|   8 +
 drivers/phy/ralink/Makefile   |   1 +
 drivers/phy/ralink/phy-mt7621-pci.c   | 423 ++
 4 files changed, 460 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.txt
 create mode 100644 drivers/phy/ralink/phy-mt7621-pci.c

-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v3 1/2] dt-bindings: phy: Add binding for Mediatek MT7621 PCIe PHY

2019-04-25 Thread Sergio Paracuellos
Add bindings to describe Mediatek MT7621 PCIe PHY.

Reviewed-by: Rob Herring 
Signed-off-by: Sergio Paracuellos 
---
 .../bindings/phy/mediatek,mt7621-pci-phy.txt  | 28 +++
 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.txt 
b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.txt
new file mode 100644
index ..a369d715378b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.txt
@@ -0,0 +1,28 @@
+Mediatek Mt7621 PCIe PHY
+
+Required properties:
+- compatible: must be "mediatek,mt7621-pci-phy"
+- reg: base address and length of the PCIe PHY block
+- #phy-cells: must be <1> for pcie0_phy and for pcie1_phy.
+
+Example:
+   pcie0_phy: pcie-phy@1e149000 {
+   compatible = "mediatek,mt7621-pci-phy";
+   reg = <0x1e149000 0x0700>;
+   #phy-cells = <1>;
+   };
+
+   pcie1_phy: pcie-phy@1e14a000 {
+   compatible = "mediatek,mt7621-pci-phy";
+   reg = <0x1e14a000 0x0700>;
+   #phy-cells = <1>;
+   };
+
+   /* users of the PCIe phy */
+
+   pcie: pcie@1e14 {
+   ...
+   ...
+   phys = <&pcie0_phy 0>, <&pcie0_phy 1>, <&pcie1_phy 0>;
+   phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
+   };
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v3 2/2] phy: ralink: Add PHY driver for MT7621 PCIe PHY

2019-04-25 Thread Sergio Paracuellos
This patch adds a driver for the PCIe PHY of MT7621 SoC.

Signed-off-by: Sergio Paracuellos 
---
 drivers/phy/ralink/Kconfig  |   8 +
 drivers/phy/ralink/Makefile |   1 +
 drivers/phy/ralink/phy-mt7621-pci.c | 423 
 3 files changed, 432 insertions(+)
 create mode 100644 drivers/phy/ralink/phy-mt7621-pci.c

diff --git a/drivers/phy/ralink/Kconfig b/drivers/phy/ralink/Kconfig
index 14fd219535ef..429187ff02e2 100644
--- a/drivers/phy/ralink/Kconfig
+++ b/drivers/phy/ralink/Kconfig
@@ -1,6 +1,14 @@
 #
 # PHY drivers for Ralink platforms.
 #
+config PHY_MT7621_PCI
+   tristate "MediaTek MT7621 PCI PHY Driver"
+   depends on (RALINK || COMPILE_TEST) && OF
+   select GENERIC_PHY
+   select REGMAP_MMIO
+   help
+ Say 'Y' here to add support for MediaTek MT7621 PCI PHY driver,
+
 config PHY_RALINK_USB
tristate "Ralink USB PHY driver"
depends on RALINK || COMPILE_TEST
diff --git a/drivers/phy/ralink/Makefile b/drivers/phy/ralink/Makefile
index 5c9e326e8757..2052d5649863 100644
--- a/drivers/phy/ralink/Makefile
+++ b/drivers/phy/ralink/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_PHY_MT7621_PCI)   += phy-mt7621-pci.o
 obj-$(CONFIG_PHY_RALINK_USB)   += phy-ralink-usb.o
diff --git a/drivers/phy/ralink/phy-mt7621-pci.c 
b/drivers/phy/ralink/phy-mt7621-pci.c
new file mode 100644
index ..2576f179e30a
--- /dev/null
+++ b/drivers/phy/ralink/phy-mt7621-pci.c
@@ -0,0 +1,423 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mediatek MT7621 PCI PHY Driver
+ * Author: Sergio Paracuellos 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RALINK_CLKCFG1 0x30
+
+#define PCIE_PORT_CLK_EN(x)BIT(24 + (x))
+
+#define RG_PE1_PIPE_REG0x02c
+#define RG_PE1_PIPE_RSTBIT(12)
+#define RG_PE1_PIPE_CMD_FRCBIT(4)
+
+#define RG_P0_TO_P1_WIDTH  0x100
+#define RG_PE1_H_LCDDS_REG 0x49c
+#define RG_PE1_H_LCDDS_PCW GENMASK(30, 0)
+#define RG_PE1_H_LCDDS_PCW_VAL(x)  ((0x7fff & (x)) << 0)
+
+#define RG_PE1_FRC_H_XTAL_REG  0x400
+#define RG_PE1_FRC_H_XTAL_TYPE BIT(8)
+#define RG_PE1_H_XTAL_TYPE GENMASK(10, 9)
+#define RG_PE1_H_XTAL_TYPE_VAL(x)  ((0x3 & (x)) << 9)
+
+#define RG_PE1_FRC_PHY_REG 0x000
+#define RG_PE1_FRC_PHY_EN  BIT(4)
+#define RG_PE1_PHY_EN  BIT(5)
+
+#define RG_PE1_H_PLL_REG   0x490
+#define RG_PE1_H_PLL_BCGENMASK(23, 22)
+#define RG_PE1_H_PLL_BC_VAL(x) ((0x3 & (x)) << 22)
+#define RG_PE1_H_PLL_BPGENMASK(21, 18)
+#define RG_PE1_H_PLL_BP_VAL(x) ((0xf & (x)) << 18)
+#define RG_PE1_H_PLL_IRGENMASK(15, 12)
+#define RG_PE1_H_PLL_IR_VAL(x) ((0xf & (x)) << 12)
+#define RG_PE1_H_PLL_ICGENMASK(11, 8)
+#define RG_PE1_H_PLL_IC_VAL(x) ((0xf & (x)) << 8)
+#define RG_PE1_H_PLL_PREDIVGENMASK(7, 6)
+#define RG_PE1_H_PLL_PREDIV_VAL(x) ((0x3 & (x)) << 6)
+#define RG_PE1_PLL_DIVEN   GENMASK(3, 1)
+#define RG_PE1_PLL_DIVEN_VAL(x)((0x7 & (x)) << 1)
+
+#define RG_PE1_H_PLL_FBKSEL_REG0x4bc
+#define RG_PE1_H_PLL_FBKSELGENMASK(5, 4)
+#define RG_PE1_H_PLL_FBKSEL_VAL(x) ((0x3 & (x)) << 4)
+
+#defineRG_PE1_H_LCDDS_SSC_PRD_REG  0x4a4
+#define RG_PE1_H_LCDDS_SSC_PRD GENMASK(15, 0)
+#define RG_PE1_H_LCDDS_SSC_PRD_VAL(x)  ((0x & (x)) << 0)
+
+#define RG_PE1_H_LCDDS_SSC_DELTA_REG   0x4a8
+#define RG_PE1_H_LCDDS_SSC_DELTA   GENMASK(11, 0)
+#define RG_PE1_H_LCDDS_SSC_DELTA_VAL(x)((0xfff & (x)) << 0)
+#define RG_PE1_H_LCDDS_SSC_DELTA1  GENMASK(27, 16)
+#define RG_PE1_H_LCDDS_SSC_DELTA1_VAL(x)   ((0xff & (x)) << 16)
+
+#define RG_PE1_LCDDS_CLK_PH_INV_REG0x4a0
+#define RG_PE1_LCDDS_CLK_PH_INVBIT(5)
+
+#define RG_PE1_H_PLL_BR_REG0x4ac
+#define RG_PE1_H_PLL_BRGENMASK(18, 16)
+#define RG_PE1_H_PLL_BR_VAL(x) ((0x7 & (x)) << 16)
+
+#defineRG_PE1_MSTCKDIV_REG 0x414
+#define RG_PE1_MSTCKDIVGENMASK(7, 6)
+#define RG_PE1_MSTCKDIV_VAL(x) ((0x3 & (x)) << 6)
+
+#define RG_PE1_FRC_MSTCKDIVBIT(5)
+
+#define MAX_PHYS   2
+
+/**
+ * struct mt7621_pci_phy_instance - Mt7621 Pcie PHY device
+ * @phy: pointer to the kernel PHY device
+ * @port_base: base reg

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Arnd Bergmann
On Thu, Apr 25, 2019 at 5:22 PM Mauro Carvalho Chehab
 wrote:
> Em Tue, 16 Apr 2019 22:25:33 +0200 Arnd Bergmann  escreveu:
>
> If I understand your patch description well, using compat_ptr_ioctl
> only works if the driver is not for s390, right?

No, the purpose of compat_ptr_ioctl() is to make sure it works
everywhere including s390.

Even on s390 it tends to work most of the time, but for correctness
the upper bit of a 32-bit pointer needs to be cleared, as
compat_ptr_ioctl does, in case some application passes a pointer
with that bit set. [IIRC, in the instruction pointer, the high bit is set, in
data references it is ignored but usually cleared, but it may be left
on for IP-relative address generation]

   Arnd
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2] staging: kpc2000: Add DMA driver

2019-04-25 Thread 'gre...@linuxfoundation.org'
On Mon, Apr 22, 2019 at 10:05:58PM +, Matt Sickler wrote:
> Add Daktronics DMA driver.  I've added the SPDX license identifiers, Kconfig
> entry, and cleaned up as many of the warnings as I could.
> 
> The AIO support code will be removed in a future patch.
> 
> Signed-off-by: Matt Sickler 

Looks good, now applied, thanks for doing this.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v4 3/4] media: pixfmt: Document the HEVC slice pixel format

2019-04-25 Thread Paul Kocialkowski
Document the current state of the HEVC slice pixel format.
The format will need to evolve in the future, which is why it is
not part of the public API.

Signed-off-by: Paul Kocialkowski 
---
 .../media/uapi/v4l/pixfmt-compressed.rst  | 21 +++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/media/uapi/v4l/pixfmt-compressed.rst 
b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
index 4b701fc7653e..9d4195723c3e 100644
--- a/Documentation/media/uapi/v4l/pixfmt-compressed.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
@@ -143,6 +143,27 @@ Compressed Formats
   - ``V4L2_PIX_FMT_HEVC``
   - 'HEVC'
   - HEVC/H.265 video elementary stream.
+* .. _V4L2-PIX-FMT-HEVC-SLICE:
+
+  - ``V4L2_PIX_FMT_HEVC_SLICE``
+  - 'S265'
+  - HEVC parsed slice data, as extracted from the HEVC bitstream.
+   This format is adapted for stateless video decoders that implement a
+   HEVC pipeline (using the :ref:`codec` and :ref:`media-request-api`).
+   Metadata associated with the frame to decode is required to be passed
+   through the following controls :
+* ``V4L2_CID_MPEG_VIDEO_HEVC_SPS``
+* ``V4L2_CID_MPEG_VIDEO_HEVC_PPS``
+* ``V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS``
+   See the :ref:`associated Codec Control IDs `.
+   Buffers associated with this pixel format must contain the appropriate
+   number of macroblocks to decode a full corresponding frame.
+
+   .. note::
+
+  This format is not yet part of the public kernel API and it
+  is expected to change.
+
 * .. _V4L2-PIX-FMT-FWHT:
 
   - ``V4L2_PIX_FMT_FWHT``
-- 
2.21.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v4 4/4] media: cedrus: Add HEVC/H.265 decoding support

2019-04-25 Thread Paul Kocialkowski
This introduces support for HEVC/H.265 to the Cedrus VPU driver, with
both uni-directional and bi-directional prediction modes supported.

Field-coded (interlaced) pictures, custom quantization matrices and
10-bit output are not supported at this point.

Signed-off-by: Paul Kocialkowski 
---
 drivers/staging/media/sunxi/cedrus/Makefile   |   2 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |  31 +-
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  18 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |   9 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  | 532 ++
 .../staging/media/sunxi/cedrus/cedrus_hw.c|   4 +
 .../staging/media/sunxi/cedrus/cedrus_regs.h  | 290 ++
 .../staging/media/sunxi/cedrus/cedrus_video.c |  10 +
 8 files changed, 891 insertions(+), 5 deletions(-)
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h265.c

diff --git a/drivers/staging/media/sunxi/cedrus/Makefile 
b/drivers/staging/media/sunxi/cedrus/Makefile
index aaf141fc58b6..186cb6d01b67 100644
--- a/drivers/staging/media/sunxi/cedrus/Makefile
+++ b/drivers/staging/media/sunxi/cedrus/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus.o
 
 sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o cedrus_dec.o \
-cedrus_mpeg2.o cedrus_h264.o
+cedrus_mpeg2.o cedrus_h264.o cedrus_h265.o
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index d613f5c24a2f..b7b7646a8c43 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -70,6 +70,24 @@ static const struct cedrus_control cedrus_controls[] = {
.codec  = CEDRUS_CODEC_H264,
.required   = true,
},
+   {
+   .id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
+   .elem_size  = sizeof(struct v4l2_ctrl_hevc_sps),
+   .codec  = CEDRUS_CODEC_H265,
+   .required   = true,
+   },
+   {
+   .id = V4L2_CID_MPEG_VIDEO_HEVC_PPS,
+   .elem_size  = sizeof(struct v4l2_ctrl_hevc_pps),
+   .codec  = CEDRUS_CODEC_H265,
+   .required   = true,
+   },
+   {
+   .id = V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS,
+   .elem_size  = sizeof(struct v4l2_ctrl_hevc_slice_params),
+   .codec  = CEDRUS_CODEC_H265,
+   .required   = true,
+   },
 };
 
 #define CEDRUS_CONTROLS_COUNT  ARRAY_SIZE(cedrus_controls)
@@ -309,6 +327,7 @@ static int cedrus_probe(struct platform_device *pdev)
 
dev->dec_ops[CEDRUS_CODEC_MPEG2] = &cedrus_dec_ops_mpeg2;
dev->dec_ops[CEDRUS_CODEC_H264] = &cedrus_dec_ops_h264;
+   dev->dec_ops[CEDRUS_CODEC_H265] = &cedrus_dec_ops_h265;
 
mutex_init(&dev->dev_mutex);
 
@@ -416,19 +435,23 @@ static const struct cedrus_variant 
sun8i_a33_cedrus_variant = {
 };
 
 static const struct cedrus_variant sun8i_h3_cedrus_variant = {
-   .capabilities   = CEDRUS_CAPABILITY_UNTILED,
+   .capabilities   = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_H265_DEC,
 };
 
 static const struct cedrus_variant sun50i_a64_cedrus_variant = {
-   .capabilities   = CEDRUS_CAPABILITY_UNTILED,
+   .capabilities   = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_H265_DEC,
 };
 
 static const struct cedrus_variant sun50i_h5_cedrus_variant = {
-   .capabilities   = CEDRUS_CAPABILITY_UNTILED,
+   .capabilities   = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_H265_DEC,
 };
 
 static const struct cedrus_variant sun50i_h6_cedrus_variant = {
-   .capabilities   = CEDRUS_CAPABILITY_UNTILED,
+   .capabilities   = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_H265_DEC,
.quirks = CEDRUS_QUIRK_NO_DMA_OFFSET,
 };
 
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index bef79f630520..05de29b52fca 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -27,12 +27,14 @@
 #define CEDRUS_NAME"cedrus"
 
 #define CEDRUS_CAPABILITY_UNTILED  BIT(0)
+#define CEDRUS_CAPABILITY_H265_DEC BIT(1)
 
 #define CEDRUS_QUIRK_NO_DMA_OFFSET BIT(0)
 
 enum cedrus_codec {
CEDRUS_CODEC_MPEG2,
CEDRUS_CODEC_H264,
+   CEDRUS_CODEC_H265,
CEDRUS_CODEC_LAST,
 };
 
@@ -68,6 +70,12 @@ struct cedrus_mpeg2_run {
const struct v4l2_ctrl_mpeg2_quantization   *quantization;
 };
 
+struct cedrus_h265_run {
+   const struct v4l2_ctrl_hevc_sps *sps;
+   const struct v4l2_ctrl_hevc_pps *pps;
+   const struct v4l2_ctrl_hevc_slice_params*slice_params;
+};
+
 struct cedrus_run {
struct vb2_v4l2_bu

[PATCH v4 2/4] media: pixfmt: Add HEVC slice pixel format

2019-04-25 Thread Paul Kocialkowski
Introduce the V4L2_PIX_FMT_HEVC_SLICE pixel format, which currently
describes an output buffer with enough appended slice data for
producing one decoded frame with a stateless video decoder.

This will need to be reworked (along with the controls and the core) to
allow passing slice data individually, as it is the natural decoding
unit in HEVC.

We also need to figure out the description of the possible source data:
* Compressed slice data only, with slice controls attached;
* Slice data in Annex-B format (with raw slice header), without slice
  controls attached;
* Slice data in Annex-B format (with raw slice header), with slice
  controls attached.

Signed-off-by: Paul Kocialkowski 
---
 include/media/hevc-ctrls.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index 9ea013c88afc..2de83d9f6d47 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -11,6 +11,9 @@
 #ifndef _HEVC_CTRLS_H_
 #define _HEVC_CTRLS_H_
 
+/* The pixel format isn't stable at the moment and will likely be renamed. */
+#define V4L2_PIX_FMT_HEVC_SLICE v4l2_fourcc('S', '2', '6', '5') /* HEVC parsed 
slices */
+
 #define V4L2_CID_MPEG_VIDEO_HEVC_SPS   (V4L2_CID_MPEG_BASE + 1008)
 #define V4L2_CID_MPEG_VIDEO_HEVC_PPS   (V4L2_CID_MPEG_BASE + 1009)
 #define V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS  (V4L2_CID_MPEG_BASE + 1010)
-- 
2.21.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v4 0/4] HEVC/H.265 stateless support for V4L2 and Cedrus

2019-04-25 Thread Paul Kocialkowski
This is early support for HEVC/H.265 stateless decoding in V4L2,
including both definitions and driver support for the Cedrus VPU
driver, which concerns Allwinner devices.

A specific pixel format is introduced for the HEVC slice format and
controls are provided to pass the bitstream metadata to the decoder.
Some bitstream extensions are intentionally not supported at this point.

Since this is the first proposal for stateless HEVC/H.265 support in
V4L2, reviews and comments about the controls definitions are
particularly welcome.

On the Cedrus side, the H.265 implementation covers frame pictures
with both uni-directional and bi-direction prediction modes (P/B
slices). Field pictures (interleaved), scaling lists and 10-bit output
are not supported at this point.

This series is based upon the following series:
* media: cedrus: Add H264 decoding support

Changes since v3:
* Updated commit messages;
* Updated CID base to avoid conflicts;
* Used cpu_to_le32 for packed le32 data;
* Fixed misc minor issues in the drive code;
* Made it clear in the docs that the API will evolve;
* Made the pixfmt private and split commits about it.

Changes since v2:
* Moved headers to non-public API;
* Added H265 capability for A64 and H5;
* Moved docs to ext-ctrls-codec.rst;
* Mentionned sections of the spec in the docs;
* Added padding to control structures for 32-bit alignment;
* Made write function use void/size in bytes;
* Reduced the number of arguments to helpers when possible;
* Removed PHYS_OFFSET since we already set PFN_OFFSET;
* Added comments where suggested;
* Moved to timestamp for references instead of index;
* Fixed some style issues reported by checkpatch.

Changes since v1:
* Added a H.265 capability to whitelist relevant platforms;
* Switched over to tags instead of buffer indices in the DPB
* Declared variable in their reduced scope as suggested;
* Added the H.265/HEVC spec to the biblio;
* Used in-doc references to the spec and the required APIs;
* Removed debugging leftovers.

Cheers!

Paul Kocialkowski (4):
  media: v4l: Add definitions for the HEVC slice controls
  media: pixfmt: Add HEVC slice pixel format
  media: pixfmt: Document the HEVC slice pixel format
  media: cedrus: Add HEVC/H.265 decoding support

 Documentation/media/uapi/v4l/biblio.rst   |   9 +
 .../media/uapi/v4l/ext-ctrls-codec.rst| 429 +-
 .../media/uapi/v4l/pixfmt-compressed.rst  |  21 +
 .../media/uapi/v4l/vidioc-queryctrl.rst   |  18 +
 .../media/videodev2.h.rst.exceptions  |   3 +
 drivers/media/v4l2-core/v4l2-ctrls.c  |  26 +
 drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
 drivers/staging/media/sunxi/cedrus/Makefile   |   2 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |  31 +-
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  18 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |   9 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  | 532 ++
 .../staging/media/sunxi/cedrus/cedrus_hw.c|   4 +
 .../staging/media/sunxi/cedrus/cedrus_regs.h  | 290 ++
 .../staging/media/sunxi/cedrus/cedrus_video.c |  10 +
 include/media/hevc-ctrls.h| 185 ++
 include/media/v4l2-ctrls.h|   7 +
 17 files changed, 1587 insertions(+), 8 deletions(-)
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h265.c
 create mode 100644 include/media/hevc-ctrls.h

-- 
2.21.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v4 1/4] media: v4l: Add definitions for the HEVC slice controls

2019-04-25 Thread Paul Kocialkowski
This introduces the required definitions for HEVC decoding support with
stateless VPUs. The controls associated to the HEVC slice format provide
the required meta-data for decoding slices extracted from the bitstream.

They are not exported to the public V4L2 API since reworking this API
will be needed for covering various use-cases and new hardware.

The interface comes with the following limitations:
* No custom quantization matrices (scaling lists);
* Support for a single temporal layer only;
* No slice entry point offsets support;
* No conformance window support;
* No VUI parameters support;
* No support for SPS extensions: range, multilayer, 3d, scc, 4 bits;
* No support for PPS extensions: range, multilayer, 3d, scc, 4 bits.
---
 Documentation/media/uapi/v4l/biblio.rst   |   9 +
 .../media/uapi/v4l/ext-ctrls-codec.rst| 429 +-
 .../media/uapi/v4l/vidioc-queryctrl.rst   |  18 +
 .../media/videodev2.h.rst.exceptions  |   3 +
 drivers/media/v4l2-core/v4l2-ctrls.c  |  26 ++
 drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
 include/media/hevc-ctrls.h| 182 
 include/media/v4l2-ctrls.h|   7 +
 8 files changed, 672 insertions(+), 3 deletions(-)
 create mode 100644 include/media/hevc-ctrls.h

diff --git a/Documentation/media/uapi/v4l/biblio.rst 
b/Documentation/media/uapi/v4l/biblio.rst
index 8f4eb8823d82..e38ef5ee4209 100644
--- a/Documentation/media/uapi/v4l/biblio.rst
+++ b/Documentation/media/uapi/v4l/biblio.rst
@@ -131,6 +131,15 @@ ITU-T Rec. H.264 Specification (04/2017 Edition)
 
 :author:International Telecommunication Union (http://www.itu.ch)
 
+.. _hevc:
+
+ITU H.265/HEVC
+==
+
+:title: ITU-T Rec. H.265 | ISO/IEC 23008-2 "High Efficiency Video Coding"
+
+:author:International Telecommunication Union (http://www.itu.ch), 
International Organisation for Standardisation (http://www.iso.ch)
+
 .. _jfif:
 
 JFIF
diff --git a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst 
b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
index fe720f239f70..62a456af7992 100644
--- a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
+++ b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
@@ -1901,9 +1901,9 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
   - ``reference_ts``
   - Timestamp of the V4L2 capture buffer to use as reference, used
 with B-coded and P-coded frames. The timestamp refers to the
-   ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
-   :c:func:`v4l2_timeval_to_ns()` function to convert the struct
-   :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
+``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
+:c:func:`v4l2_timeval_to_ns()` function to convert the struct
+:c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
 * - __u16
   - ``frame_num``
   -
@@ -3211,3 +3211,426 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
 Indicates whether to generate SPS and PPS at every IDR. Setting it to 0
 disables generating SPS and PPS at every IDR. Setting it to one enables
 generating SPS and PPS at every IDR.
+
+.. _v4l2-mpeg-hevc:
+
+``V4L2_CID_MPEG_VIDEO_HEVC_SPS (struct)``
+Specifies the Sequence Parameter Set fields (as extracted from the
+bitstream) for the associated HEVC slice data.
+These bitstream parameters are defined according to :ref:`hevc`.
+They are described in section 7.4.3.2 "Sequence parameter set RBSP
+semantics" of the specification.
+
+.. c:type:: v4l2_ctrl_hevc_sps
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_hevc_sps
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``chroma_format_idc``
+  -
+* - __u8
+  - ``separate_colour_plane_flag``
+  -
+* - __u16
+  - ``pic_width_in_luma_samples``
+  -
+* - __u16
+  - ``pic_height_in_luma_samples``
+  -
+* - __u8
+  - ``bit_depth_luma_minus8``
+  -
+* - __u8
+  - ``bit_depth_chroma_minus8``
+  -
+* - __u8
+  - ``log2_max_pic_order_cnt_lsb_minus4``
+  -
+* - __u8
+  - ``sps_max_dec_pic_buffering_minus1``
+  -
+* - __u8
+  - ``sps_max_num_reorder_pics``
+  -
+* - __u8
+  - ``sps_max_latency_increase_plus1``
+  -
+* - __u8
+  - ``log2_min_luma_coding_block_size_minus3``
+  -
+* - __u8
+  - ``log2_diff_max_min_luma_coding_block_size``
+  -
+* - __u8
+  - ``log2_min_luma_transform_block_size_minus2``
+  -
+* - __u8
+  - ``log2_diff_max_min_luma_transform_block_size``
+  -
+* - __u8
+  - ``max_transform_hierarchy_depth_inter``
+  -
+* - __u8
+  - ``max_transform_hierarchy_depth_intra``
+  -
+* - __u8
+  - ``scaling_list_enabled_flag``
+  -
+* - __u8
+  - ``amp_enabled_flag``
+  -
+* - __u8
+  - ``sample_ada