Re: [PATCH] cx231xx: correctly handling failed allocation

[Devin Heitmueller]

On Tue, Dec 29, 2015 at 1:53 PM, Insu Yun  wrote:
> Since kmalloc can be failed in memory pressure,
> if not properly handled, NULL dereference can be happend
>
> Signed-off-by: Insu Yun 
> ---
>  drivers/media/usb/cx231xx/cx231xx-417.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c 
> b/drivers/media/usb/cx231xx/cx231xx-417.c
> index 47a98a2..9725e4f 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-417.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-417.c
> @@ -1382,6 +1382,8 @@ static int cx231xx_bulk_copy(struct cx231xx *dev, 
> struct urb *urb)
> buffer_size = urb->actual_length;
>
> buffer = kmalloc(buffer_size, GFP_ATOMIC);
> +   if (!buffer)
> +   return -ENOMEM;

A kmalloc() call inside a bulk handler running in softirq context?
That doesn't look right.

That said, I don't have any specific objection to the patch (which I'm
assuming came from some automated tool), but I suspect the cx231xx-417
code is probably completely broken.  The only device I've ever seen
that has the cx23102 and cx23417 is one of the Polaris EVKs, which
AFAIK nobody has ever shipped a production design based on.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] cx231xx: correctly handling failed allocation

[Insu Yun]

Since kmalloc can be failed in memory pressure, 
if not properly handled, NULL dereference can be happend

Signed-off-by: Insu Yun 
---
 drivers/media/usb/cx231xx/cx231xx-417.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c 
b/drivers/media/usb/cx231xx/cx231xx-417.c
index 47a98a2..9725e4f 100644
--- a/drivers/media/usb/cx231xx/cx231xx-417.c
+++ b/drivers/media/usb/cx231xx/cx231xx-417.c
@@ -1382,6 +1382,8 @@ static int cx231xx_bulk_copy(struct cx231xx *dev, struct 
urb *urb)
buffer_size = urb->actual_length;
 
buffer = kmalloc(buffer_size, GFP_ATOMIC);
+   if (!buffer)
+   return -ENOMEM;
 
memcpy(buffer, dma_q->ps_head, 3);
memcpy(buffer+3, p_buffer, buffer_size-3);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] cx88-dvb: Changed tuner associated with board Hauppauge HVR-4000 from TUNER_PHILIPS_FMD1216ME_MK3 to TUNER_PHILIPS_FMD1216MEX_MK3

[José David Moreno Juárez]

The correct tuner for the board Hauppauge HVR-4000 seems to be FMD1216MEX MK3 
instead of FMD1216ME MK3. The tuner is identified as such by tveeprom:
Dec 28 23:01:15 [kernel] tveeprom 8-0050: tuner model is Philips 
FMD1216MEX (idx 133, type 78)

This patch fixes a longstanding warning message issued by tuner-simple:
Dec 28 23:01:15 [kernel] tuner-simple 8-0061: couldn't set type to 63. 
Using 78 (Philips FMD1216MEX MK3 Hybrid Tuner) instead

It has been successfully tested against kernel 4.1.12.



Signed-off-by: José David Moreno Juárez 
---
 drivers/media/pci/cx88/cx88-dvb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/cx88/cx88-dvb.c b/drivers/media/pci/cx88/cx88-
dvb.c
index afb2075..ac2ad00 100644
--- a/drivers/media/pci/cx88/cx88-dvb.c
+++ b/drivers/media/pci/cx88/cx88-dvb.c
@@ -1474,7 +1474,7 @@ static int dvb_register(struct cx8802_dev *dev)
if (!dvb_attach(simple_tuner_attach,
fe1->dvb.frontend,
>core->i2c_adap,
-   0x61, TUNER_PHILIPS_FMD1216ME_MK3))
+   0x61, TUNER_PHILIPS_FMD1216MEX_MK3))
goto frontend_detach;
}
break;
-- 
2.4.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usbtv: correctly handling failed allocation

[Insu Yun]

Since kzalloc can be failed, 
if not properly handled, NULL dereference could be happened.

Signed-off-by: Insu Yun 
---
 drivers/media/usb/usbtv/usbtv-video.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/usb/usbtv/usbtv-video.c 
