cron job: media_tree daily build: OK
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: Tue Sep 11 04:00:15 CEST 2018 media-tree git hash:d842a7cf938b6e0f8a1aa9f1aec0476c9a599310 media_build git hash: ed1d887e2c18299383c7258615130197c8ce4946 v4l-utils git hash: d26e4941419b05fcb2b6708ee32aef367c2ec4af edid-decode git hash: b2da1516df3cc2756bfe8d1fa06d7bf2562ba1f4 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.17.0-3-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-2.6.36.4-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-i686: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-i686: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-i686: OK linux-2.6.39.4-x86_64: OK linux-3.0.101-i686: OK linux-3.0.101-x86_64: OK linux-3.1.10-i686: OK linux-3.1.10-x86_64: OK linux-3.2.102-i686: OK linux-3.2.102-x86_64: OK linux-3.3.8-i686: OK linux-3.3.8-x86_64: OK linux-3.4.113-i686: OK linux-3.4.113-x86_64: OK linux-3.5.7-i686: OK linux-3.5.7-x86_64: OK linux-3.6.11-i686: OK linux-3.6.11-x86_64: OK linux-3.7.10-i686: OK linux-3.7.10-x86_64: OK linux-3.8.13-i686: OK linux-3.8.13-x86_64: OK linux-3.9.11-i686: OK linux-3.9.11-x86_64: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.119-i686: OK linux-3.18.119-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.152-i686: OK linux-4.4.152-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.124-i686: OK linux-4.9.124-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK 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.67-i686: OK linux-4.14.67-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.5-i686: OK linux-4.18.5-x86_64: OK linux-4.19-rc1-i686: OK linux-4.19-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH v2 5/5] media: ov5640: fix restore of last mode set
Hi Hugues,
On Monday, 10 September 2018 18:14:45 EEST Hugues FRUCHET wrote:
> On 09/07/2018 04:18 PM, Laurent Pinchart wrote:
> > On Thursday, 16 August 2018 18:07:54 EEST Hugues FRUCHET wrote:
> >> On 08/16/2018 12:10 PM, jacopo mondi wrote:
> >>> On Mon, Aug 13, 2018 at 12:19:46PM +0200, Hugues Fruchet wrote:
> >>>
> Mode setting depends on last mode set, in particular
> because of exposure calculation when downscale mode
> change between subsampling and scaling.
> At stream on the last mode was wrongly set to current mode,
> so no change was detected and exposure calculation
> was not made, fix this.
> >>>
> >>> I actually see a different issue here...
> >>
> >> Which problem do you have exactly, you got a VGA JPEG instead of a QVGA
> >> YUYV ?
> >>
> >>> The issue I see here depends on the format programmed through
> >>> set_fmt() never being applied when using the sensor with a media
> >>> controller equipped device (in this case an i.MX6 board) through
> >>> capture sessions, and the not properly calculated exposure you see may
> >>> be a consequence of this.
> >>>
> >>> I'll try to write down what I see, with the help of some debug output.
> >>>
> >>> - At probe time mode 640x460@30 is programmed:
> >>>
> >>> [1.651216] ov5640_probe: Initial mode with id: 2
> >>>
> >>> - I set the format on the sensor's pad and it gets not applied but
> >>> marked as pending as the sensor is powered off:
>>>
> >>> #media-ctl --set-v4l2 "'ov5640 2-003c':0[fmt:UYVY2X8/320x240
> >>> field:none]"
> >>> [ 65.611983] ov5640_set_fmt: NEW mode with id: 1 - PENDING
> >>
> >> So here sensor->current_mode is set to <1>;//QVGA
> >> and sensor->pending_mode_change is set to true;
> >>
> >>> - I start streaming with yavta, and the sensor receives a power on;
> >>> this causes the 'initial' format to be re-programmed and the
> >>> pending change to be ignored:
> >>>
> >>> #yavta -c10 -n4 -f YUYV -s $320x240 -F"../frame-#.yuv" /dev/video4
> >>>
> >>> [ 69.395018] ov5640_set_power:1805 - on
> >>> [ 69.431342] ov5640_restore_mode:1711
> >>> [ 69.996882] ov5640_set_mode: Apply mode with id: 0
> >>>
> >>> The 'ov5640_set_mode()' call from 'ov5640_restore_mode()' clears
> >>> the sensor->pending flag, discarding the newly requested format, for
> >>> this reason, at s_stream() time, the pending flag is not set
> >>> anymore.
> >>
> >> OK but before clearing sensor->pending_mode_change, set_mode() is
> >> loading registers corresponding to sensor->current_mode:
> >>
> >> static int ov5640_set_mode(struct ov5640_dev *sensor,
> >> const struct ov5640_mode_info *orig_mode)
> >> {
> >> ==>const struct ov5640_mode_info *mode = sensor->current_mode;
> >> ...
> >>ret = ov5640_set_mode_direct(sensor, mode, exposure);
> >>
> >> => so mode <1> is expected to be set now, so I don't understand your
> >> trace:
> >> "> [ 69.996882] ov5640_set_mode: Apply mode with id: 0"
> >> Which variable do you trace that shows "0" ?
> >>
> >>> Are you using a media-controller system? I suspect in non-mc cases,
> >>> the set_fmt is applied through a single power_on/power_off session, not
> >>> causing the 'restore_mode()' issue. Is this the case for you or your
> >>> issue is differnt?
> >>>
> >>> Edit:
> >>> Mita-san tried to address the issue of the output pixel format not
> >>> being restored when the image format was restored in
> >>> 19ad26f9e6e1 ("media: ov5640: add missing output pixel format setting")
> >>>
> >>> I understand the issue he tried to fix, but shouldn't the pending
> >>> format (if any) be applied instead of the initial one unconditionally?
> >>
> >> This is what does the ov5640_restore_mode(), set the current mode
> >> (sensor->current_mode), that is done through this line:
> >>
> >>/* now restore the last capture mode */
> >>ret = ov5640_set_mode(sensor, _mode_init_data);
> >>
> >> => note that the comment above is weird, in fact it is the "current"
> >> mode that is set.
> >> => note also that the 2nd parameter is not the mode to be set but the
> >> previously applied mode ! (ie loaded in ov5640 registers). This is used
> >> to decide if we have to go to the "set_mode_exposure_calc" or
> >> "set_mode_direct".
> >>
> >> the ov5640_restore_mode() also set the current pixel format
> >> (sensor->fmt), that is done through this line:
> >>
> >>return ov5640_set_framefmt(sensor, >fmt);
> >>
> >> ==> This is what have fixed Mita-san, this line was missing previously,
> >> leading to "mode registers" being loaded but not the "pixel format
> >> registers".
> >
> > This seems overly complicated to me. Why do we have to set the mode at
> > power on time at all, why can't we do it at stream on time only, and
> > simplify all this logic ?
>
> I'm not the author of this driver, Steve do you know the origin and the
> gain to do so ? Anyway, I would prefer that we stabilize currently
Re: [PATCH 3/3] media: replace strncpy() by strscpy()
On Mon, Sep 10, 2018 at 11:34 AM, Mauro Carvalho Chehab wrote: > Em Mon, 10 Sep 2018 09:18:05 -0700 > Kees Cook escreveu: > >> On Mon, Sep 10, 2018 at 5:19 AM, Mauro Carvalho Chehab >> wrote: >> > The strncpy() function is being deprecated upstream. Replace >> > it by the safer strscpy(). >> >> This one I'm quite concerned about. This could lead to kernel memory >> exposures if any of the callers depend on strncpy()'s trailing >> NUL-padding to clear a buffer of prior contents. >> >> How did you validate that for these changes? > > That's actually easy for those familiar with the V4L2 API. There are > several fields at either uAPI or kAPI (or both) that have strings. > > For example, a video input has a name. > > So, for one familiar with the V4L2 API, it is clear that something > like: > > + strscpy(inp->name, zr->card.input[inp->index].name, > + sizeof(inp->name)); > > Is just filling the uAPI with the name of Input, with is, typically, > something like: > S-Video > Television > Radio > Composite > > A visual inspection of the patch shows that, on almost all cases, it is > either filling a device driver's name (used mainly for debug routines), > a video Input, a format description string, or the video caps fields > name and driver. It looks like the ioctl path also pre-clears the output buffer before handing it over to the per-driver routines, so I think this looks okay. It's a large patch, but if you're comfortable with it, go for it. :) -Kees -- Kees Cook Pixel Security
Re: [PATCH v2 4/5] media: ov5640: fix auto controls values when switching to manual mode
Hi Hugues,
(Hans, there's a question for you below)
On Monday, 10 September 2018 17:43:27 EEST Hugues FRUCHET wrote:
> On 09/10/2018 12:46 PM, Laurent Pinchart wrote:
> > On Monday, 10 September 2018 13:23:41 EEST Hugues FRUCHET wrote:
> >> On 09/06/2018 03:31 PM, Laurent Pinchart wrote:
> >>> On Monday, 13 August 2018 13:19:45 EEST Hugues Fruchet wrote:
> >>>
> When switching from auto to manual mode, V4L2 core is calling
> g_volatile_ctrl() in manual mode in order to get the manual initial
> value. Remove the manual mode check/return to not break this
> behaviour.
>
> Signed-off-by: Hugues Fruchet
> ---
> drivers/media/i2c/ov5640.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 9fb17b5..c110a6a 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -2277,16 +2277,12 @@ static int ov5640_g_volatile_ctrl(struct
> v4l2_ctrl *ctrl)
>
> switch (ctrl->id) {
> case V4L2_CID_AUTOGAIN:
> -if (!ctrl->val)
> -return 0;
> val = ov5640_get_gain(sensor);
> if (val < 0)
> return val;
> sensor->ctrls.gain->val = val;
> break;
> >>>
> >>> What is this even supposed to do ? Only the V4L2_CID_GAIN and
> >>> V4L2_CID_EXPOSURE have the volatile flag set. Why can't this code be
> >>> replaced with
> >>
> >> This is because V4L2_CID_AUTOGAIN & V4L2_CID_GAIN are declared as
> >> auto-cluster:
> >>
> >>static int ov5640_init_controls(struct ov5640_dev *sensor)
> >>
> >>/* Auto/manual gain */
> >>ctrls->auto_gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_AUTOGAIN,
> >> 0, 1, 1, 1);
> >>ctrls->gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAIN,
> >>0, 1023, 1, 0);
> >>
> >> [...]
> >>
> >>v4l2_ctrl_auto_cluster(2, >auto_gain, 0, true);
> >>
> >> By checking many other drivers that are using clustered auto controls,
> >> they are all doing that way:
> >>
> >> ctrls->auto_x = v4l2_ctrl_new_std(CID_X_AUTO..
> >> ctrls->x = v4l2_ctrl_new_std(CID_X..
> >> v4l2_ctrl_auto_cluster(2, >auto, 0, true);
> >>
> >> g_volatile_ctrl(ctrl)
> >> switch (ctrl->id) {
> >> case CID_X_AUTO:
> >>ctrls->x->val = READ_REG()
> >
> > Seems like cargo-cult to me. Why is this better than the construct below
> > ?
>
> I have done the changes as per your suggestion, but behaviour is broken:
> when autogain control is on and I read gain value, gain is not refreshed
> with current gain value from sensor, but stick to last manual value set.
This looks like an issue in the control framework. We shouldn't have to force
all drivers to implement workarounds.
Hans, what's your opinion ?
> Moreover I've checked in vivid how it is done and still we have the
> structure of code I've already mentionned:
>
> static int vivid_user_vid_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
> {
> struct vivid_dev *dev = container_of(ctrl->handler, struct vivid_dev,
> ctrl_hdl_user_vid);
>
> switch (ctrl->id) {
> case V4L2_CID_AUTOGAIN:
> dev->gain->val = dev->jiffies_vid_cap & 0xff;
> break;
> }
> return 0;
> }
>
> >>> case V4L2_CID_GAIN:
> >>> val = ov5640_get_gain(sensor);
> >>> if (val < 0)
> >>> return val;
> >>> ctrl->val = val;
> >>> break;
> >>>
> case V4L2_CID_EXPOSURE_AUTO:
> -if (ctrl->val == V4L2_EXPOSURE_MANUAL)
> -return 0;
> val = ov5640_get_exposure(sensor);
> if (val < 0)
> return val;
> >>>
> >>> And same here.
--
Regards,
Laurent Pinchart
Re: [PATCH 2/2] vicodec: set state->info before calling the encode/decode funcs
On Mon, 2018-09-10 at 13:16 -0400, Nicolas Dufresne wrote: > Le lundi 10 septembre 2018 à 12:37 -0300, Ezequiel Garcia a écrit : > > On Mon, 2018-09-10 at 17:00 +0200, Hans Verkuil wrote: > > > From: Hans Verkuil > > > > > > state->info was NULL since I completely forgot to set state->info. > > > Oops. > > > > > > Reported-by: Ezequiel Garcia > > > Signed-off-by: Hans Verkuil > > > > For both patches: > > > > Tested-by: Ezequiel Garcia > > > > With these changes, now this gstreamer pipeline no longer > > crashes: > > > > gst-launch-1.0 -v videotestsrc num-buffers=30 ! video/x- > > raw,width=1280,height=720 ! v4l2fwhtenc capture-io-mode=mmap output- > > io-mode=mmap ! v4l2fwhtdec > > capture-io-mode=mmap output-io-mode=mmap ! fakesink > > > > A few things: > > > > * You now need to mark "[PATCH] vicodec: fix sparse warning" as > > invalid. > > * v4l2fwhtenc/v4l2fwhtdec elements are not upstream yet. > > * Gstreamer doesn't end properly; and it seems to negotiate > > Is the driver missing CMD_STOP implementation ? (draining flow) > I think that's the case. Gstreamer debug log, right before it stalls: 0:00:16.929785442 180 0x5593bcbd18a0 DEBUG v4l2videodec gstv4l2videodec.c:375:gst_v4l2_video_dec_finish: Finishing decoding 0:00:16.931866009 180 0x5593bcbd18a0 DEBUG v4l2videodec gstv4l2videodec.c:340:gst_v4l2_decoder_cmd: sending v4l2 decoder command 1 with flags 0 0:00:16.934260349 180 0x5593bcbd18a0 DEBUG v4l2videodec gstv4l2videodec.c:384:gst_v4l2_video_dec_finish: Waiting for decoder stop [stalls here] Regards, Ezequiel
[PATCH 2/3 v2] media: replace strcpy() by strscpy()
The strcpy() function is being deprecated upstream. Replace
it by the safer strscpy().
Signed-off-by: Mauro Carvalho Chehab
--
v2: removed the changes at the imon driver. There, the is a debugfs
node with a store function using DEVICE_ATTR() passing a char * buf
without any sizing information.
So, for now, keep using strcpy() there.
diff --git a/drivers/media/common/saa7146/saa7146_video.c
b/drivers/media/common/saa7146/saa7146_video.c
index 77d8fcdd4f66..efbf13c5ab82 100644
--- a/drivers/media/common/saa7146/saa7146_video.c
+++ b/drivers/media/common/saa7146/saa7146_video.c
@@ -451,7 +451,7 @@ static int vidioc_querycap(struct file *file, void *fh,
struct v4l2_capability *
struct video_device *vdev = video_devdata(file);
struct saa7146_dev *dev = ((struct saa7146_fh *)fh)->dev;
- strcpy((char *)cap->driver, "saa7146 v4l2");
+ strscpy((char *)cap->driver, "saa7146 v4l2", sizeof(cap->driver));
strscpy((char *)cap->card, dev->ext->name, sizeof(cap->card));
sprintf((char *)cap->bus_info, "PCI:%s", pci_name(dev->pci));
cap->device_caps =
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index c4e7ebfe4d29..961207cf09eb 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2422,7 +2422,7 @@ static int dvb_frontend_handle_ioctl(struct file *file,
struct dvb_frontend_info *info = parg;
memset(info, 0, sizeof(*info));
- strcpy(info->name, fe->ops.info.name);
+ strscpy(info->name, fe->ops.info.name, sizeof(info->name));
info->symbol_rate_min = fe->ops.info.symbol_rate_min;
info->symbol_rate_max = fe->ops.info.symbol_rate_max;
info->symbol_rate_tolerance =
fe->ops.info.symbol_rate_tolerance;
diff --git a/drivers/media/dvb-frontends/mt312.c
b/drivers/media/dvb-frontends/mt312.c
index aad07adda37d..03e74a729168 100644
--- a/drivers/media/dvb-frontends/mt312.c
+++ b/drivers/media/dvb-frontends/mt312.c
@@ -815,17 +815,20 @@ struct dvb_frontend *mt312_attach(const struct
mt312_config *config,
switch (state->id) {
case ID_VP310:
- strcpy(state->frontend.ops.info.name, "Zarlink VP310 DVB-S");
+ strscpy(state->frontend.ops.info.name, "Zarlink VP310 DVB-S",
+ sizeof(state->frontend.ops.info.name));
state->xtal = MT312_PLL_CLK;
state->freq_mult = 9;
break;
case ID_MT312:
- strcpy(state->frontend.ops.info.name, "Zarlink MT312 DVB-S");
+ strscpy(state->frontend.ops.info.name, "Zarlink MT312 DVB-S",
+ sizeof(state->frontend.ops.info.name));
state->xtal = MT312_PLL_CLK;
state->freq_mult = 6;
break;
case ID_ZL10313:
- strcpy(state->frontend.ops.info.name, "Zarlink ZL10313 DVB-S");
+ strscpy(state->frontend.ops.info.name, "Zarlink ZL10313 DVB-S",
+ sizeof(state->frontend.ops.info.name));
state->xtal = MT312_PLL_CLK_10_111;
state->freq_mult = 9;
break;
diff --git a/drivers/media/dvb-frontends/zl10039.c
b/drivers/media/dvb-frontends/zl10039.c
index 6293bd920fa6..333e4a1da13b 100644
--- a/drivers/media/dvb-frontends/zl10039.c
+++ b/drivers/media/dvb-frontends/zl10039.c
@@ -288,8 +288,9 @@ struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
state->id = state->id & 0x0f;
switch (state->id) {
case ID_ZL10039:
- strcpy(fe->ops.tuner_ops.info.name,
- "Zarlink ZL10039 DVB-S tuner");
+ strscpy(fe->ops.tuner_ops.info.name,
+ "Zarlink ZL10039 DVB-S tuner",
+ sizeof(fe->ops.tuner_ops.info.name));
break;
default:
dprintk("Chip ID=%x does not match a known type\n", state->id);
diff --git a/drivers/media/firewire/firedtv-fe.c
b/drivers/media/firewire/firedtv-fe.c
index 69087ae6c1d0..683957885ac4 100644
--- a/drivers/media/firewire/firedtv-fe.c
+++ b/drivers/media/firewire/firedtv-fe.c
@@ -247,7 +247,7 @@ void fdtv_frontend_init(struct firedtv *fdtv, const char
*name)
dev_err(fdtv->device, "no frontend for model type %d\n",
fdtv->type);
}
- strcpy(fi->name, name);
+ strscpy(fi->name, name, sizeof(fi->name));
fdtv->fe.dvb = >adapter;
fdtv->fe.sec_priv = fdtv;
diff --git a/drivers/media/i2c/ad5820.c b/drivers/media/i2c/ad5820.c
index 034ebf754007..907323f0ca3b 100644
--- a/drivers/media/i2c/ad5820.c
+++ b/drivers/media/i2c/ad5820.c
@@ -317,7 +317,7 @@ static int ad5820_probe(struct i2c_client *client,
v4l2_i2c_subdev_init(>subdev, client, _ops);
coil->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
Re: [PATCH 2/3] media: replace strcpy() by strscpy()
Em Mon, 10 Sep 2018 16:48:47 -0300
Mauro Carvalho Chehab escreveu:
> Em Mon, 10 Sep 2018 09:16:35 -0700
> Kees Cook escreveu:
>
> > On Mon, Sep 10, 2018 at 5:19 AM, Mauro Carvalho Chehab
> > wrote:
> > > The strcpy() function is being deprecated upstream. Replace
> > > it by the safer strscpy().
> >
> > Did you verify that all the destination buffers here are arrays and
> > not pointers? For example:
> >
> > struct thing {
> > char buffer[64];
> > char *ptr;
> > }
> >
> > strscpy(instance->buffer, source, sizeof(instance->buffer));
> >
> > is correct.
> >
> > But:
> >
> > strscpy(instance->ptr, source, sizeof(instance->ptr));
> >
> > will not be and will truncate strings to sizeof(char *).
> >
> > If you _did_ verify this, I'd love to know more about your tooling. :)
>
> I ended by implementing a simple tooling to test... it found just
> one place where it was wrong. I'll send the correct patch.
Btw, at the only case it was trying to fill a pointer was for
some sysfs fill. AFAIKT, the buffer size there is PAGE_SIZE,
so, I guess the enclosed patch would be the right way to use
strscpy().
Yet, IMHO, a better fix would be if the parameters for
DEVICE_ATTR store field would have a count.
Thanks,
Mauro
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 1041c056854d..989d2554ec72 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -772,9 +772,9 @@ static ssize_t show_associate_remote(struct device *d,
mutex_lock(>lock);
if (ictx->rf_isassociating)
- strcpy(buf, "associating\n");
+ strscpy(buf, "associating\n", PAGE_SIZE);
else
- strcpy(buf, "closed\n");
+ strscpy(buf, "closed\n", PAGE_SIZE);
dev_info(d, "Visit http://www.lirc.org/html/imon-24g.html for
instructions on how to associate your iMON 2.4G DT/LT remote\n");
mutex_unlock(>lock);
Re: [PATCH 2/3] media: replace strcpy() by strscpy()
Em Mon, 10 Sep 2018 09:16:35 -0700
Kees Cook escreveu:
> On Mon, Sep 10, 2018 at 5:19 AM, Mauro Carvalho Chehab
> wrote:
> > The strcpy() function is being deprecated upstream. Replace
> > it by the safer strscpy().
>
> Did you verify that all the destination buffers here are arrays and
> not pointers? For example:
>
> struct thing {
> char buffer[64];
> char *ptr;
> }
>
> strscpy(instance->buffer, source, sizeof(instance->buffer));
>
> is correct.
>
> But:
>
> strscpy(instance->ptr, source, sizeof(instance->ptr));
>
> will not be and will truncate strings to sizeof(char *).
>
> If you _did_ verify this, I'd love to know more about your tooling. :)
I ended by implementing a simple tooling to test... it found just
one place where it was wrong. I'll send the correct patch.
The tooling is actually a hack... see enclosed.
Basically, it defines a __strscpy() that will try to create a negative
array if the size is equal to a pointer size.
Then, I replaced all occurrences of strscpy with __strcpy() with:
$ for i in $(git grep -l strscpy drivers/media drivers/staging/media);
do sed s,strscpy,__strscpy,g -i $i; done
and compiled on 32 bits (that's my usual build). As all strings at
the media API are bigger than 4 bytes, it will only complain if it
tries to do a sizeof(*).
Thanks,
Mauro
TEST hack
diff --git a/include/linux/string.h b/include/linux/string.h
index 4a5a0eb7df51..06a87e328293 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -66,6 +66,15 @@ extern char * strrchr(const char *,int);
#endif
extern char * __must_check skip_spaces(const char *);
+
+#define __strscpy(origin, dest, size) \
+({ \
+ char zzz[1 - 2*(size == sizeof(char *))]; \
+ zzz[0] = 1; \
+ if (zzz[0] >2) zzz[0]++; \
+ strscpy(origin, dest, size); \
+})
+
extern char *strim(char *);
static inline __must_check char *strstrip(char *str)
Re: [PATCH 3/3] media: replace strncpy() by strscpy()
Em Mon, 10 Sep 2018 09:18:05 -0700 Kees Cook escreveu: > On Mon, Sep 10, 2018 at 5:19 AM, Mauro Carvalho Chehab > wrote: > > The strncpy() function is being deprecated upstream. Replace > > it by the safer strscpy(). > > This one I'm quite concerned about. This could lead to kernel memory > exposures if any of the callers depend on strncpy()'s trailing > NUL-padding to clear a buffer of prior contents. > > How did you validate that for these changes? That's actually easy for those familiar with the V4L2 API. There are several fields at either uAPI or kAPI (or both) that have strings. For example, a video input has a name. So, for one familiar with the V4L2 API, it is clear that something like: + strscpy(inp->name, zr->card.input[inp->index].name, + sizeof(inp->name)); Is just filling the uAPI with the name of Input, with is, typically, something like: S-Video Television Radio Composite A visual inspection of the patch shows that, on almost all cases, it is either filling a device driver's name (used mainly for debug routines), a video Input, a format description string, or the video caps fields name and driver. Thanks, Mauro
Re: [PATCH 2/2] vicodec: set state->info before calling the encode/decode funcs
Le lundi 10 septembre 2018 à 12:37 -0300, Ezequiel Garcia a écrit :
> On Mon, 2018-09-10 at 17:00 +0200, Hans Verkuil wrote:
> > From: Hans Verkuil
> >
> > state->info was NULL since I completely forgot to set state->info.
> > Oops.
> >
> > Reported-by: Ezequiel Garcia
> > Signed-off-by: Hans Verkuil
>
> For both patches:
>
> Tested-by: Ezequiel Garcia
>
> With these changes, now this gstreamer pipeline no longer
> crashes:
>
> gst-launch-1.0 -v videotestsrc num-buffers=30 ! video/x-
> raw,width=1280,height=720 ! v4l2fwhtenc capture-io-mode=mmap output-
> io-mode=mmap ! v4l2fwhtdec
> capture-io-mode=mmap output-io-mode=mmap ! fakesink
>
> A few things:
>
> * You now need to mark "[PATCH] vicodec: fix sparse warning" as
> invalid.
> * v4l2fwhtenc/v4l2fwhtdec elements are not upstream yet.
> * Gstreamer doesn't end properly; and it seems to negotiate
Is the driver missing CMD_STOP implementation ? (draining flow)
> different sizes for encoded and decoded unless explicitly set.
>
> Thanks!
>
> > drivers/media/platform/vicodec/vicodec-core.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/platform/vicodec/vicodec-core.c
> > b/drivers/media/platform/vicodec/vicodec-core.c
> > index fdd77441a47b..5d42a8414283 100644
> > --- a/drivers/media/platform/vicodec/vicodec-core.c
> > +++ b/drivers/media/platform/vicodec/vicodec-core.c
> > @@ -176,12 +176,15 @@ static int device_process(struct vicodec_ctx
> > *ctx,
> > }
> >
> > if (ctx->is_enc) {
> > - unsigned int size = v4l2_fwht_encode(state, p_in,
> > p_out);
> > -
> > - vb2_set_plane_payload(_vb->vb2_buf, 0, size);
> > + state->info = q_out->info;
> > + ret = v4l2_fwht_encode(state, p_in, p_out);
> > + if (ret < 0)
> > + return ret;
> > + vb2_set_plane_payload(_vb->vb2_buf, 0, ret);
> > } else {
> > + state->info = q_cap->info;
> > ret = v4l2_fwht_decode(state, p_in, p_out);
> > - if (ret)
> > + if (ret < 0)
> > return ret;
> > vb2_set_plane_payload(_vb->vb2_buf, 0, q_cap-
> > >sizeimage);
> > }
>
>
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 3/3] media: replace strncpy() by strscpy()
On Mon, Sep 10, 2018 at 5:19 AM, Mauro Carvalho Chehab wrote: > The strncpy() function is being deprecated upstream. Replace > it by the safer strscpy(). This one I'm quite concerned about. This could lead to kernel memory exposures if any of the callers depend on strncpy()'s trailing NUL-padding to clear a buffer of prior contents. How did you validate that for these changes? -Kees -- Kees Cook Pixel Security
Re: [PATCH 2/3] media: replace strcpy() by strscpy()
On Mon, Sep 10, 2018 at 5:19 AM, Mauro Carvalho Chehab
wrote:
> The strcpy() function is being deprecated upstream. Replace
> it by the safer strscpy().
Did you verify that all the destination buffers here are arrays and
not pointers? For example:
struct thing {
char buffer[64];
char *ptr;
}
strscpy(instance->buffer, source, sizeof(instance->buffer));
is correct.
But:
strscpy(instance->ptr, source, sizeof(instance->ptr));
will not be and will truncate strings to sizeof(char *).
If you _did_ verify this, I'd love to know more about your tooling. :)
-Kees
--
Kees Cook
Pixel Security
Re: [PATCH 1/3] media: use strscpy() instead of strlcpy()
On Mon, Sep 10, 2018 at 5:19 AM, Mauro Carvalho Chehab wrote: > The implementation of strscpy() is more robust and safer. > > That's now the recommended way to copy NUL terminated strings. This looks fine since I don't see anything using the strlcpy() return value (the return value meaning between strlcpy() and strscpy() differs). Reviewed-by: Kees Cook -Kees -- Kees Cook Pixel Security
Re: [PATCH 1/2] vicodec: Drop unneeded symbol dependency
On 09/10/2018 05:44 PM, Ezequiel Garcia wrote: > On Mon, 2018-09-10 at 17:23 +0200, Hans Verkuil wrote: >> On 09/10/2018 05:21 PM, Ezequiel Garcia wrote: >>> The vicodec doesn't use the Subdev API, so drop the dependency. >>> >>> Signed-off-by: Ezequiel Garcia >>> --- >>> drivers/media/platform/vicodec/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/media/platform/vicodec/Kconfig >>> b/drivers/media/platform/vicodec/Kconfig >>> index 2503bcb1529f..ad13329e3461 100644 >>> --- a/drivers/media/platform/vicodec/Kconfig >>> +++ b/drivers/media/platform/vicodec/Kconfig >>> @@ -1,6 +1,6 @@ >>> config VIDEO_VICODEC >>> tristate "Virtual Codec Driver" >>> - depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API >> >> But it definitely needs the MEDIA_CONTROLLER. That's what it should depend >> on. >> > > Does it really? The code have proper ifdefs. > You are right, it is not needed now, but will be when stateless codec support is added to vicodec in the future. Regards, Hans
Re: [PATCH 1/2] vicodec: Drop unneeded symbol dependency
On Mon, 2018-09-10 at 17:23 +0200, Hans Verkuil wrote: > On 09/10/2018 05:21 PM, Ezequiel Garcia wrote: > > The vicodec doesn't use the Subdev API, so drop the dependency. > > > > Signed-off-by: Ezequiel Garcia > > --- > > drivers/media/platform/vicodec/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/media/platform/vicodec/Kconfig > > b/drivers/media/platform/vicodec/Kconfig > > index 2503bcb1529f..ad13329e3461 100644 > > --- a/drivers/media/platform/vicodec/Kconfig > > +++ b/drivers/media/platform/vicodec/Kconfig > > @@ -1,6 +1,6 @@ > > config VIDEO_VICODEC > > tristate "Virtual Codec Driver" > > - depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > > But it definitely needs the MEDIA_CONTROLLER. That's what it should depend on. > Does it really? The code have proper ifdefs.
Re: [PATCH 2/2] vicodec: set state->info before calling the encode/decode funcs
On Mon, 2018-09-10 at 17:00 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> state->info was NULL since I completely forgot to set state->info.
> Oops.
>
> Reported-by: Ezequiel Garcia
> Signed-off-by: Hans Verkuil
For both patches:
Tested-by: Ezequiel Garcia
With these changes, now this gstreamer pipeline no longer
crashes:
gst-launch-1.0 -v videotestsrc num-buffers=30 !
video/x-raw,width=1280,height=720 ! v4l2fwhtenc capture-io-mode=mmap
output-io-mode=mmap ! v4l2fwhtdec
capture-io-mode=mmap output-io-mode=mmap ! fakesink
A few things:
* You now need to mark "[PATCH] vicodec: fix sparse warning" as invalid.
* v4l2fwhtenc/v4l2fwhtdec elements are not upstream yet.
* Gstreamer doesn't end properly; and it seems to negotiate
different sizes for encoded and decoded unless explicitly set.
Thanks!
> drivers/media/platform/vicodec/vicodec-core.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/vicodec/vicodec-core.c
> b/drivers/media/platform/vicodec/vicodec-core.c
> index fdd77441a47b..5d42a8414283 100644
> --- a/drivers/media/platform/vicodec/vicodec-core.c
> +++ b/drivers/media/platform/vicodec/vicodec-core.c
> @@ -176,12 +176,15 @@ static int device_process(struct vicodec_ctx *ctx,
> }
>
> if (ctx->is_enc) {
> - unsigned int size = v4l2_fwht_encode(state, p_in, p_out);
> -
> - vb2_set_plane_payload(_vb->vb2_buf, 0, size);
> + state->info = q_out->info;
> + ret = v4l2_fwht_encode(state, p_in, p_out);
> + if (ret < 0)
> + return ret;
> + vb2_set_plane_payload(_vb->vb2_buf, 0, ret);
> } else {
> + state->info = q_cap->info;
> ret = v4l2_fwht_decode(state, p_in, p_out);
> - if (ret)
> + if (ret < 0)
> return ret;
> vb2_set_plane_payload(_vb->vb2_buf, 0, q_cap->sizeimage);
> }
Re: [PATCH 1/2] vicodec: Drop unneeded symbol dependency
On 09/10/2018 05:21 PM, Ezequiel Garcia wrote: > The vicodec doesn't use the Subdev API, so drop the dependency. > > Signed-off-by: Ezequiel Garcia > --- > drivers/media/platform/vicodec/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/platform/vicodec/Kconfig > b/drivers/media/platform/vicodec/Kconfig > index 2503bcb1529f..ad13329e3461 100644 > --- a/drivers/media/platform/vicodec/Kconfig > +++ b/drivers/media/platform/vicodec/Kconfig > @@ -1,6 +1,6 @@ > config VIDEO_VICODEC > tristate "Virtual Codec Driver" > - depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API But it definitely needs the MEDIA_CONTROLLER. That's what it should depend on. Regards, Hans > + depends on VIDEO_DEV && VIDEO_V4L2 > select VIDEOBUF2_VMALLOC > select V4L2_MEM2MEM_DEV > default n >
[PATCH 2/2] vicodec: Drop unused job_abort()
The vicodec does not use the aborting field. In fact, this driver
can't really cancel any work, since it performs all the work
in device_run().
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/vicodec/vicodec-core.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index bbc48fcaa563..8d455c42163e 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -112,8 +112,6 @@ struct vicodec_ctx {
struct v4l2_ctrl_handler hdl;
- /* Abort requested by m2m */
- int aborting;
struct vb2_v4l2_buffer *last_src_buf;
struct vb2_v4l2_buffer *last_dst_buf;
@@ -376,14 +374,6 @@ static int job_ready(void *priv)
return 1;
}
-static void job_abort(void *priv)
-{
- struct vicodec_ctx *ctx = priv;
-
- /* Will cancel the transaction in the next interrupt handler */
- ctx->aborting = 1;
-}
-
/*
* video ioctls
*/
@@ -1268,7 +1258,6 @@ static const struct video_device vicodec_videodev = {
static const struct v4l2_m2m_ops m2m_ops = {
.device_run = device_run,
- .job_abort = job_abort,
.job_ready = job_ready,
};
--
2.19.0.rc2
[PATCH 1/2] vicodec: Drop unneeded symbol dependency
The vicodec doesn't use the Subdev API, so drop the dependency. Signed-off-by: Ezequiel Garcia --- drivers/media/platform/vicodec/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/vicodec/Kconfig b/drivers/media/platform/vicodec/Kconfig index 2503bcb1529f..ad13329e3461 100644 --- a/drivers/media/platform/vicodec/Kconfig +++ b/drivers/media/platform/vicodec/Kconfig @@ -1,6 +1,6 @@ config VIDEO_VICODEC tristate "Virtual Codec Driver" - depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + depends on VIDEO_DEV && VIDEO_V4L2 select VIDEOBUF2_VMALLOC select V4L2_MEM2MEM_DEV default n -- 2.19.0.rc2
Re: [PATCH v2 5/5] media: ov5640: fix restore of last mode set
Hi Laurent, Steve,
On 09/07/2018 04:18 PM, Laurent Pinchart wrote:
> Hello Hugues,
>
> On Thursday, 16 August 2018 18:07:54 EEST Hugues FRUCHET wrote:
>> On 08/16/2018 12:10 PM, jacopo mondi wrote:
>>> On Mon, Aug 13, 2018 at 12:19:46PM +0200, Hugues Fruchet wrote:
>>>
Mode setting depends on last mode set, in particular
because of exposure calculation when downscale mode
change between subsampling and scaling.
At stream on the last mode was wrongly set to current mode,
so no change was detected and exposure calculation
was not made, fix this.
>>>
>>> I actually see a different issue here...
>>
>> Which problem do you have exactly, you got a VGA JPEG instead of a QVGA
>> YUYV ?
>>
>>> The issue I see here depends on the format programmed through
>>> set_fmt() never being applied when using the sensor with a media
>>> controller equipped device (in this case an i.MX6 board) through
>>> capture sessions, and the not properly calculated exposure you see may
>>> be a consequence of this.
>>>
>>> I'll try to write down what I see, with the help of some debug output.
>>>
>>> - At probe time mode 640x460@30 is programmed:
>>>
>>> [1.651216] ov5640_probe: Initial mode with id: 2
>>>
>>> - I set the format on the sensor's pad and it gets not applied but
>>> marked as pending as the sensor is powered off:
>>>
>>> #media-ctl --set-v4l2 "'ov5640 2-003c':0[fmt:UYVY2X8/320x240
>>> field:none]"
>>> [ 65.611983] ov5640_set_fmt: NEW mode with id: 1 - PENDING
>>
>> So here sensor->current_mode is set to <1>;//QVGA
>> and sensor->pending_mode_change is set to true;
>>
>>> - I start streaming with yavta, and the sensor receives a power on;
>>> this causes the 'initial' format to be re-programmed and the pending
>>> change to be ignored:
>>>
>>> #yavta -c10 -n4 -f YUYV -s $320x240 -F"../frame-#.yuv" /dev/video4
>>>
>>> [ 69.395018] ov5640_set_power:1805 - on
>>> [ 69.431342] ov5640_restore_mode:1711
>>> [ 69.996882] ov5640_set_mode: Apply mode with id: 0
>>>
>>> The 'ov5640_set_mode()' call from 'ov5640_restore_mode()' clears the
>>> sensor->pending flag, discarding the newly requested format, for
>>> this reason, at s_stream() time, the pending flag is not set
>>> anymore.
>>
>> OK but before clearing sensor->pending_mode_change, set_mode() is
>> loading registers corresponding to sensor->current_mode:
>> static int ov5640_set_mode(struct ov5640_dev *sensor,
>> const struct ov5640_mode_info *orig_mode)
>> {
>> ==> const struct ov5640_mode_info *mode = sensor->current_mode;
>> ...
>> ret = ov5640_set_mode_direct(sensor, mode, exposure);
>>
>> => so mode <1> is expected to be set now, so I don't understand your trace:
>> "> [ 69.996882] ov5640_set_mode: Apply mode with id: 0"
>> Which variable do you trace that shows "0" ?
>>
>>> Are you using a media-controller system? I suspect in non-mc cases,
>>> the set_fmt is applied through a single power_on/power_off session, not
>>> causing the 'restore_mode()' issue. Is this the case for you or your
>>> issue is differnt?
>>>
>>> Edit:
>>> Mita-san tried to address the issue of the output pixel format not
>>> being restored when the image format was restored in
>>> 19ad26f9e6e1 ("media: ov5640: add missing output pixel format setting")
>>>
>>> I understand the issue he tried to fix, but shouldn't the pending
>>> format (if any) be applied instead of the initial one unconditionally?
>>
>> This is what does the ov5640_restore_mode(), set the current mode
>> (sensor->current_mode), that is done through this line:
>> /* now restore the last capture mode */
>> ret = ov5640_set_mode(sensor, _mode_init_data);
>> => note that the comment above is weird, in fact it is the "current"
>> mode that is set.
>> => note also that the 2nd parameter is not the mode to be set but the
>> previously applied mode ! (ie loaded in ov5640 registers). This is used
>> to decide if we have to go to the "set_mode_exposure_calc" or
>> "set_mode_direct".
>>
>> the ov5640_restore_mode() also set the current pixel format
>> (sensor->fmt), that is done through this line:
>> return ov5640_set_framefmt(sensor, >fmt);
>> ==> This is what have fixed Mita-san, this line was missing previously,
>> leading to "mode registers" being loaded but not the "pixel format
>> registers".
>
> This seems overly complicated to me. Why do we have to set the mode at power
> on time at all, why can't we do it at stream on time only, and simplify all
> this logic ?
>
I'm not the author of this driver, Steve do you know the origin and the
gain to do so ?
Anyway, I would prefer that we stabilize currently existing code before
going to larger changes.
>> PS: There are two other "set mode" related changes that are related to
>> this:
>> 1) 6949d864776e ("media: ov5640: do not change mode if format or
>> frame interval is unchanged")
>> => this is merged in media master,
[PATCH 2/2] vicodec: set state->info before calling the encode/decode funcs
From: Hans Verkuil
state->info was NULL since I completely forgot to set state->info.
Oops.
Reported-by: Ezequiel Garcia
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vicodec/vicodec-core.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index fdd77441a47b..5d42a8414283 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -176,12 +176,15 @@ static int device_process(struct vicodec_ctx *ctx,
}
if (ctx->is_enc) {
- unsigned int size = v4l2_fwht_encode(state, p_in, p_out);
-
- vb2_set_plane_payload(_vb->vb2_buf, 0, size);
+ state->info = q_out->info;
+ ret = v4l2_fwht_encode(state, p_in, p_out);
+ if (ret < 0)
+ return ret;
+ vb2_set_plane_payload(_vb->vb2_buf, 0, ret);
} else {
+ state->info = q_cap->info;
ret = v4l2_fwht_decode(state, p_in, p_out);
- if (ret)
+ if (ret < 0)
return ret;
vb2_set_plane_payload(_vb->vb2_buf, 0, q_cap->sizeimage);
}
--
2.18.0
[PATCH 1/2] vicodec: check for valid format in v4l2_fwht_en/decode
From: Hans Verkuil
These functions did not return an error if state->info was NULL
or an unsupported pixelformat was selected (should not happen,
but just to be on the safe side).
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vicodec/codec-v4l2-fwht.c | 15 +++
drivers/media/platform/vicodec/codec-v4l2-fwht.h | 7 ++-
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/vicodec/codec-v4l2-fwht.c
b/drivers/media/platform/vicodec/codec-v4l2-fwht.c
index cfcf84b8574d..1b86eb9868c3 100644
--- a/drivers/media/platform/vicodec/codec-v4l2-fwht.c
+++ b/drivers/media/platform/vicodec/codec-v4l2-fwht.c
@@ -51,8 +51,7 @@ const struct v4l2_fwht_pixfmt_info *v4l2_fwht_get_pixfmt(u32
idx)
return v4l2_fwht_pixfmts + idx;
}
-unsigned int v4l2_fwht_encode(struct v4l2_fwht_state *state,
- u8 *p_in, u8 *p_out)
+int v4l2_fwht_encode(struct v4l2_fwht_state *state, u8 *p_in, u8 *p_out)
{
unsigned int size = state->width * state->height;
const struct v4l2_fwht_pixfmt_info *info = state->info;
@@ -62,6 +61,8 @@ unsigned int v4l2_fwht_encode(struct v4l2_fwht_state *state,
u32 encoding;
u32 flags = 0;
+ if (!info)
+ return -EINVAL;
rf.width = state->width;
rf.height = state->height;
rf.luma = p_in;
@@ -137,6 +138,8 @@ unsigned int v4l2_fwht_encode(struct v4l2_fwht_state *state,
rf.cr = rf.cb + 2;
rf.luma++;
break;
+ default:
+ return -EINVAL;
}
cf.width = state->width;
@@ -180,8 +183,7 @@ unsigned int v4l2_fwht_encode(struct v4l2_fwht_state *state,
return cf.size + sizeof(*p_hdr);
}
-int v4l2_fwht_decode(struct v4l2_fwht_state *state,
-u8 *p_in, u8 *p_out)
+int v4l2_fwht_decode(struct v4l2_fwht_state *state, u8 *p_in, u8 *p_out)
{
unsigned int size = state->width * state->height;
unsigned int chroma_size = size;
@@ -191,6 +193,9 @@ int v4l2_fwht_decode(struct v4l2_fwht_state *state,
struct fwht_cframe cf;
u8 *p;
+ if (!state->info)
+ return -EINVAL;
+
p_hdr = (struct fwht_cframe_hdr *)p_in;
cf.width = ntohl(p_hdr->width);
cf.height = ntohl(p_hdr->height);
@@ -320,6 +325,8 @@ int v4l2_fwht_decode(struct v4l2_fwht_state *state,
*p++ = 0;
}
break;
+ default:
+ return -EINVAL;
}
return 0;
}
diff --git a/drivers/media/platform/vicodec/codec-v4l2-fwht.h
b/drivers/media/platform/vicodec/codec-v4l2-fwht.h
index 7794c186d905..22ae0e4d7315 100644
--- a/drivers/media/platform/vicodec/codec-v4l2-fwht.h
+++ b/drivers/media/platform/vicodec/codec-v4l2-fwht.h
@@ -41,10 +41,7 @@ struct v4l2_fwht_state {
const struct v4l2_fwht_pixfmt_info *v4l2_fwht_find_pixfmt(u32 pixelformat);
const struct v4l2_fwht_pixfmt_info *v4l2_fwht_get_pixfmt(u32 idx);
-unsigned int v4l2_fwht_encode(struct v4l2_fwht_state *state,
- u8 *p_in, u8 *p_out);
-
-int v4l2_fwht_decode(struct v4l2_fwht_state *state,
-u8 *p_in, u8 *p_out);
+int v4l2_fwht_encode(struct v4l2_fwht_state *state, u8 *p_in, u8 *p_out);
+int v4l2_fwht_decode(struct v4l2_fwht_state *state, u8 *p_in, u8 *p_out);
#endif
--
2.18.0
Re: [PATCH v2 4/5] media: ov5640: fix auto controls values when switching to manual mode
Hi Laurent,
On 09/10/2018 12:46 PM, Laurent Pinchart wrote:
> Hi Hugues,
>
> On Monday, 10 September 2018 13:23:41 EEST Hugues FRUCHET wrote:
>> On 09/06/2018 03:31 PM, Laurent Pinchart wrote:
>>> On Monday, 13 August 2018 13:19:45 EEST Hugues Fruchet wrote:
>>>
When switching from auto to manual mode, V4L2 core is calling
g_volatile_ctrl() in manual mode in order to get the manual initial
value. Remove the manual mode check/return to not break this behaviour.
Signed-off-by: Hugues Fruchet
---
drivers/media/i2c/ov5640.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 9fb17b5..c110a6a 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2277,16 +2277,12 @@ static int ov5640_g_volatile_ctrl(struct
v4l2_ctrl *ctrl)
switch (ctrl->id) {
case V4L2_CID_AUTOGAIN:
- if (!ctrl->val)
- return 0;
val = ov5640_get_gain(sensor);
if (val < 0)
return val;
sensor->ctrls.gain->val = val;
break;
>>>
>>> What is this even supposed to do ? Only the V4L2_CID_GAIN and
>>> V4L2_CID_EXPOSURE have the volatile flag set. Why can't this code be
>>> replaced with
>>
>> This is because V4L2_CID_AUTOGAIN & V4L2_CID_GAIN are declared as
>> auto-cluster:
>>static int ov5640_init_controls(struct ov5640_dev *sensor)
>> /* Auto/manual gain */
>> ctrls->auto_gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_AUTOGAIN,
>> 0, 1, 1, 1);
>> ctrls->gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAIN,
>> 0, 1023, 1, 0);
>> [...]
>> v4l2_ctrl_auto_cluster(2, >auto_gain, 0, true);
>>
>> By checking many other drivers that are using clustered auto controls,
>> they are all doing that way:
>>
>> ctrls->auto_x = v4l2_ctrl_new_std(CID_X_AUTO..
>> ctrls->x = v4l2_ctrl_new_std(CID_X..
>> v4l2_ctrl_auto_cluster(2, >auto, 0, true);
>>
>> g_volatile_ctrl(ctrl)
>> switch (ctrl->id) {
>> case CID_X_AUTO:
>>ctrls->x->val = READ_REG()
>
> Seems like cargo-cult to me. Why is this better than the construct below ?
>
I have done the changes as per your suggestion, but behaviour is broken:
when autogain control is on and I read gain value, gain is not refreshed
with current gain value from sensor, but stick to last manual value set.
Moreover I've checked in vivid how it is done and still we have the
structure of code I've already mentionned:
static int vivid_user_vid_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
{
struct vivid_dev *dev = container_of(ctrl->handler, struct vivid_dev,
ctrl_hdl_user_vid);
switch (ctrl->id) {
case V4L2_CID_AUTOGAIN:
dev->gain->val = dev->jiffies_vid_cap & 0xff;
break;
}
return 0;
}
>>> case V4L2_CID_GAIN:
>>> val = ov5640_get_gain(sensor);
>>> if (val < 0)
>>> return val;
>>> ctrl->val = val;
>>> break;
>>>
case V4L2_CID_EXPOSURE_AUTO:
- if (ctrl->val == V4L2_EXPOSURE_MANUAL)
- return 0;
val = ov5640_get_exposure(sensor);
if (val < 0)
return val;
>>>
>>> And same here.
>
BR Hugues.
Re: [PATCH v5 5/6] media: Add controls for JPEG quantization tables
Hi Hans, Thanks for the review. On Mon, 2018-09-10 at 14:42 +0200, Hans Verkuil wrote: > On 09/06/2018 12:00 AM, Ezequiel Garcia wrote: > > From: Shunqian Zheng > > > > Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace > > configure the JPEG quantization tables. > > > > Signed-off-by: Shunqian Zheng > > Signed-off-by: Ezequiel Garcia > > --- > > .../media/uapi/v4l/extended-controls.rst | 31 +++ > > .../media/videodev2.h.rst.exceptions | 1 + > > drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++ > > include/uapi/linux/v4l2-controls.h| 12 +++ > > include/uapi/linux/videodev2.h| 1 + > > 5 files changed, 55 insertions(+) > > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst > > b/Documentation/media/uapi/v4l/extended-controls.rst > > index 9f7312bf3365..1335d27d30f3 100644 > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > @@ -3354,7 +3354,38 @@ JPEG Control IDs > > Specify which JPEG markers are included in compressed stream. This > > control is valid only for encoders. > > > > +.. _jpeg-quant-tables-control: > > > > +``V4L2_CID_JPEG_QUANTIZATION (struct)`` > > +Specifies the luma and chroma quantization matrices for encoding > > +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The :ref:`itu-t81` > > +specification allows 8-bit quantization coefficients for > > +baseline profile images, and 8-bit or 16-bit for extended profile > > +images. Supporting or not 16-bit precision coefficients is > > driver-specific. > > +Coefficients must be set in JPEG zigzag scan order. > > + > > + > > +.. c:type:: struct v4l2_ctrl_jpeg_quantization > > + > > +.. cssclass:: longtable > > + > > +.. flat-table:: struct v4l2_ctrl_jpeg_quantization > > +:header-rows: 0 > > +:stub-columns: 0 > > +:widths: 1 1 2 > > + > > +* - __u8 > > + - ``precision`` > > + - Specifies the coefficient precision. User shall set 0 > > +for 8-bit, and 1 for 16-bit. > > So does specifying 1 here switch the HW encoder to use extended profile? > What if the HW only supports baseline? The rockchip driver doesn't appear > to check the precision field at all... > The driver is missing to check that, when the user sets this control. > I think this needs a bit more thought. > > I am not at all sure that this is the right place for the precision field. > This is really about JPEG profiles, so I would kind of expect a JPEG PROFILE > control (just like other codec profiles), or possibly a new pixelformat for > extended profiles. > > And based on that the driver would interpret these matrix values as 8 or > 16 bits. > Right, the JPEG profile control is definitely needed. I haven't add it because it wouldn't be used, since this VPU can only do baseline. However, the problem is that some JPEGs in the wild have with 8-bit data and 16-bit quantization coefficients, as per [1] and [2]: [1] https://github.com/martinhath/jpeg-rust/issues/1 [2] https://github.com/libjpeg-turbo/libjpeg-turbo/pull/90 So, in order to support decoding of these images, I've added the precision field to the quantization control. The user would be able to set a baseline or extended profile thru a (future) profile control, and if 16-bit tables are found, and if the hardware supports them, the driver would be able to support them. Another option, which might be even better, is have explicit baseline and extended quantization tables controls, e.g.: V4L2_CID_JPEG_QUANT and V4L2_CID_JPEG_EXT_QUANT. Thanks, Ezequiel
Re: [PATCH v5 5/6] media: Add controls for JPEG quantization tables
On 09/06/2018 12:00 AM, Ezequiel Garcia wrote: > From: Shunqian Zheng > > Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace > configure the JPEG quantization tables. > > Signed-off-by: Shunqian Zheng > Signed-off-by: Ezequiel Garcia > --- > .../media/uapi/v4l/extended-controls.rst | 31 +++ > .../media/videodev2.h.rst.exceptions | 1 + > drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++ > include/uapi/linux/v4l2-controls.h| 12 +++ > include/uapi/linux/videodev2.h| 1 + > 5 files changed, 55 insertions(+) > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst > b/Documentation/media/uapi/v4l/extended-controls.rst > index 9f7312bf3365..1335d27d30f3 100644 > --- a/Documentation/media/uapi/v4l/extended-controls.rst > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > @@ -3354,7 +3354,38 @@ JPEG Control IDs > Specify which JPEG markers are included in compressed stream. This > control is valid only for encoders. > > +.. _jpeg-quant-tables-control: > > +``V4L2_CID_JPEG_QUANTIZATION (struct)`` > +Specifies the luma and chroma quantization matrices for encoding > +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The :ref:`itu-t81` > +specification allows 8-bit quantization coefficients for > +baseline profile images, and 8-bit or 16-bit for extended profile > +images. Supporting or not 16-bit precision coefficients is > driver-specific. > +Coefficients must be set in JPEG zigzag scan order. > + > + > +.. c:type:: struct v4l2_ctrl_jpeg_quantization > + > +.. cssclass:: longtable > + > +.. flat-table:: struct v4l2_ctrl_jpeg_quantization > +:header-rows: 0 > +:stub-columns: 0 > +:widths: 1 1 2 > + > +* - __u8 > + - ``precision`` > + - Specifies the coefficient precision. User shall set 0 > +for 8-bit, and 1 for 16-bit. So does specifying 1 here switch the HW encoder to use extended profile? What if the HW only supports baseline? The rockchip driver doesn't appear to check the precision field at all... I think this needs a bit more thought. I am not at all sure that this is the right place for the precision field. This is really about JPEG profiles, so I would kind of expect a JPEG PROFILE control (just like other codec profiles), or possibly a new pixelformat for extended profiles. And based on that the driver would interpret these matrix values as 8 or 16 bits. Regards, Hans > + > +* - __u16 > + - ``luma_quantization_matrix[64]`` > + - Sets the luma quantization table. > + > +* - __u16 > + - ``chroma_quantization_matrix[64]`` > + - Sets the chroma quantization table. > > .. flat-table:: > :header-rows: 0 > diff --git a/Documentation/media/videodev2.h.rst.exceptions > b/Documentation/media/videodev2.h.rst.exceptions > index ca9f0edc579e..a0a38e92bf38 100644 > --- a/Documentation/media/videodev2.h.rst.exceptions > +++ b/Documentation/media/videodev2.h.rst.exceptions > @@ -129,6 +129,7 @@ replace symbol V4L2_CTRL_TYPE_STRING > :c:type:`v4l2_ctrl_type` > replace symbol V4L2_CTRL_TYPE_U16 :c:type:`v4l2_ctrl_type` > replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type` > replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type` > +replace symbol V4L2_CTRL_TYPE_JPEG_QUANTIZATION :c:type:`v4l2_ctrl_type` > > # V4L2 capability defines > replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c > b/drivers/media/v4l2-core/v4l2-ctrls.c > index 599c1cbff3b9..305bd7a9b7f1 100644 > --- a/drivers/media/v4l2-core/v4l2-ctrls.c > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c > @@ -999,6 +999,7 @@ const char *v4l2_ctrl_get_name(u32 id) > case V4L2_CID_JPEG_RESTART_INTERVAL:return "Restart Interval"; > case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality"; > case V4L2_CID_JPEG_ACTIVE_MARKER: return "Active Markers"; > + case V4L2_CID_JPEG_QUANTIZATION:return "JPEG Quantization > Tables"; > > /* Image source controls */ > /* Keep the order of the 'case's the same as in v4l2-controls.h! */ > @@ -1286,6 +1287,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum > v4l2_ctrl_type *type, > case V4L2_CID_DETECT_MD_REGION_GRID: > *type = V4L2_CTRL_TYPE_U8; > break; > + case V4L2_CID_JPEG_QUANTIZATION: > + *type = V4L2_CTRL_TYPE_JPEG_QUANTIZATION; > + break; > case V4L2_CID_DETECT_MD_THRESHOLD_GRID: > *type = V4L2_CTRL_TYPE_U16; > break; > @@ -1612,6 +1616,9 @@ static int std_validate(const struct v4l2_ctrl *ctrl, > u32 idx, > return -ERANGE; > return 0; > > + case V4L2_CTRL_TYPE_JPEG_QUANTIZATION: > + return 0; > + > default: > return -EINVAL; > } > @@ -2133,6 +2140,9 @@ static
[GIT PULL FOR v4.20] i.MX PXP scaler/CSC driver
Pull request for v3 of this new driver (https://www.spinics.net/lists/arm-kernel/msg674871.html). Regards, Hans The following changes since commit d842a7cf938b6e0f8a1aa9f1aec0476c9a599310: media: adv7842: enable reduced fps detection (2018-08-31 10:03:51 -0400) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git pxp for you to fetch changes up to e04f2b108133c628747df35e5be42e2faa0325f7: MAINTAINERS: add entry for i.MX PXP media mem2mem driver (2018-09-10 13:36:55 +0200) Philipp Zabel (3): dt-bindings: media: Add i.MX Pixel Pipeline binding media: imx-pxp: add i.MX Pixel Pipeline driver MAINTAINERS: add entry for i.MX PXP media mem2mem driver Documentation/devicetree/bindings/media/fsl-pxp.txt | 26 + MAINTAINERS |7 + drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile |2 + drivers/media/platform/imx-pxp.c| 1752 +++ drivers/media/platform/imx-pxp.h| 1685 + 6 files changed, 3481 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/fsl-pxp.txt create mode 100644 drivers/media/platform/imx-pxp.c create mode 100644 drivers/media/platform/imx-pxp.h
[PATCH 2/3] media: replace strcpy() by strscpy()
The strcpy() function is being deprecated upstream. Replace it by the safer strscpy(). Signed-off-by: Mauro Carvalho Chehab --- drivers/media/common/saa7146/saa7146_video.c | 2 +- drivers/media/dvb-core/dvb_frontend.c | 2 +- drivers/media/dvb-frontends/mt312.c | 9 --- drivers/media/dvb-frontends/zl10039.c | 5 ++-- drivers/media/firewire/firedtv-fe.c | 2 +- drivers/media/i2c/ad5820.c| 2 +- drivers/media/i2c/lm3560.c| 3 ++- drivers/media/i2c/lm3646.c| 3 ++- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +- drivers/media/i2c/sr030pc30.c | 2 +- drivers/media/pci/bt8xx/bttv-driver.c | 4 +-- drivers/media/pci/cx23885/cx23885-417.c | 2 +- drivers/media/pci/cx23885/cx23885-alsa.c | 4 +-- drivers/media/pci/cx23885/cx23885-video.c | 11 drivers/media/pci/cx25821/cx25821-alsa.c | 8 +++--- drivers/media/pci/cx25821/cx25821-video.c | 6 ++--- drivers/media/pci/cx88/cx88-alsa.c| 6 ++--- drivers/media/pci/cx88/cx88-blackbird.c | 4 +-- drivers/media/pci/cx88/cx88-cards.c | 2 +- drivers/media/pci/cx88/cx88-video.c | 8 +++--- drivers/media/pci/dm1105/dm1105.c | 5 ++-- drivers/media/pci/dt3155/dt3155.c | 6 ++--- drivers/media/pci/meye/meye.c | 10 drivers/media/pci/ngene/ngene-i2c.c | 2 +- drivers/media/pci/pluto2/pluto2.c | 3 ++- drivers/media/pci/pt1/pt1.c | 2 +- drivers/media/pci/saa7134/saa7134-alsa.c | 8 +++--- drivers/media/pci/saa7134/saa7134-i2c.c | 2 +- drivers/media/pci/saa7134/saa7134-video.c | 9 --- drivers/media/pci/saa7164/saa7164-core.c | 2 +- drivers/media/pci/saa7164/saa7164-encoder.c | 6 ++--- drivers/media/pci/saa7164/saa7164-vbi.c | 2 +- drivers/media/pci/smipcie/smipcie-main.c | 4 +-- drivers/media/pci/solo6x10/solo6x10-g723.c| 8 +++--- .../media/pci/solo6x10/solo6x10-v4l2-enc.c| 13 ++ drivers/media/pci/solo6x10/solo6x10-v4l2.c| 4 +-- drivers/media/pci/sta2x11/sta2x11_vip.c | 6 ++--- drivers/media/pci/ttpci/av7110_v4l.c | 2 +- drivers/media/pci/ttpci/budget-core.c | 3 ++- drivers/media/pci/tw5864/tw5864-video.c | 2 +- drivers/media/pci/tw68/tw68-video.c | 2 +- drivers/media/platform/am437x/am437x-vpfe.c | 3 ++- drivers/media/platform/atmel/atmel-isc.c | 6 ++--- drivers/media/platform/davinci/vpbe_display.c | 6 +++-- drivers/media/platform/davinci/vpbe_venc.c| 2 +- drivers/media/platform/davinci/vpif_capture.c | 6 +++-- drivers/media/platform/davinci/vpif_display.c | 3 ++- drivers/media/platform/fsl-viu.c | 8 +++--- .../media/platform/marvell-ccic/cafe-driver.c | 2 +- .../media/platform/marvell-ccic/mcam-core.c | 6 ++--- .../media/platform/soc_camera/soc_camera.c| 2 +- drivers/media/platform/via-camera.c | 6 ++--- drivers/media/platform/vivid/vivid-cec.c | 4 +-- drivers/media/platform/vivid/vivid-core.c | 4 +-- drivers/media/radio/dsbr100.c | 2 +- drivers/media/radio/radio-ma901.c | 2 +- drivers/media/radio/radio-mr800.c | 2 +- .../media/radio/si470x/radio-si470x-common.c | 2 +- drivers/media/radio/wl128x/fmdrv_v4l2.c | 4 +-- drivers/media/rc/imon.c | 4 +-- drivers/media/usb/au0828/au0828-video.c | 18 ++--- drivers/media/usb/cpia2/cpia2_v4l.c | 12 - drivers/media/usb/cx231xx/cx231xx-audio.c | 9 --- drivers/media/usb/cx231xx/cx231xx-video.c | 9 --- drivers/media/usb/em28xx/em28xx-audio.c | 8 +++--- drivers/media/usb/em28xx/em28xx-i2c.c | 3 ++- drivers/media/usb/em28xx/em28xx-video.c | 22 drivers/media/usb/hdpvr/hdpvr-video.c | 7 +++--- drivers/media/usb/pulse8-cec/pulse8-cec.c | 3 ++- drivers/media/usb/pwc/pwc-if.c| 2 +- drivers/media/usb/pwc/pwc-v4l.c | 2 +- .../media/usb/rainshadow-cec/rainshadow-cec.c | 3 ++- drivers/media/usb/stk1160/stk1160-i2c.c | 2 +- drivers/media/usb/stk1160/stk1160-v4l.c | 4 +-- drivers/media/usb/stkwebcam/stk-webcam.c | 21 ++-- drivers/media/usb/tm6000/tm6000-alsa.c| 6 ++--- drivers/media/usb/tm6000/tm6000-video.c | 6 ++--- .../media/usb/ttusb-budget/dvb-ttusb-budget.c | 3 ++- drivers/media/usb/usbvision/usbvision-video.c | 25 +++ drivers/media/usb/uvc/uvc_driver.c| 2 +- drivers/media/usb/zr364xx/zr364xx.c | 4 +-- .../media/davinci_vpfe/vpfe_mc_capture.c | 3 ++- drivers/staging/media/imx/imx6-mipi-csi2.c| 2 +- drivers/staging/media/zoran/zoran_card.c | 3 ++- 84 files changed, 240 insertions(+), 201 deletions(-)
[PATCH 0/3] Use only strscpy() for string copy
There are hot discussions upstream about getting rid of strcpy(), strncpy() and strlcpy() in favor of the safer strscpy(). While there are exceptions where strscpy() may not be the best option (for example, when filling records with fixed size), we don't have those situations right now on media. On all cases, all the core and drivers are doing are filling some var with a name. So, we can switch all such functions by strscpy(). Mauro Carvalho Chehab (3): media: use strscpy() instead of strlcpy() media: replace strcpy() by strscpy() media: replace strncpy() by strscpy() drivers/media/cec/cec-api.c | 4 +- drivers/media/cec/cec-core.c | 2 +- drivers/media/common/b2c2/flexcop-i2c.c | 12 ++--- drivers/media/common/cx2341x.c| 2 +- drivers/media/common/saa7146/saa7146_fops.c | 2 +- drivers/media/common/saa7146/saa7146_video.c | 8 +-- drivers/media/common/siano/smscoreapi.c | 4 +- drivers/media/common/siano/smsir.c| 2 +- drivers/media/dvb-core/dvb_frontend.c | 2 +- drivers/media/dvb-core/dvb_vb2.c | 2 +- drivers/media/dvb-core/dvbdev.c | 4 +- drivers/media/dvb-frontends/as102_fe.c| 2 +- drivers/media/dvb-frontends/cx24123.c | 2 +- drivers/media/dvb-frontends/cxd2820r_core.c | 2 +- drivers/media/dvb-frontends/dib7000p.c| 3 +- drivers/media/dvb-frontends/dib8000.c | 4 +- drivers/media/dvb-frontends/dib9000.c | 6 ++- drivers/media/dvb-frontends/dibx000_common.c | 2 +- drivers/media/dvb-frontends/dvb-pll.c | 2 +- drivers/media/dvb-frontends/lgdt330x.c| 2 +- drivers/media/dvb-frontends/m88ds3103.c | 4 +- drivers/media/dvb-frontends/mt312.c | 9 ++-- drivers/media/dvb-frontends/rtl2832_sdr.c | 10 ++-- drivers/media/dvb-frontends/s5h1420.c | 2 +- drivers/media/dvb-frontends/tc90522.c | 2 +- drivers/media/dvb-frontends/ts2020.c | 2 +- drivers/media/dvb-frontends/zd1301_demod.c| 3 +- drivers/media/dvb-frontends/zl10039.c | 5 +- drivers/media/firewire/firedtv-fe.c | 2 +- drivers/media/i2c/ad5820.c| 2 +- drivers/media/i2c/cs53l32a.c | 2 +- drivers/media/i2c/imx274.c| 2 +- drivers/media/i2c/lm3560.c| 3 +- drivers/media/i2c/lm3646.c| 3 +- drivers/media/i2c/m5mols/m5mols_core.c| 2 +- drivers/media/i2c/max2175.c | 2 +- drivers/media/i2c/msp3400-driver.c| 2 +- drivers/media/i2c/noon010pc30.c | 2 +- drivers/media/i2c/ov9650.c| 2 +- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 4 +- drivers/media/i2c/s5k4ecgx.c | 2 +- drivers/media/i2c/s5k6aa.c| 2 +- drivers/media/i2c/saa7115.c | 6 +-- drivers/media/i2c/saa7127.c | 4 +- drivers/media/i2c/sr030pc30.c | 2 +- drivers/media/i2c/tvaudio.c | 2 +- drivers/media/i2c/video-i2c.c | 8 +-- drivers/media/media-device.c | 28 +- drivers/media/pci/bt8xx/bttv-driver.c | 10 ++-- drivers/media/pci/bt8xx/bttv-i2c.c| 6 +-- drivers/media/pci/bt8xx/bttv-input.c | 2 +- drivers/media/pci/bt8xx/dst.c | 3 +- drivers/media/pci/bt8xx/dvb-bt8xx.c | 3 +- drivers/media/pci/cobalt/cobalt-alsa-main.c | 2 +- drivers/media/pci/cobalt/cobalt-alsa-pcm.c| 4 +- drivers/media/pci/cobalt/cobalt-v4l2.c| 14 ++--- drivers/media/pci/cx18/cx18-alsa-main.c | 2 +- drivers/media/pci/cx18/cx18-alsa-pcm.c| 2 +- drivers/media/pci/cx18/cx18-cards.c | 8 +-- drivers/media/pci/cx18/cx18-driver.c | 2 +- drivers/media/pci/cx18/cx18-i2c.c | 2 +- drivers/media/pci/cx18/cx18-ioctl.c | 8 +-- drivers/media/pci/cx23885/cx23885-417.c | 8 +-- drivers/media/pci/cx23885/cx23885-alsa.c | 4 +- drivers/media/pci/cx23885/cx23885-dvb.c | 54 +-- drivers/media/pci/cx23885/cx23885-i2c.c | 4 +- drivers/media/pci/cx23885/cx23885-ioctl.c | 4 +- drivers/media/pci/cx23885/cx23885-video.c | 15 +++--- drivers/media/pci/cx25821/cx25821-alsa.c | 8 +-- drivers/media/pci/cx25821/cx25821-i2c.c | 2 +- drivers/media/pci/cx25821/cx25821-video.c | 10 ++-- drivers/media/pci/cx88/cx88-alsa.c| 6 +-- drivers/media/pci/cx88/cx88-blackbird.c | 6 +-- drivers/media/pci/cx88/cx88-cards.c | 2 +- drivers/media/pci/cx88/cx88-i2c.c | 4 +- drivers/media/pci/cx88/cx88-input.c | 4 +- drivers/media/pci/cx88/cx88-video.c | 12 ++--- drivers/media/pci/cx88/cx88-vp3054-i2c.c | 2 +- drivers/media/pci/dm1105/dm1105.c | 5 +-
[PATCH 3/3] media: replace strncpy() by strscpy()
The strncpy() function is being deprecated upstream. Replace it by the safer strscpy(). Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb-frontends/as102_fe.c | 2 +- drivers/media/dvb-frontends/dib7000p.c | 3 ++- drivers/media/dvb-frontends/dib8000.c| 4 ++-- drivers/media/dvb-frontends/dib9000.c| 6 -- drivers/media/dvb-frontends/dvb-pll.c| 2 +- drivers/media/dvb-frontends/m88ds3103.c | 2 +- drivers/media/pci/bt8xx/dst.c| 3 ++- drivers/media/pci/mantis/mantis_i2c.c| 2 +- drivers/media/pci/saa7134/saa7134-go7007.c | 2 +- drivers/media/platform/am437x/am437x-vpfe.c | 2 +- drivers/media/platform/davinci/vpfe_capture.c| 2 +- drivers/media/platform/davinci/vpif_capture.c| 2 +- drivers/media/platform/davinci/vpif_display.c| 3 +-- drivers/media/platform/exynos4-is/fimc-capture.c | 2 +- drivers/media/platform/exynos4-is/fimc-m2m.c | 2 +- drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +- drivers/media/platform/mx2_emmaprp.c | 4 ++-- drivers/media/platform/s5p-g2d/g2d.c | 6 +++--- drivers/media/platform/ti-vpe/vpe.c | 6 +++--- drivers/media/platform/vicodec/vicodec-core.c| 4 ++-- drivers/media/platform/vim2m.c | 4 ++-- drivers/media/radio/si4713/si4713.c | 2 +- drivers/media/usb/go7007/go7007-usb.c| 16 drivers/media/usb/go7007/go7007-v4l2.c | 2 +- drivers/media/usb/hdpvr/hdpvr-video.c| 9 +++-- drivers/media/usb/pulse8-cec/pulse8-cec.c| 4 ++-- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 2 +- drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 4 ++-- drivers/staging/media/bcm2048/radio-bcm2048.c| 4 ++-- drivers/staging/media/imx/imx-ic-common.c| 2 +- drivers/staging/media/imx/imx-media-vdic.c | 2 +- drivers/staging/media/zoran/zoran_driver.c | 10 +- 32 files changed, 61 insertions(+), 61 deletions(-) diff --git a/drivers/media/dvb-frontends/as102_fe.c b/drivers/media/dvb-frontends/as102_fe.c index f59a102b0a64..9ba8f39fe310 100644 --- a/drivers/media/dvb-frontends/as102_fe.c +++ b/drivers/media/dvb-frontends/as102_fe.c @@ -467,7 +467,7 @@ struct dvb_frontend *as102_attach(const char *name, /* init frontend callback ops */ memcpy(>ops, _fe_ops, sizeof(struct dvb_frontend_ops)); - strncpy(fe->ops.info.name, name, sizeof(fe->ops.info.name)); + strscpy(fe->ops.info.name, name, sizeof(fe->ops.info.name)); return fe; diff --git a/drivers/media/dvb-frontends/dib7000p.c b/drivers/media/dvb-frontends/dib7000p.c index 58387860b62d..d8cfdb4ce16e 100644 --- a/drivers/media/dvb-frontends/dib7000p.c +++ b/drivers/media/dvb-frontends/dib7000p.c @@ -2771,7 +2771,8 @@ static struct dvb_frontend *dib7000p_init(struct i2c_adapter *i2c_adap, u8 i2c_a dibx000_init_i2c_master(>i2c_master, DIB7000P, st->i2c_adap, st->i2c_addr); /* init 7090 tuner adapter */ - strncpy(st->dib7090_tuner_adap.name, "DiB7090 tuner interface", sizeof(st->dib7090_tuner_adap.name)); + strscpy(st->dib7090_tuner_adap.name, "DiB7090 tuner interface", + sizeof(st->dib7090_tuner_adap.name)); st->dib7090_tuner_adap.algo = _tuner_xfer_algo; st->dib7090_tuner_adap.algo_data = NULL; st->dib7090_tuner_adap.dev.parent = st->i2c_adap->dev.parent; diff --git a/drivers/media/dvb-frontends/dib8000.c b/drivers/media/dvb-frontends/dib8000.c index 3c3f8cb14845..286f8000b445 100644 --- a/drivers/media/dvb-frontends/dib8000.c +++ b/drivers/media/dvb-frontends/dib8000.c @@ -4458,8 +4458,8 @@ static struct dvb_frontend *dib8000_init(struct i2c_adapter *i2c_adap, u8 i2c_ad dibx000_init_i2c_master(>i2c_master, DIB8000, state->i2c.adap, state->i2c.addr); /* init 8096p tuner adapter */ - strncpy(state->dib8096p_tuner_adap.name, "DiB8096P tuner interface", - sizeof(state->dib8096p_tuner_adap.name)); + strscpy(state->dib8096p_tuner_adap.name, "DiB8096P tuner interface", + sizeof(state->dib8096p_tuner_adap.name)); state->dib8096p_tuner_adap.algo = _tuner_xfer_algo; state->dib8096p_tuner_adap.algo_data = NULL; state->dib8096p_tuner_adap.dev.parent = state->i2c.adap->dev.parent; diff --git a/drivers/media/dvb-frontends/dib9000.c b/drivers/media/dvb-frontends/dib9000.c index 0183fb1346ef..c986687def30 100644 --- a/drivers/media/dvb-frontends/dib9000.c +++ b/drivers/media/dvb-frontends/dib9000.c @@ -2521,7 +2521,8 @@ struct dvb_frontend *dib9000_attach(struct i2c_adapter *i2c_adap, u8 i2c_addr, c dibx000_init_i2c_master(>i2c_master, DIB7000MC, st->i2c.i2c_adap, st->i2c.i2c_addr); st->tuner_adap.dev.parent = i2c_adap->dev.parent; - strncpy(st->tuner_adap.name, "DIB9000_FW TUNER ACCESS",
3% Loan Offer Apply Now
ARE YOU IN NEED OF LOAN @3% INTEREST RATE FOR BUSINESS AND PRIVATE PURPOSES? IF YES: FILL AND RETURN Name:=== Amount needed:=== Duration:== country:=== Purpose:=== Mobile number
Re: [PATCH v2 4/5] media: ov5640: fix auto controls values when switching to manual mode
Hi Hugues,
On Monday, 10 September 2018 13:23:41 EEST Hugues FRUCHET wrote:
> On 09/06/2018 03:31 PM, Laurent Pinchart wrote:
> > On Monday, 13 August 2018 13:19:45 EEST Hugues Fruchet wrote:
> >
> >> When switching from auto to manual mode, V4L2 core is calling
> >> g_volatile_ctrl() in manual mode in order to get the manual initial
> >> value. Remove the manual mode check/return to not break this behaviour.
> >>
> >> Signed-off-by: Hugues Fruchet
> >> ---
> >> drivers/media/i2c/ov5640.c | 4
> >> 1 file changed, 4 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> >> index 9fb17b5..c110a6a 100644
> >> --- a/drivers/media/i2c/ov5640.c
> >> +++ b/drivers/media/i2c/ov5640.c
> >> @@ -2277,16 +2277,12 @@ static int ov5640_g_volatile_ctrl(struct
> >> v4l2_ctrl *ctrl)
> >>
> >>switch (ctrl->id) {
> >>case V4L2_CID_AUTOGAIN:
> >> - if (!ctrl->val)
> >> - return 0;
> >>
> >>val = ov5640_get_gain(sensor);
> >>if (val < 0)
> >>return val;
> >>
> >>sensor->ctrls.gain->val = val;
> >>break;
> >
> > What is this even supposed to do ? Only the V4L2_CID_GAIN and
> > V4L2_CID_EXPOSURE have the volatile flag set. Why can't this code be
> > replaced with
>
> This is because V4L2_CID_AUTOGAIN & V4L2_CID_GAIN are declared as
> auto-cluster:
> static int ov5640_init_controls(struct ov5640_dev *sensor)
> /* Auto/manual gain */
> ctrls->auto_gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_AUTOGAIN,
>0, 1, 1, 1);
> ctrls->gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAIN,
> 0, 1023, 1, 0);
> [...]
> v4l2_ctrl_auto_cluster(2, >auto_gain, 0, true);
>
> By checking many other drivers that are using clustered auto controls,
> they are all doing that way:
>
> ctrls->auto_x = v4l2_ctrl_new_std(CID_X_AUTO..
> ctrls->x = v4l2_ctrl_new_std(CID_X..
> v4l2_ctrl_auto_cluster(2, >auto, 0, true);
>
> g_volatile_ctrl(ctrl)
>switch (ctrl->id) {
> case CID_X_AUTO:
> ctrls->x->val = READ_REG()
Seems like cargo-cult to me. Why is this better than the construct below ?
> > case V4L2_CID_GAIN:
> > val = ov5640_get_gain(sensor);
> > if (val < 0)
> > return val;
> > ctrl->val = val;
> > break;
> >
> >>case V4L2_CID_EXPOSURE_AUTO:
> >> - if (ctrl->val == V4L2_EXPOSURE_MANUAL)
> >> - return 0;
> >>val = ov5640_get_exposure(sensor);
> >>if (val < 0)
> >>return val;
> >
> > And same here.
--
Regards,
Laurent Pinchart
3% Loan Offer Apply Now
ARE YOU IN NEED OF LOAN @3% INTEREST RATE FOR BUSINESS AND PRIVATE PURPOSES? IF YES: FILL AND RETURN Name:=== Amount needed:=== Duration:== country:=== Purpose:=== Mobile number
Re: [PATCH v3 1/2] media: dt-bindings: bind nokia,n900-ir to generic pwm-ir-tx driver
On Fri, Aug 31, 2018 at 11:07:23AM +0300, Sakari Ailus wrote:
> Hi Sean,
>
> On Fri, Jul 13, 2018 at 01:22:29PM +0100, Sean Young wrote:
> > The generic pwm-ir-tx driver should work for the Nokia n900.
> >
> > Compile tested only.
> >
> > Cc: Rob Herring
> > Cc: Ivaylo Dimitrov
> > Cc: Pali Rohár
> > Cc: Pavel Machek
> > Cc: Timo Kokkonen
> > Cc: Tony Lindgren
> > Signed-off-by: Sean Young
> > ---
> > arch/arm/boot/dts/omap3-n900.dts | 2 +-
> > drivers/media/rc/pwm-ir-tx.c | 1 +
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/omap3-n900.dts
> > b/arch/arm/boot/dts/omap3-n900.dts
> > index 182a53991c90..fd12dea15799 100644
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -154,7 +154,7 @@
> > };
> >
> > ir: n900-ir {
> > - compatible = "nokia,n900-ir";
> > + compatible = "nokia,n900-ir", "pwm-ir-tx";
> > pwms = < 0 26316 0>; /* 38000 Hz */
> > };
> >
> > diff --git a/drivers/media/rc/pwm-ir-tx.c b/drivers/media/rc/pwm-ir-tx.c
> > index 27d0f5837a76..272947b430c8 100644
> > --- a/drivers/media/rc/pwm-ir-tx.c
> > +++ b/drivers/media/rc/pwm-ir-tx.c
> > @@ -30,6 +30,7 @@ struct pwm_ir {
> > };
> >
> > static const struct of_device_id pwm_ir_of_match[] = {
> > + { .compatible = "nokia,n900-ir" },
>
> Is this change needed as well? I suppose you could add it later if there's
> a need to e.g. do something differently for the N900 IR transmitter.
This is to ensure compatibility of a new kernel with an old board dtb.
> It'd be nice if someone tested it, too...
That would be nice, but I don't have the hardware and so far I there has
been noone willing/able to test it.
Sean
Re: [PATCH v2 4/5] media: ov5640: fix auto controls values when switching to manual mode
Hi Laurent,
On 09/06/2018 03:31 PM, Laurent Pinchart wrote:
> Hi Hugues,
>
> Thank you for the patch.
>
> On Monday, 13 August 2018 13:19:45 EEST Hugues Fruchet wrote:
>> When switching from auto to manual mode, V4L2 core is calling
>> g_volatile_ctrl() in manual mode in order to get the manual initial value.
>> Remove the manual mode check/return to not break this behaviour.
>>
>> Signed-off-by: Hugues Fruchet
>> ---
>> drivers/media/i2c/ov5640.c | 4
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
>> index 9fb17b5..c110a6a 100644
>> --- a/drivers/media/i2c/ov5640.c
>> +++ b/drivers/media/i2c/ov5640.c
>> @@ -2277,16 +2277,12 @@ static int ov5640_g_volatile_ctrl(struct v4l2_ctrl
>> *ctrl)
>>
>> switch (ctrl->id) {
>> case V4L2_CID_AUTOGAIN:
>> -if (!ctrl->val)
>> -return 0;
>> val = ov5640_get_gain(sensor);
>> if (val < 0)
>> return val;
>> sensor->ctrls.gain->val = val;
>> break;
>
> What is this even supposed to do ? Only the V4L2_CID_GAIN and
> V4L2_CID_EXPOSURE have the volatile flag set. Why can't this code be replaced
> with
This is because V4L2_CID_AUTOGAIN & V4L2_CID_GAIN are declared as
auto-cluster:
static int ov5640_init_controls(struct ov5640_dev *sensor)
/* Auto/manual gain */
ctrls->auto_gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_AUTOGAIN,
0, 1, 1, 1);
ctrls->gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAIN,
0, 1023, 1, 0);
[...]
v4l2_ctrl_auto_cluster(2, >auto_gain, 0, true);
By checking many other drivers that are using clustered auto controls,
they are all doing that way:
ctrls->auto_x = v4l2_ctrl_new_std(CID_X_AUTO..
ctrls->x = v4l2_ctrl_new_std(CID_X..
v4l2_ctrl_auto_cluster(2, >auto, 0, true);
g_volatile_ctrl(ctrl)
switch (ctrl->id) {
case CID_X_AUTO:
ctrls->x->val = READ_REG()
>
> case V4L2_CID_GAIN:
> val = ov5640_get_gain(sensor);
> if (val < 0)
> return val;
> ctrl->val = val;
> break;
>
>
>> case V4L2_CID_EXPOSURE_AUTO:
>> -if (ctrl->val == V4L2_EXPOSURE_MANUAL)
>> -return 0;
>> val = ov5640_get_exposure(sensor);
>> if (val < 0)
>> return val;
>
> And same here.
>
Best regards,
Hugues.
[GIT PULL FOR v4.20 (request_api branch)] Add Allwinner cedrus decoder driver
Hi Mauro, This is the cedrus Allwinner decoder driver. It is for the request_api topic branch, but it assumes that this pull request is applied first: https://patchwork.linuxtv.org/patch/51889/ The last two patches could optionally be squashed with the main driver patch: they fix COMPILE_TEST issues. I decided not to squash them and leave the choice to you. This won't fully fix the COMPILE_TEST problems, for that another patch is needed: https://lore.kernel.org/patchwork/patch/983848/ But that's going through another subsystem. Many, many thanks go to Paul for working on this, trying to keep up to date with the Request API changes at the same time. It was a pleasure working with you on this! Regards, Hans The following changes since commit 051dfd971de1317626d322581546257b748ebde1: media-request: update documentation (2018-09-04 11:34:57 +0200) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git cedrus for you to fetch changes up to e035b190fac3735e5f9d3c96cee5afc82aa1a94d: media: cedrus: Select the sunxi SRAM driver in Kconfig (2018-09-10 10:22:07 +0200) Paul Kocialkowski (13): media: videobuf2-core: Rework and rename helper for request buffer count media: v4l: Add definitions for MPEG-2 slice format and metadata media: v4l: Add definition for the Sunxi tiled NV12 format dt-bindings: media: Document bindings for the Cedrus VPU driver media: platform: Add Cedrus VPU decoder driver ARM: dts: sun5i: Add Video Engine and reserved memory nodes ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes ARM: dts: sun8i-a33: Add Video Engine and reserved memory nodes ARM: dts: sun8i-h3: Add Video Engine and reserved memory nodes media: cedrus: Fix error reporting in request validation media: cedrus: Add TODO file with tasks to complete before unstaging media: cedrus: Wrap PHYS_PFN_OFFSET with ifdef and add dedicated comment media: cedrus: Select the sunxi SRAM driver in Kconfig Documentation/devicetree/bindings/media/cedrus.txt | 54 + Documentation/media/uapi/v4l/extended-controls.rst | 176 Documentation/media/uapi/v4l/pixfmt-compressed.rst | 16 ++ Documentation/media/uapi/v4l/pixfmt-reserved.rst | 15 +- Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 14 +- Documentation/media/videodev2.h.rst.exceptions | 2 + MAINTAINERS| 7 + arch/arm/boot/dts/sun5i.dtsi | 26 +++ arch/arm/boot/dts/sun7i-a20.dtsi | 26 +++ arch/arm/boot/dts/sun8i-a33.dtsi | 26 +++ arch/arm/boot/dts/sun8i-h3.dtsi| 25 +++ drivers/media/common/videobuf2/videobuf2-core.c| 18 +- drivers/media/common/videobuf2/videobuf2-v4l2.c| 2 +- drivers/media/v4l2-core/v4l2-ctrls.c | 63 ++ drivers/media/v4l2-core/v4l2-ioctl.c | 2 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile | 1 + drivers/staging/media/sunxi/Kconfig| 15 ++ drivers/staging/media/sunxi/Makefile | 1 + drivers/staging/media/sunxi/cedrus/Kconfig | 14 ++ drivers/staging/media/sunxi/cedrus/Makefile| 3 + drivers/staging/media/sunxi/cedrus/TODO| 7 + drivers/staging/media/sunxi/cedrus/cedrus.c| 431 +++ drivers/staging/media/sunxi/cedrus/cedrus.h| 165 +++ drivers/staging/media/sunxi/cedrus/cedrus_dec.c| 70 +++ drivers/staging/media/sunxi/cedrus/cedrus_dec.h| 27 +++ drivers/staging/media/sunxi/cedrus/cedrus_hw.c | 327 + drivers/staging/media/sunxi/cedrus/cedrus_hw.h | 30 +++ drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c | 237 + drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 233 + drivers/staging/media/sunxi/cedrus/cedrus_video.c | 544 + drivers/staging/media/sunxi/cedrus/cedrus_video.h | 30 +++ include/media/v4l2-ctrls.h | 18 +- include/media/videobuf2-core.h | 4 +- include/uapi/linux/v4l2-controls.h | 65 ++ include/uapi/linux/videodev2.h | 6 + 36 files changed, 2679 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/cedrus.txt create mode 100644 drivers/staging/media/sunxi/Kconfig create mode 100644 drivers/staging/media/sunxi/Makefile create mode 100644 drivers/staging/media/sunxi/cedrus/Kconfig create mode 100644 drivers/staging/media/sunxi/cedrus/Makefile create mode 100644 drivers/staging/media/sunxi/cedrus/TODO create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus.c
