RE: [PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t

> On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > >

RE: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t

> On 03/08/2017 08:49 AM, Reshetova, Elena wrote: > >> On 03/06/2017 09:21 AM, Elena Reshetova wrote: > >>> refcount_t type and corresponding API should be > >>> used instead of atomic_t when the variable is used as > >>> a reference counter. This allows to avoid accidental > >>> refcounter

cron job: media_tree daily build: ERRORS

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: Thu Mar 9 05:00:15 CET 2017 media-tree git hash:700ea5e0e0dd70420a04e703ff264cc133834cba media_build

[GIT PULL for v4.11-rc2] media fixes

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.11-2 For media regression fixes: - serial_ir: fix a Kernel crash during boot on Kernel 4.11-rc1, due to an IRQ code called too early; - other IR regression fixes at lirc

Re: [PATCH] [media] solo6x10: release vb2 buffers in solo_stop_streaming()

Signed-off-by: Andrey Utkin Signed-off-by: Andrey Utkin Please welcome Anton who is now in charge of solo6x10 and tw5864 support and development in Bluecherry company, I have sent out to him the hardware samples I possessed. (We will

[PATCH] [media] vcodec: mediatek: fix platform_no_drv_owner.cocci warnings

drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c:1296:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci CC: Rick Chang Signed-off-by:

[ragnatech:media-tree 1271/1281] drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c:1296:3-8: No need to set .owner here. The core will do it.

tree: https://git.ragnatech.se/linux media-tree head: 700ea5e0e0dd70420a04e703ff264cc133834cba commit: b2f0d2724ba477d326e9d654d4db1c93e98f8b93 [1271/1281] [media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver coccinelle warnings: (new ones prefixed by >>) >>

Re: [PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t

On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. >

Re: [PATCHv3 10/15] ov2640: convert from soc-camera to a standard subdev sensor driver.

Am 06.03.2017 um 15:56 schrieb Hans Verkuil: From: Hans Verkuil Convert ov2640 to a standard subdev driver. The soc-camera driver no longer uses this driver, so it can safely be converted. Note: the s_power op has been dropped: this never worked. When the last open()

[PATCH] [media] solo6x10: release vb2 buffers in solo_stop_streaming()

Fixes warning that appears in dmesg after closing V4L2 userspace application that plays video from the display device (first device from V4L2 device nodes provided by solo, usually /dev/video0 when no other V4L2 devices are present). Encoder device nodes are not affected. Can be reproduced by

Re: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t

On 03/08/2017 08:49 AM, Reshetova, Elena wrote: >> On 03/06/2017 09:21 AM, Elena Reshetova wrote: >>> refcount_t type and corresponding API should be >>> used instead of atomic_t when the variable is used as >>> a reference counter. This allows to avoid accidental >>> refcounter overflows that

Re: [PATCH] atomisp2: unify some ifdef cases caused by format changes

Em Wed, 8 Mar 2017 14:55:44 +0100 Hans Verkuil escreveu: > On 08/03/17 14:45, Hans Verkuil wrote: > > On 08/03/17 14:39, Greg KH wrote: > >> On Wed, Mar 08, 2017 at 01:49:23PM +0100, Hans Verkuil wrote: > >>> OK, so I discovered that these patches are for a driver added

Re: [PATCH] staging/atomisp: Add support for the Intel IPU v2

Hi Alan, Em Fri, 17 Feb 2017 16:55:17 + Alan Cox escreveu: Thanks for the driver. Unfortunately, we missed the initial post at linux-media, because VGER doesn't accept too big posts :-( > This patch adds support for the Intel IPU v2 as found on Android and IoT >

[PATCH] v4l: soc-camera: Remove videobuf1 support

All remaining soc-camera drivers use videobuf2, drop support for videobuf1. Signed-off-by: Laurent Pinchart --- drivers/media/platform/soc_camera/soc_camera.c | 103 + include/media/soc_camera.h | 14 +--- 2 files

Re: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t

On 03/08/2017 02:48 PM, Reshetova, Elena wrote: On 03/06/2017 03:21 PM, Elena Reshetova wrote: refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to

Re: [PATCH] atomisp2: unify some ifdef cases caused by format changes

On Wed, Mar 08, 2017 at 01:49:23PM +0100, Hans Verkuil wrote: > OK, so I discovered that these patches are for a driver added to linux-next > without it ever been cross-posted to linux-media. > > To be polite, I think that's rather impolite. They were, but got rejected due to the size :( Mauro

Re: [PATCH] atomisp2: unify some ifdef cases caused by format changes

On Wed, Mar 08, 2017 at 02:55:44PM +0100, Hans Verkuil wrote: > On 08/03/17 14:45, Hans Verkuil wrote: > > On 08/03/17 14:39, Greg KH wrote: > > > On Wed, Mar 08, 2017 at 01:49:23PM +0100, Hans Verkuil wrote: > > > > OK, so I discovered that these patches are for a driver added to > > > >

[GIT PULL FOR v4.12] Fixes, small improvements, coda

Various fixes, improvements. Also a fair number of coda fixes. Regards, Hans The following changes since commit 700ea5e0e0dd70420a04e703ff264cc133834cba: Merge tag 'v4.11-rc1' into patchwork (2017-03-06 06:49:34 -0300) are available in the git repository at:

Re: [PATCH] atomisp2: unify some ifdef cases caused by format changes

On 08/03/17 14:55, Hans Verkuil wrote: > On 08/03/17 14:45, Hans Verkuil wrote: >> On 08/03/17 14:39, Greg KH wrote: >>> On Wed, Mar 08, 2017 at 01:49:23PM +0100, Hans Verkuil wrote: OK, so I discovered that these patches are for a driver added to linux-next without it ever been

Re: [PATCH] atomisp2: unify some ifdef cases caused by format changes

On 08/03/17 15:20, Greg KH wrote: > On Wed, Mar 08, 2017 at 02:55:44PM +0100, Hans Verkuil wrote: >> On 08/03/17 14:45, Hans Verkuil wrote: >>> On 08/03/17 14:39, Greg KH wrote: On Wed, Mar 08, 2017 at 01:49:23PM +0100, Hans Verkuil wrote: > OK, so I discovered that these patches are for

RE: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t

> On 03/06/2017 09:21 AM, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > >

Re: [PATCH] atomisp2: unify some ifdef cases caused by format changes

On 08/03/17 14:45, Hans Verkuil wrote: On 08/03/17 14:39, Greg KH wrote: On Wed, Mar 08, 2017 at 01:49:23PM +0100, Hans Verkuil wrote: OK, so I discovered that these patches are for a driver added to linux-next without it ever been cross-posted to linux-media. To be polite, I think that's

RE: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t

> On 03/06/2017 03:21 PM, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > >

Re: [PATCH] atomisp2: unify some ifdef cases caused by format changes

On 08/03/17 14:39, Greg KH wrote: On Wed, Mar 08, 2017 at 01:49:23PM +0100, Hans Verkuil wrote: OK, so I discovered that these patches are for a driver added to linux-next without it ever been cross-posted to linux-media. To be polite, I think that's rather impolite. They were, but got

[GIT PULL FOR v4.12] Sub-device driver fixes

Hi Mauro, Here are a few minor fixes for sub-device drivers recently added and a documentation change. Please pull. The following changes since commit 700ea5e0e0dd70420a04e703ff264cc133834cba: Merge tag 'v4.11-rc1' into patchwork (2017-03-06 06:49:34 -0300) are available in the git

Re: [PATCH 3/4] Documentation: dt: Add bindings documentation for CSI-2 Host Video Platform

Hi Ramiro, On Tue, Mar 07, 2017 at 02:37:50PM +, Ramiro Oliveira wrote: > Create device tree bindings documentation for the CSI-2 Host Video > platform. Extra space here. > > Signed-off-by: Ramiro Oliveira > --- > .../devicetree/bindings/media/snps,plat-csi2.txt

Re: [PATCH] coda: enable with COMPILE_TEST

On Wed, 2017-03-08 at 12:52 +0100, Hans Verkuil wrote: > Allow building of coda with COMPILE_TEST. > > Fixed one v4l2_err format string that caused a compiler warning when > compiling on a 64-bit > platform. > > Signed-off-by: Hans Verkuil > --- > diff --git

Re: [PATCH] atomisp2: unify some ifdef cases caused by format changes

OK, so I discovered that these patches are for a driver added to linux-next without it ever been cross-posted to linux-media. To be polite, I think that's rather impolite. I'm now reviewing patches for a driver I haven't seen, so that makes me rather unhappy. Please cross-post staging/media

Re: [PATCH] media: vpif: use a configurable i2c_adapter_id for vpif display

2017-03-07 18:12 GMT+01:00 Lad, Prabhakar : > Hi Bartosz, > > Thanks for the patch. > > On Thu, Feb 16, 2017 at 6:08 PM, Bartosz Golaszewski > wrote: >> >> The vpif display driver uses a static i2c adapter ID of 1 but on the >> da850-evm

[PATCH v2] [media] coda: restore original firmware locations

Recently, an unfinished patch was merged that added a third entry to the beginning of the array of firmware locations without changing the code to also look at the third element, thus pushing an old firmware location off the list. Fixes: 8af7779f3cbc ("[media] coda: add Freescale firmware

Re: [PATCH] [media] coda: restore original firmware locations

On Wed, 2017-03-08 at 11:38 +0100, Hans Verkuil wrote: > On 01/03/17 16:36, Philipp Zabel wrote: > > Recently, an unfinished patch was merged that added a third entry to the > > beginning of the array of firmware locations without changing the code > > to also look at the third element, thus

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

On 03/07/2017 06:35 PM, Jose Abreu wrote: > Hi Neil, > > > On 07-03-2017 16:42, Neil Armstrong wrote: >> Some display pipelines can only provide non-RBG input pixels to the HDMI TX >> Controller, this patch takes the pixel format from the plat_data if provided. >> >> Signed-off-by: Neil

[PATCH] coda: enable with COMPILE_TEST

Allow building of coda with COMPILE_TEST. Fixed one v4l2_err format string that caused a compiler warning when compiling on a 64-bit platform. Signed-off-by: Hans Verkuil --- diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

On 03/07/2017 06:35 PM, Jose Abreu wrote: > Hi Neil, > > > On 07-03-2017 16:42, Neil Armstrong wrote: >> Some display pipelines can only provide non-RBG input pixels to the HDMI TX >> Controller, this patch takes the pixel format from the plat_data if provided. >> >> Signed-off-by: Neil

Re: [PATCH] [media] coda: restore original firmware locations

On 01/03/17 16:36, Philipp Zabel wrote: Recently, an unfinished patch was merged that added a third entry to the beginning of the array of firmware locations without changing the code to also look at the third element, thus pushing an old firmware location off the list. Fixes: 8af7779f3cbc

Re: [PATCH] vivid: fix try_fmt behavior

Hi Hans, Thanks for the patch. It has been successfully tested. Tested-by: Vincent Abriou On 03/06/2017 03:23 PM, Hans Verkuil wrote: > vivid_try_fmt_vid_cap() called tpg_calc_line_width to calculate the > sizeimage > value, but that tpg function uses the current format,

Re: [PATCH v3 1/6] drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

Hi Jose, On 03/07/2017 06:12 PM, Jose Abreu wrote: > Hi Neil, > > > On 07-03-2017 16:42, Neil Armstrong wrote: >> From: Laurent Pinchart >> >> In preparation for adding PHY operations to handle RX SENSE and HPD, >> group all the PHY interrupt setup

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

On Wed, Mar 08, 2017 at 09:42:09AM +, Reshetova, Elena wrote: > > On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote: > > > refcount_t type and corresponding API should be > > > used instead of atomic_t when the variable is used as > > > a reference counter. This allows to avoid

RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

> On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > >

RE: [PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t

> On Mon, Mar 06, 2017 at 04:20:57PM +0200, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > >

[PATCH] [media] dvb-usb: don't use stack for firmware load

As reported by Marc Duponcheel , firmware load on dvb-usb is using the stack, with is not allowed anymore on default Kernel configurations: [ 1025.958836] dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)' in cold state, will try to load a firmware [