b/drivers/media/usb/usbtv/usbtv-video.c
index e645c9d..92d8d7a 100644
--- a/drivers/media/usb/usbtv/usbtv-video.c
+++ b/drivers/media/usb/usbtv/usbtv-video.c
@@ -389,6 +389,10 @@ static struct urb *usbtv_setup_iso_transfer(struct usbtv 
*usbtv)
ip->transfer_flags = URB_ISO_ASAP;
ip->transfer_buffer = kzalloc(size * USBTV_ISOC_PACKETS,
GFP_KERNEL);
+   if (!ip->transfer_buffer) {
+   usb_free_urb(ip);
+   return NULL;
+   }
ip->complete = usbtv_iso_cb;
ip->number_of_packets = USBTV_ISOC_PACKETS;
ip->transfer_buffer_length = size * USBTV_ISOC_PACKETS;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] staging: media: lirc: replace NULL comparisons with !var

[Sudip Mukherjee]

On Fri, Dec 18, 2015 at 06:35:25PM +0530, Sudip Mukherjee wrote:
> A NULL comparison can be written as if (var) or if (!var).
> Reported by checkpatch.
> 
> Signed-off-by: Sudip Mukherjee 
> ---

Hi Mauro,

A gentle ping.   
Can this series be considered for 4.5?

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: OK

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Wed Dec 30 04:00:14 CET 2015
git branch: test
git hash:   768acf46e1320d6c41ed1b7c4952bab41c1cde79
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-51-ga53cea2
smatch version: v0.5.0-3228-g5cf65ab
host hardware:  x86_64
host os:4.3.0-164

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

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[media] anysee: Checking failure reporting

[SF Markus Elfring]

Hello,

I have looked at the implementation of the function "anysee_del_i2c_dev" once 
more.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/media/usb/dvb-usb-v2/anysee.c?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n685

Is it really appropriate to end this one with the message "failed"?
Would it be useful to move such a log statement a bit?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: On Lindent shortcomings and massive style fixing

[Andrey Utkin]

On Tue, Dec 29, 2015 at 9:32 AM, Mauro Carvalho Chehab
 wrote:
> IMHO, there are two problems by letting indent breaking long
> lines:
>
> 1) indent would break strings on printks. This is something that we don't
> want to break strings on multiple lines in the Kernel;

Yeah, GNU indent does its work badly (although I believe it could be
taught to respect long literals), this makes me want to have a better
tool for clean "relayouting" C code.
I believe that'd require at last a proper syntax parser. With such
tool, it would be straightforward to rewrite source code automatically
to please any demanding reviewer of code style, except for issues of
higher level of thought (like naming or nesting limitations).

> 2) It doesn't actually solve the problem of having too complex loops,
> with is why the 80 columns warning is meant to warn. Worse than that,
> if a piece of code is inside more than 4 or 5 indentation levels, the
> resulting code of using indent for 80-cols line break is a total crap.

Then I'd propose to enforce nesting limitation explicitly, because
Documentation/CodingStyle appreciates low nesting, just doesn't give
exact numbers.
It's better this way, because the programmer could pay attention to N
places of excessive nesting and fix it manually, and then carelessly
reformat NNN places of "80 chars" issues automatically, comparing to
reviewing all NNN places, to figure out if there's excessive nesting,
or not.
(CCed checkpatch.pl maintainers.)

> That's said, on a quick look at the driver, it seems that the 80-cols
> violations are mostly (if not all) on the comments, like:
>
> int i_poc_lsb = (frame_seqno_in_gop << 1); /* why multiplied by two? 
> TODO try without multiplication */
>
> and
>
> #define TW5864_UNDEF_REG_0x0224 0x0224  /* Undeclared in spec (or not yet 
> added to tw5864-reg.h) but used */
> #define TW5864_UNDEF_REG_0x4014 0x4014  /* Undeclared in spec (or not yet 
> added to tw5864-reg.h) but used */
> #define TW5864_UNDEF_REG_0xA800 0xA800  /* Undeclared in spec (or not yet 
> added to tw5864-reg.h) but used */
>
> Btw, the content of tw5864-reg-undefined.h is weird... Why not just
> add the stuff there at tw5864-reg.h and remove the comments for all
> defines there?

tw5864-reg-undefined.h will be edited for sure (maybe dropped), of
course it won't stay as it is now.
It was generated by script during reverse-engineering that bastard
chip from hell.

> Also, Lindent already did some crappy 80-cols like breaks, like:
>
> static int pci_i2c_multi_read(struct tw5864_dev *dev, u8 devid, u8 devfn, u8 
> *buf,
>u32 count)
>
> (count is misaligned with the open parenthesis)

I just added "static " after indenting.
Actually, Documentation/CodingStyle says nothing about alignment of
function declaration tail on open parenthesis.
Also I'd like to mention that I hate such alignment, because it
requires intermixing of tabs and spaces. I am not aware if this is K
thing or not. If it is, then please don't kill me.

Thanks for kind replies, gentlemen.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] [media] mt9v032: Add V4L2 controls for AEC and AGC

[Laurent Pinchart]

Hi Markus,

On Wednesday 16 December 2015 11:14:28 Markus Pargmann wrote:
> On Wednesday 16 December 2015 09:47:58 Laurent Pinchart wrote:
> > On Monday 14 December 2015 15:41:53 Markus Pargmann wrote:
> >> This patch adds V4L2 controls for Auto Exposure Control and Auto Gain
> >> Control settings. These settings include low pass filter, update
> >> frequency of these settings and the update interval for those units.
> >> 
> >> Signed-off-by: Markus Pargmann 
> > 
> > Please see below for a few comments. If you agree about them there's no
> > need to resubmit, I'll fix the patch when applying.
> 
> Most of them are fine, I commented on the open ones.
> 
> >> ---
> >> 
> >>  drivers/media/i2c/mt9v032.c | 153 -
> >>  1 file changed, 152 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> >> index cc16acf001de..6cbc3b87eda9 100644
> >> --- a/drivers/media/i2c/mt9v032.c
> >> +++ b/drivers/media/i2c/mt9v032.c

[snip]

> >> +static const struct v4l2_ctrl_config mt9v032_aec_max_shutter_width = {
> >> +  .ops= _ctrl_ops,
> >> +  .id = V4L2_CID_AEC_MAX_SHUTTER_WIDTH,
> >> +  .type   = V4L2_CTRL_TYPE_INTEGER,
> >> +  .name   = "aec_max_shutter_width",
> >> +  .min= 1,
> >> +  .max= MT9V032_TOTAL_SHUTTER_WIDTH_MAX,
> > 
> > According the the MT9V032 datasheet I have, the maximum value is 2047
> > while MT9V032_TOTAL_SHUTTER_WIDTH_MAX is defined as 32767. Do you have any
> > information that would hint for an error in the datasheet ?
> 
> The register is defined as having 15 bits. I simply assumed that the already
> defined TOTAL_SHUTTER_WIDTH_MAX would apply for this register as well. At
> least it should end up controlling the same property of the chip. I didn't
> test this on mt9v032 but on mt9v024.

According to the MT9V032 datasheet 
(http://www.onsemi.com/pub/Collateral/MT9V032-D.PDF) the maximum shutter width 
in AEC mode is limited to 2047. That is documented both in the Maximum Total 
Shutter Width register legal values and in the "Automatic Gain Control and 
Automatic Exposure Control" section:

"The exposure is measured in row-time by reading R0xBB. The exposure range is
1 to 2047."

I assume that the the AEC unit limits the shutter width to 2047 lines and that 
it's thus pointless to set the maximum total shutter width to a higher value. 
Whether doing so could have any adverse effect I don't know, but better be 
same than sorry. If you agree we should limit the value to 2047 I can fix 
this.

> >> +  .step   = 1,
> >> +  .def= MT9V032_TOTAL_SHUTTER_WIDTH_DEF,
> >> +  .flags  = 0,
> >> +};
> >> +
> >> +static const struct v4l2_ctrl_config mt9v034_aec_max_shutter_width = {
> >> +  .ops= _ctrl_ops,
> >> +  .id = V4L2_CID_AEC_MAX_SHUTTER_WIDTH,
> >> +  .type   = V4L2_CTRL_TYPE_INTEGER,
> >> +  .name   = "aec_max_shutter_width",
> >> +  .min= 1,
> >> +  .max= MT9V034_TOTAL_SHUTTER_WIDTH_MAX,
> >> +  .step   = 1,
> >> +  .def= MT9V032_TOTAL_SHUTTER_WIDTH_DEF,
> >> +  .flags  = 0,
> >> +};
> > 
> > [snip]

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] uvcvideo: Fix build if !MEDIA_CONTROLLER

[Thierry Reding]

From: Thierry Reding 

Accesses to the UVC device's mdev field need to be protected by a
preprocessor conditional to avoid build errors, since the field is only
included if the MEDIA_CONTROLLER option is selected.

Fixes: 1590ad7b5271 ("[media] media-device: split media initialization and 
registration")
Cc: Javier Martinez Canillas 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Thierry Reding 
---
 drivers/media/usb/uvc/uvc_driver.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 4dfd3eb814e7..fc63f9aae63e 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1937,9 +1937,11 @@ static int uvc_probe(struct usb_interface *intf,
if (uvc_register_chains(dev) < 0)
goto error;
 
+#ifdef CONFIG_MEDIA_CONTROLLER
/* Register the media device node */
if (media_device_register(>mdev) < 0)
goto error;
+#endif
 
/* Save our data pointer in the interface data. */
usb_set_intfdata(intf, dev);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] msi2500: Delete an unnecessary check in msi2500_set_usb_adc()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 29 Dec 2015 12:32:41 +0100

This issue was detected by using the Coccinelle software.

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

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/msi2500/msi2500.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/usb/msi2500/msi2500.c 
b/drivers/media/usb/msi2500/msi2500.c
index c104315..2d33033 100644
--- a/drivers/media/usb/msi2500/msi2500.c
+++ b/drivers/media/usb/msi2500/msi2500.c
@@ -839,8 +839,6 @@ static int msi2500_set_usb_adc(struct msi2500_dev *dev)
goto err;
 
ret = msi2500_ctrl_msg(dev, CMD_WREG, reg3);
-   if (ret)
-   goto err;
 err:
return ret;
 }
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] uvcvideo: Fix build if !MEDIA_CONTROLLER

[Javier Martinez Canillas]

Hello Thierry,

On 12/29/2015 07:30 AM, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Accesses to the UVC device's mdev field need to be protected by a
> preprocessor conditional to avoid build errors, since the field is only
> included if the MEDIA_CONTROLLER option is selected.
> 
> Fixes: 1590ad7b5271 ("[media] media-device: split media initialization and 
> registration")
> Cc: Javier Martinez Canillas 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Thierry Reding 
> ---

Thanks for the patch but I've already posted the same fix a couple of
days ago [0]. Since the offending commit still has not landed in
mainline, Mauro squashed the fixes with the original commit and will
refresh his next branch soon.

[0]: https://lkml.org/lkml/2015/12/21/224

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] v4l: omap3isp: Fix data lane shift configuration

[Laurent Pinchart]

The data-shift DT property speficies the number of bits to be shifted,
but the driver still interprets the value as a multiple of two bits as
used by now removed platform data support. Fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/omap3isp/isp.c  | 2 +-
 drivers/media/platform/omap3isp/ispccdc.c  | 2 +-
 drivers/media/platform/omap3isp/omap3isp.h | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 6952d3604e52..1af6a4359706 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -449,7 +449,7 @@ void omap3isp_configure_bridge(struct isp_device *isp,
case CCDC_INPUT_PARALLEL:
ispctrl_val |= ISPCTRL_PAR_SER_CLK_SEL_PARALLEL;
ispctrl_val |= parcfg->clk_pol << ISPCTRL_PAR_CLK_POL_SHIFT;
-   shift += parcfg->data_lane_shift * 2;
+   shift += parcfg->data_lane_shift;
break;
 
case CCDC_INPUT_CSI2A:
diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index 203323ce7dd4..5cf410949dbc 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -2453,7 +2453,7 @@ static int ccdc_link_validate(struct v4l2_subdev *sd,
&((struct isp_bus_cfg *)
  media_entity_to_v4l2_subdev(link->source->entity)
  ->host_priv)->bus.parallel;
-   parallel_shift = parcfg->data_lane_shift * 2;
+   parallel_shift = parcfg->data_lane_shift;
} else {
parallel_shift = 0;
}
diff --git a/drivers/media/platform/omap3isp/omap3isp.h 
b/drivers/media/platform/omap3isp/omap3isp.h
index 190e259a6a2d..443e8f7673e2 100644
--- a/drivers/media/platform/omap3isp/omap3isp.h
+++ b/drivers/media/platform/omap3isp/omap3isp.h
@@ -33,9 +33,9 @@ enum isp_interface_type {
  * struct isp_parallel_cfg - Parallel interface configuration
  * @data_lane_shift: Data lane shifter
  * 0 - CAMEXT[13:0] -> CAM[13:0]
- * 1 - CAMEXT[13:2] -> CAM[11:0]
- * 2 - CAMEXT[13:4] -> CAM[9:0]
- * 3 - CAMEXT[13:6] -> CAM[7:0]
+ * 2 - CAMEXT[13:2] -> CAM[11:0]
+ * 4 - CAMEXT[13:4] -> CAM[9:0]
+ * 6 - CAMEXT[13:6] -> CAM[7:0]
  * @clk_pol: Pixel clock polarity
  * 0 - Sample on rising edge, 1 - Sample on falling edge
  * @hs_pol: Horizontal synchronization polarity
@@ -48,7 +48,7 @@ enum isp_interface_type {
  * 0 - Normal, 1 - One's complement
  */
 struct isp_parallel_cfg {
-   unsigned int data_lane_shift:2;
+   unsigned int data_lane_shift:3;
unsigned int clk_pol:1;
unsigned int hs_pol:1;
unsigned int vs_pol:1;
-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] hdpvr: Refactoring for hdpvr_read()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 29 Dec 2015 11:02:43 +0100

Let us return directly if the element "status" of the variable "buf"
indicates "BUFSTAT_READY".
A check repetition can be excluded for the variable "ret" at the end then.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/hdpvr/hdpvr-video.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c 
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 7dee22d..ba7f022 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -462,10 +462,8 @@ static ssize_t hdpvr_read(struct file *file, char __user 
*buffer, size_t count,
}
 
if (wait_event_interruptible(dev->wait_data,
- buf->status == BUFSTAT_READY)) {
-   ret = -ERESTARTSYS;
-   goto err;
-   }
+ buf->status == BUFSTAT_READY))
+   return -ERESTARTSYS;
}
 
if (buf->status != BUFSTAT_READY)
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: On Lindent shortcomings and massive style fixing

[Julia Lawall]

On Tue, 29 Dec 2015, Andrey Utkin wrote:

> On Tue, Dec 29, 2015 at 9:32 AM, Mauro Carvalho Chehab
>  wrote:
> > IMHO, there are two problems by letting indent breaking long
> > lines:
> >
> > 1) indent would break strings on printks. This is something that we don't
> > want to break strings on multiple lines in the Kernel;
>
> Yeah, GNU indent does its work badly (although I believe it could be
> taught to respect long literals), this makes me want to have a better
> tool for clean "relayouting" C code.
> I believe that'd require at last a proper syntax parser. With such
> tool, it would be straightforward to rewrite source code automatically
> to please any demanding reviewer of code style, except for issues of
> higher level of thought (like naming or nesting limitations).
>
> > 2) It doesn't actually solve the problem of having too complex loops,
> > with is why the 80 columns warning is meant to warn. Worse than that,
> > if a piece of code is inside more than 4 or 5 indentation levels, the
> > resulting code of using indent for 80-cols line break is a total crap.
>
> Then I'd propose to enforce nesting limitation explicitly, because
> Documentation/CodingStyle appreciates low nesting, just doesn't give
> exact numbers.
> It's better this way, because the programmer could pay attention to N
> places of excessive nesting and fix it manually, and then carelessly
> reformat NNN places of "80 chars" issues automatically, comparing to
> reviewing all NNN places, to figure out if there's excessive nesting,
> or not.
> (CCed checkpatch.pl maintainers.)

Personally, I prefer to see only 80 characters per line, as long as it
doesn't require contorting the code in some other way.  So perhaps not
everyone would agree that the issue is only the amount of nesting.

julia

> > That's said, on a quick look at the driver, it seems that the 80-cols
> > violations are mostly (if not all) on the comments, like:
> >
> > int i_poc_lsb = (frame_seqno_in_gop << 1); /* why multiplied by 
> > two? TODO try without multiplication */
> >
> > and
> >
> > #define TW5864_UNDEF_REG_0x0224 0x0224  /* Undeclared in spec (or not yet 
> > added to tw5864-reg.h) but used */
> > #define TW5864_UNDEF_REG_0x4014 0x4014  /* Undeclared in spec (or not yet 
> > added to tw5864-reg.h) but used */
> > #define TW5864_UNDEF_REG_0xA800 0xA800  /* Undeclared in spec (or not yet 
> > added to tw5864-reg.h) but used */
> >
> > Btw, the content of tw5864-reg-undefined.h is weird... Why not just
> > add the stuff there at tw5864-reg.h and remove the comments for all
> > defines there?
>
> tw5864-reg-undefined.h will be edited for sure (maybe dropped), of
> course it won't stay as it is now.
> It was generated by script during reverse-engineering that bastard
> chip from hell.
>
> > Also, Lindent already did some crappy 80-cols like breaks, like:
> >
> > static int pci_i2c_multi_read(struct tw5864_dev *dev, u8 devid, u8 devfn, 
> > u8 *buf,
> >u32 count)
> >
> > (count is misaligned with the open parenthesis)
>
> I just added "static " after indenting.
> Actually, Documentation/CodingStyle says nothing about alignment of
> function declaration tail on open parenthesis.
> Also I'd like to mention that I hate such alignment, because it
> requires intermixing of tabs and spaces. I am not aware if this is K
> thing or not. If it is, then please don't kill me.
>
> Thanks for kind replies, gentlemen.
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.5] omap3isp fixes

[Laurent Pinchart]

Hi Mauro,

The following changes since commit 768acf46e1320d6c41ed1b7c4952bab41c1cde79:

  [media] rc: sunxi-cir: Initialize the spinlock properly (2015-12-23 15:51:40 
-0200)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git omap3isp/next

for you to fetch changes up to d86cdf3233d06fa037672f09c23ab38f8715c902:

  v4l: omap3isp: Fix data lane shift configuration (2015-12-29 16:28:32 +0200)


Andrzej Hajda (1):
  v4l: omap3isp: Fix handling platform_get_irq result

Javier Martinez Canillas (1):
  v4l: omap3isp: Fix module autoloading

Lad, Prabhakar (1):
  v4l: omap3isp: use vb2_buffer_state enum for vb2 buffer state

Laurent Pinchart (1):
  v4l: omap3isp: Fix data lane shift configuration

Sakari Ailus (3):
  v4l: omap3isp: Move starting the sensor from streamon IOCTL handler to 
VB2 QOP
  v4l: omap3isp: Return buffers back to videobuf2 if pipeline streamon fails
  v4l: omap3isp: preview: Mark output buffer done first

 drivers/media/platform/omap3isp/isp.c|   8 ++-
 drivers/media/platform/omap3isp/ispccdc.c|   2 +-
 drivers/media/platform/omap3isp/isppreview.c |  14 ++---
 drivers/media/platform/omap3isp/ispvideo.c   | 103 
+++
 drivers/media/platform/omap3isp/omap3isp.h   |   8 +--
 5 files changed, 84 insertions(+), 51 deletions(-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] v4l: omap3isp: Fix data lane shift configuration

[Sakari Ailus]

On Tue, Dec 29, 2015 at 04:11:51PM +0200, Laurent Pinchart wrote:
> The data-shift DT property speficies the number of bits to be shifted,
> but the driver still interprets the value as a multiple of two bits as
> used by now removed platform data support. Fix it.
> 
> Signed-off-by: Laurent Pinchart 

Thanks!

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html