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

[Reshetova, Elena]

> 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.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> 
> This looks OK to me.
> 
> Acked-by: Chris Leech 

Thank you for review! Do you have a tree that can take this change? 

Best Regards,
Elena.

> 
> > ---
> >  drivers/scsi/libiscsi.c| 8 
> >  drivers/scsi/qedi/qedi_iscsi.c | 2 +-
> >  include/scsi/libiscsi.h| 3 ++-
> >  3 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> > index 834d121..7eb1d2c 100644
> > --- a/drivers/scsi/libiscsi.c
> > +++ b/drivers/scsi/libiscsi.c
> > @@ -516,13 +516,13 @@ static void iscsi_free_task(struct iscsi_task *task)
> >
> >  void __iscsi_get_task(struct iscsi_task *task)
> >  {
> > -   atomic_inc(>refcount);
> > +   refcount_inc(>refcount);
> >  }
> >  EXPORT_SYMBOL_GPL(__iscsi_get_task);
> >
> >  void __iscsi_put_task(struct iscsi_task *task)
> >  {
> > -   if (atomic_dec_and_test(>refcount))
> > +   if (refcount_dec_and_test(>refcount))
> > iscsi_free_task(task);
> >  }
> >  EXPORT_SYMBOL_GPL(__iscsi_put_task);
> > @@ -744,7 +744,7 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct
> iscsi_hdr *hdr,
> >  * released by the lld when it has transmitted the task for
> >  * pdus we do not expect a response for.
> >  */
> > -   atomic_set(>refcount, 1);
> > +   refcount_set(>refcount, 1);
> > task->conn = conn;
> > task->sc = NULL;
> > INIT_LIST_HEAD(>running);
> > @@ -1616,7 +1616,7 @@ static inline struct iscsi_task 
> > *iscsi_alloc_task(struct
> iscsi_conn *conn,
> > sc->SCp.phase = conn->session->age;
> > sc->SCp.ptr = (char *) task;
> >
> > -   atomic_set(>refcount, 1);
> > +   refcount_set(>refcount, 1);
> > task->state = ISCSI_TASK_PENDING;
> > task->conn = conn;
> > task->sc = sc;
> > diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
> > index b9f79d3..3895bd5 100644
> > --- a/drivers/scsi/qedi/qedi_iscsi.c
> > +++ b/drivers/scsi/qedi/qedi_iscsi.c
> > @@ -1372,7 +1372,7 @@ static void qedi_cleanup_task(struct iscsi_task *task)
> >  {
> > if (!task->sc || task->state == ISCSI_TASK_PENDING) {
> > QEDI_INFO(NULL, QEDI_LOG_IO, "Returning
> ref_cnt=%d\n",
> > - atomic_read(>refcount));
> > + refcount_read(>refcount));
> > return;
> > }
> >
> > diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
> > index b0e275d..24d74b5 100644
> > --- a/include/scsi/libiscsi.h
> > +++ b/include/scsi/libiscsi.h
> > @@ -29,6 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -139,7 +140,7 @@ struct iscsi_task {
> >
> > /* state set/tested under session->lock */
> > int state;
> > -   atomic_trefcount;
> > +   refcount_t  refcount;
> > struct list_headrunning;/* running cmd list */
> > void*dd_data;   /*
> driver/transport data */
> >  };
> > --
> > 2.7.4
> >

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

[Reshetova, Elena]

> 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 might lead to use-after-free
> >>> situations.
> >>>
> >>> Signed-off-by: Elena Reshetova 
> >>> Signed-off-by: Hans Liljestrand 
> >>> Signed-off-by: Kees Cook 
> >>> Signed-off-by: David Windsor 
> >>> ---
> >>>  drivers/xen/gntdev.c | 11 ++-
> >>>  1 file changed, 6 insertions(+), 5 deletions(-)
> >> Reviewed-by: Boris Ostrovsky 
> > Is there a tree that can take this change? Turns out it is better to 
> > propagate
> changes via separate trees and only leftovers can be taken via Greg's tree.
> >
> 
> Sure, we can take it via Xen tree for rc3.

Thank you very much!

Best Regards,
Elena.

> 
> -boris

cron job: media_tree daily build: ERRORS

[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:   Thu Mar  9 05:00:15 CET 2017
media-tree git hash:700ea5e0e0dd70420a04e703ff264cc133834cba
media_build git hash:   9d6cebc34b27fea784dec19085970d9b4df9783e
v4l-utils git hash: 4d65b0571ea0027b6de45a76cfcadca32ea4be4a
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: 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.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9-i686: ERRORS
linux-4.10-rc3-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9-x86_64: ERRORS
linux-4.10-rc3-x86_64: ERRORS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

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

[Mauro Carvalho Chehab]

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 and at the raw IR decoding;
   - a deadlock fix at the RC nuvoton driver;
   - Fix another issue with DMA on stack at dw2102 driver.

There's an extra patch there that change a driver interface for the
SoC VSP1 driver, with is shared between the DRM and V4L2 driver.
The patch itself is trivial, and was acked by David Arlie.
As we're early at -rc, I hope that's ok.

Thanks!
Mauro

The following changes since commit 9eeb0ed0f30938f31a3d9135a88b9502192c18dd:

  [media] mtk-vcodec: fix build warnings without DEBUG (2017-02-08 12:08:20 
-0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.11-2

for you to fetch changes up to 8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b:

  [media] v4l: vsp1: Adapt vsp1_du_setup_lif() interface to use a structure 
(2017-03-07 13:34:11 -0300)


media fixes for v4.11-rc2


Heiner Kallweit (1):
  [media] rc: nuvoton: fix deadlock in nvt_write_wakeup_codes

Jonathan McDowell (1):
  [media] dw2102: don't do DMA on stack

Kieran Bingham (1):
  [media] v4l: vsp1: Adapt vsp1_du_setup_lif() interface to use a structure

Sean Young (4):
  [media] serial_ir: ensure we're ready to receive interrupts
  [media] lirc: fix dead lock between open and wakeup_filter
  [media] rc: raw decoder for keymap protocol is not loaded on register
  [media] rc: protocol is not set on register for raw IR devices

 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |   8 +-
 drivers/media/platform/vsp1/vsp1_drm.c |  33 +++--
 drivers/media/rc/lirc_dev.c|   4 +-
 drivers/media/rc/nuvoton-cir.c |   5 +-
 drivers/media/rc/rc-main.c |  26 ++--
 drivers/media/rc/serial_ir.c   | 123 -
 drivers/media/usb/dvb-usb/dw2102.c | 244 -
 include/media/vsp1.h   |  13 +-
 8 files changed, 260 insertions(+), 196 deletions(-)

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

[Andrey Utkin]

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 prepare the patch updating
MAINTAINERS file soon.)

If anybody has any outstanding complains, concerns or tasks regarding
solo6x10 and tw5864 drivers, I think now is good occasion to let us know
about it.

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

[kbuild test robot]

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: Fengguang Wu 
---

 mtk_jpeg_core.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1293,7 +1293,6 @@ static struct platform_driver mtk_jpeg_d
.probe = mtk_jpeg_probe,
.remove = mtk_jpeg_remove,
.driver = {
-   .owner  = THIS_MODULE,
.name   = MTK_JPEG_NAME,
.of_match_table = mtk_jpeg_match,
.pm = _jpeg_pm_ops,

[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.

[kbuild test robot]

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 >>)

>> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c:1296:3-8: No need to set 
>> .owner here. The core will do it.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

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

[Chris Leech]

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.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 

This looks OK to me.

Acked-by: Chris Leech 

> ---
>  drivers/scsi/libiscsi.c| 8 
>  drivers/scsi/qedi/qedi_iscsi.c | 2 +-
>  include/scsi/libiscsi.h| 3 ++-
>  3 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 834d121..7eb1d2c 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -516,13 +516,13 @@ static void iscsi_free_task(struct iscsi_task *task)
>  
>  void __iscsi_get_task(struct iscsi_task *task)
>  {
> - atomic_inc(>refcount);
> + refcount_inc(>refcount);
>  }
>  EXPORT_SYMBOL_GPL(__iscsi_get_task);
>  
>  void __iscsi_put_task(struct iscsi_task *task)
>  {
> - if (atomic_dec_and_test(>refcount))
> + if (refcount_dec_and_test(>refcount))
>   iscsi_free_task(task);
>  }
>  EXPORT_SYMBOL_GPL(__iscsi_put_task);
> @@ -744,7 +744,7 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct 
> iscsi_hdr *hdr,
>* released by the lld when it has transmitted the task for
>* pdus we do not expect a response for.
>*/
> - atomic_set(>refcount, 1);
> + refcount_set(>refcount, 1);
>   task->conn = conn;
>   task->sc = NULL;
>   INIT_LIST_HEAD(>running);
> @@ -1616,7 +1616,7 @@ static inline struct iscsi_task 
> *iscsi_alloc_task(struct iscsi_conn *conn,
>   sc->SCp.phase = conn->session->age;
>   sc->SCp.ptr = (char *) task;
>  
> - atomic_set(>refcount, 1);
> + refcount_set(>refcount, 1);
>   task->state = ISCSI_TASK_PENDING;
>   task->conn = conn;
>   task->sc = sc;
> diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
> index b9f79d3..3895bd5 100644
> --- a/drivers/scsi/qedi/qedi_iscsi.c
> +++ b/drivers/scsi/qedi/qedi_iscsi.c
> @@ -1372,7 +1372,7 @@ static void qedi_cleanup_task(struct iscsi_task *task)
>  {
>   if (!task->sc || task->state == ISCSI_TASK_PENDING) {
>   QEDI_INFO(NULL, QEDI_LOG_IO, "Returning ref_cnt=%d\n",
> -   atomic_read(>refcount));
> +   refcount_read(>refcount));
>   return;
>   }
>  
> diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
> index b0e275d..24d74b5 100644
> --- a/include/scsi/libiscsi.h
> +++ b/include/scsi/libiscsi.h
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -139,7 +140,7 @@ struct iscsi_task {
>  
>   /* state set/tested under session->lock */
>   int state;
> - atomic_trefcount;
> + refcount_t  refcount;
>   struct list_headrunning;/* running cmd list */
>   void*dd_data;   /* driver/transport data */
>  };
> -- 
> 2.7.4
> 

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

[Frank Schäfer]

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()
is closed, then the power is turned off, and when it is opened again the power
is turned on again, but the old state isn't restored.

Someone else can figure out in the future how to get this working correctly,
but I don't want to spend more time on this.

Last two sections of this description are a leftover from v2. ;)

Regards,
Frank



Signed-off-by: Hans Verkuil 
---
  drivers/media/i2c/Kconfig   | 11 
  drivers/media/i2c/Makefile  |  1 +
  drivers/media/i2c/{soc_camera => }/ov2640.c | 89 +
  drivers/media/i2c/soc_camera/Kconfig|  6 --
  drivers/media/i2c/soc_camera/Makefile   |  1 -
  5 files changed, 27 insertions(+), 81 deletions(-)
  rename drivers/media/i2c/{soc_camera => }/ov2640.c (94%)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cee1dae6e014..db2c63f592c5 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -520,6 +520,17 @@ config VIDEO_APTINA_PLL
  config VIDEO_SMIAPP_PLL
tristate
  
+config VIDEO_OV2640

+   tristate "OmniVision OV2640 sensor support"
+   depends on VIDEO_V4L2 && I2C && GPIOLIB
+   depends on MEDIA_CAMERA_SUPPORT
+   help
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2640 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2640.
+
  config VIDEO_OV2659
tristate "OmniVision OV2659 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 5bc7bbeb5499..50af1e11c85a 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
  obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
  obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
  obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/soc_camera/ov2640.c b/drivers/media/i2c/ov2640.c
similarity index 94%
rename from drivers/media/i2c/soc_camera/ov2640.c
rename to drivers/media/i2c/ov2640.c
index b9a0069f5b33..83f88efbce69 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -24,8 +24,8 @@
  #include 
  #include 
  
-#include 

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -287,7 +287,6 @@ struct ov2640_priv {
struct v4l2_clk *clk;
const struct ov2640_win_size*win;
  
-	struct soc_camera_subdev_desc	ssdd_dt;

struct gpio_desc *resetb_gpio;
struct gpio_desc *pwdn_gpio;
  };
@@ -677,13 +676,8 @@ static int ov2640_reset(struct i2c_client *client)
  }
  
  /*

- * soc_camera_ops functions
+ * functions
   */
-static int ov2640_s_stream(struct v4l2_subdev *sd, int enable)
-{
-   return 0;
-}
-
  static int ov2640_s_ctrl(struct v4l2_ctrl *ctrl)
  {
struct v4l2_subdev *sd =
@@ -744,10 +738,16 @@ static int ov2640_s_register(struct v4l2_subdev *sd,
  static int ov2640_s_power(struct v4l2_subdev *sd, int on)
  {
struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
  
-	return soc_camera_set_power(>dev, ssdd, priv->clk, on);

+   gpiod_direction_output(priv->pwdn_gpio, !on);
+   if (on && priv->resetb_gpio) {
+   /* Active the resetb pin to perform a reset pulse */
+   gpiod_direction_output(priv->resetb_gpio, 1);
+   usleep_range(3000, 5000);
+   gpiod_direction_output(priv->resetb_gpio, 0);
+   }
+   return 0;
  }
  
  /* Select the nearest higher resolution for capture */

@@ -994,26 +994,6 @@ static struct v4l2_subdev_core_ops ov2640_subdev_core_ops 
= {
.s_power= ov2640_s_power,
  };
  
-static int ov2640_g_mbus_config(struct v4l2_subdev *sd,

-   struct v4l2_mbus_config *cfg)
-{
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
-
-   cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
-   V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
-   V4L2_MBUS_DATA_ACTIVE_HIGH;
-   cfg->type = V4L2_MBUS_PARALLEL;
-   cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);
-
-   return 0;
-}
-
-static struct v4l2_subdev_video_ops ov2640_subdev_video_ops = {
-  

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

[Anton Sviridenko]

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 starting and closing

ffplay -f video4linux2  /dev/video0

[ 8130.281251] [ cut here ]
[ 8130.281256] WARNING: CPU: 1 PID: 20414 at 
drivers/media/v4l2-core/videobuf2-core.c:1651 __vb2_queue_cancel+0x14b/0x230
[ 8130.281257] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 
iptable_nat solo6x10 x86_pkg_temp_thermal vboxpci(O) vboxnetadp(O) 
vboxnetflt(O) vboxdrv(O)
[ 8130.281264] CPU: 1 PID: 20414 Comm: ffplay Tainted: G   O
4.10.0-gentoo #1
[ 8130.281264] Hardware name: ASUS All Series/B85M-E, BIOS 2301 03/30/2015
[ 8130.281265] Call Trace:
[ 8130.281267]  dump_stack+0x4f/0x72
[ 8130.281270]  __warn+0xc7/0xf0
[ 8130.281271]  warn_slowpath_null+0x18/0x20
[ 8130.281272]  __vb2_queue_cancel+0x14b/0x230
[ 8130.281273]  vb2_core_streamoff+0x23/0x90
[ 8130.281275]  vb2_streamoff+0x24/0x50
[ 8130.281276]  vb2_ioctl_streamoff+0x3d/0x50
[ 8130.281278]  v4l_streamoff+0x15/0x20
[ 8130.281279]  __video_do_ioctl+0x25e/0x2f0
[ 8130.281280]  video_usercopy+0x279/0x520
[ 8130.281282]  ? v4l_enum_fmt+0x1330/0x1330
[ 8130.281285]  ? unmap_region+0xdf/0x110
[ 8130.281285]  video_ioctl2+0x10/0x20
[ 8130.281286]  v4l2_ioctl+0xce/0xe0
[ 8130.281289]  do_vfs_ioctl+0x8b/0x5b0
[ 8130.281290]  ? __fget+0x72/0xa0
[ 8130.281291]  SyS_ioctl+0x74/0x80
[ 8130.281294]  entry_SYSCALL_64_fastpath+0x13/0x94
[ 8130.281295] RIP: 0033:0x7ff86fee6b27
[ 8130.281296] RSP: 002b:7ffe467f6a08 EFLAGS: 0246 ORIG_RAX: 
0010
[ 8130.281297] RAX: ffda RBX: d1a4d788 RCX: 7ff86fee6b27
[ 8130.281297] RDX: 7ffe467f6a14 RSI: 40045613 RDI: 0006
[ 8130.281298] RBP: 0373f8d0 R08:  R09: 7ff860001140
[ 8130.281298] R10: 0243 R11: 0246 R12: 
[ 8130.281299] R13: 00a0 R14: 7ffe467f6530 R15: 01f32228
[ 8130.281300] ---[ end trace 00695dc96be646e7 ]---

Signed-off-by: Anton Sviridenko 
---
 drivers/media/pci/solo6x10/solo6x10-v4l2.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2.c 
b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
index 896bec6..4163103 100644
--- a/drivers/media/pci/solo6x10/solo6x10-v4l2.c
+++ b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
@@ -341,6 +341,18 @@ static void solo_stop_streaming(struct vb2_queue *q)
struct solo_dev *solo_dev = vb2_get_drv_priv(q);
 
solo_stop_thread(solo_dev);
+
+   spin_lock(_dev->slock);
+   while (!list_empty(_dev->vidq_active)) {
+   struct solo_vb2_buf *buf = list_entry(
+   solo_dev->vidq_active.next,
+   struct solo_vb2_buf, list);
+
+   list_del(>list);
+   vb2_buffer_done(>vb.vb2_buf, VB2_BUF_STATE_ERROR);
+   dbg_buf_cnt++;
+   }
+   spin_unlock(_dev->slock);
INIT_LIST_HEAD(_dev->vidq_active);
 }
 
-- 
2.10.2

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

[Boris Ostrovsky]

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 might lead to use-after-free
>>> situations.
>>>
>>> Signed-off-by: Elena Reshetova 
>>> Signed-off-by: Hans Liljestrand 
>>> Signed-off-by: Kees Cook 
>>> Signed-off-by: David Windsor 
>>> ---
>>>  drivers/xen/gntdev.c | 11 ++-
>>>  1 file changed, 6 insertions(+), 5 deletions(-)
>> Reviewed-by: Boris Ostrovsky 
> Is there a tree that can take this change? Turns out it is better to 
> propagate changes via separate trees and only leftovers can be taken via 
> Greg's tree.  
>

Sure, we can take it via Xen tree for rc3.

-boris

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

[Mauro Carvalho Chehab]

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 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 was cc:ed directly, he knew these were coming...
> >>
> >> I can take care of the cleanup patches for now, you don't have to review
> >> them if you don't want to.  
> >
> > Please do.
> >
> > For the next time if the patches are too large: at least post a message with
> > a link to a repo for people to look at. I would like to know what's going
> > on in staging/media, especially since I will do a lot of the reviewing (at
> > least if it is a V4L2 driver) when they want to move it out of staging.  
> 
> Same issue BTW with the bcm2835 driver. That too landed in staging without
> ever being posted to the linux-media mailinglist. Size is no excuse for that
> driver since it isn't that large.

This one got posted at media ML:
https://patchwork.linuxtv.org/project/linux-media/list/?state=*=2835

(patches 1/6 to 6/6)

Thanks,
Mauro

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

[Mauro Carvalho Chehab]

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
> Baytrail-T and Baytrail-CR platforms (those with the IPU PCI mapped). You
> will also need the firmware files from your device (Android usually puts
> them into /etc) - or you can find them in the downloadable restore/upgrade
> kits if you blew them away for some reason.

Before moving firmware-dependent drivers out of staging, please send the
firmware files to linux-firmware ML.

> It may be possible to extend the driver to handle the BYT/T windows
> platforms such as the ASUS T100TA. These platforms don't expose the IPU via
> the PCI interface but via ACPI buried in the GPU description and with the
> camera information somewhere unknown so would need a platform driver
> interface adding to the codebase *IFF* the firmware works on such devices.
> 
> To get good results you also need a suitable support library such as
> libxcam. The camera is intended to be driven from Android so it has a lot of
> features that many desktop apps don't fully spport.
> 
> In theory all the pieces are there to build it with -DISP2401 and some
> differing files to get CherryTrail/T support, but unifying the drivers
> properlly is a work in progress.
> 
> The IPU driver represents the work of a lot of people within Intel over many
> years. It's historical goal was portability rather than Linux upstream. Any
> queries about the upstream aimed driver should be sent to me not to the
> original authors.
> 
> Signed-off-by: Alan Cox 

...

>  920 files changed, 204645 insertions(+)

Wow! that's huge!

> diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
> index abd0e2d..5fe5d8f 100644
> --- a/drivers/staging/media/Kconfig
> +++ b/drivers/staging/media/Kconfig
> @@ -36,4 +36,5 @@ source "drivers/staging/media/lirc/Kconfig"
>  
>  source "drivers/staging/media/st-cec/Kconfig"
>  
> +source "drivers/staging/media/atomisp/Kconfig"
>  endif
> diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
> index dc89325..88d5db9 100644
> --- a/drivers/staging/media/Makefile
> +++ b/drivers/staging/media/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_VIDEO_BCM2835)   += platform/bcm2835/
>  obj-$(CONFIG_VIDEO_DM365_VPFE)   += davinci_vpfe/
>  obj-$(CONFIG_VIDEO_OMAP4)+= omap4iss/
>  obj-$(CONFIG_VIDEO_STI_HDMI_CEC) += st-cec/
> +obj-$(CONFIG_INTEL_ATOMISP) += atomisp/
> diff --git a/drivers/staging/media/atomisp/Kconfig 
> b/drivers/staging/media/atomisp/Kconfig
> new file mode 100644
> index 000..f7d8a84
> --- /dev/null
> +++ b/drivers/staging/media/atomisp/Kconfig
> @@ -0,0 +1,11 @@
> +menuconfig INTEL_ATOMISP
> +bool "Enable support to Intel MIPI camera drivers"
> +depends on X86
> +help
> +  Enable support for the Intel ISP2 camera interfaces and MIPI
> +  sensor drivers.
> +
> +if INTEL_ATOMISP
> +source "drivers/staging/media/atomisp/pci/Kconfig"
> +source "drivers/staging/media/atomisp/i2c/Kconfig"
> +endif
> diff --git a/drivers/staging/media/atomisp/Makefile 
> b/drivers/staging/media/atomisp/Makefile
> new file mode 100644
> index 000..e16752e
> --- /dev/null
> +++ b/drivers/staging/media/atomisp/Makefile
> @@ -0,0 +1,8 @@
> +#
> +# Makefile for camera drivers.
> +#
> +
> +obj-$(CONFIG_INTEL_ATOMISP) += pci/
> +obj-$(CONFIG_INTEL_ATOMISP) += i2c/
> +obj-$(CONFIG_INTEL_ATOMISP) += platform/
> +LINUXINCLUDE+= -I drivers/staging/media/atomisp/include/
> diff --git a/drivers/staging/media/atomisp/TODO 
> b/drivers/staging/media/atomisp/TODO
> new file mode 100644
> index 000..737452c
> --- /dev/null
> +++ b/drivers/staging/media/atomisp/TODO
> @@ -0,0 +1,64 @@
> +1. A single AtomISP driver needs to be implemented to support both BYT and
> +   CHT platforms. The current driver is a mechanical and hand combined merge
> +   of the two using an ifdef ISP2401 to select the CHT version, which at the
> +   moment is not enabled. Eventually this should become a runtime if check,
> +   but there are some quite tricky things that need sorting out before that
> +   will be possible.
> +
> +2. The file structure needs to get tidied up to resemble a normal Linux
> +   driver.
> +
> +3. Lots of the midlayer glue. unused code and abstraction needs removing.
> +
> +3. The sensor drivers read MIPI settings from EFI variables or default to the
> +   settings hard-coded in the platform data file for different platforms.
> +   This isn't ideal but may be hard to improve as this is how existing
> +   platforms work.
> +
> +4. The sensor drivers use the regulator framework API. In the ideal world it
> +   would be using ACPI but that's not how the existing devices work.
> +
> +5. The AtomISP driver includes some special IOCTLS 

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

[Laurent Pinchart]

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 changed, 20 insertions(+), 97 deletions(-)

diff --git a/drivers/media/platform/soc_camera/soc_camera.c 
b/drivers/media/platform/soc_camera/soc_camera.c
index edd1c1de4e33..3c9421f4d8e3 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -37,18 +37,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /* Default to VGA resolution */
 #define DEFAULT_WIDTH  640
 #define DEFAULT_HEIGHT 480
 
-#define is_streaming(ici, icd) \
-   (((ici)->ops->init_videobuf) ?  \
-(icd)->vb_vidq.streaming : \
-vb2_is_streaming(&(icd)->vb2_vidq))
-
 #define MAP_MAX_NUM 32
 static DECLARE_BITMAP(device_map, MAP_MAX_NUM);
 static LIST_HEAD(hosts);
@@ -367,23 +361,13 @@ static int soc_camera_reqbufs(struct file *file, void 
*priv,
 {
int ret;
struct soc_camera_device *icd = file->private_data;
-   struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
 
WARN_ON(priv != file->private_data);
 
if (icd->streamer && icd->streamer != file)
return -EBUSY;
 
-   if (ici->ops->init_videobuf) {
-   ret = videobuf_reqbufs(>vb_vidq, p);
-   if (ret < 0)
-   return ret;
-
-   ret = ici->ops->reqbufs(icd, p);
-   } else {
-   ret = vb2_reqbufs(>vb2_vidq, p);
-   }
-
+   ret = vb2_reqbufs(>vb2_vidq, p);
if (!ret)
icd->streamer = p->count ? file : NULL;
return ret;
@@ -393,61 +377,44 @@ static int soc_camera_querybuf(struct file *file, void 
*priv,
   struct v4l2_buffer *p)
 {
struct soc_camera_device *icd = file->private_data;
-   struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
 
WARN_ON(priv != file->private_data);
 
-   if (ici->ops->init_videobuf)
-   return videobuf_querybuf(>vb_vidq, p);
-   else
-   return vb2_querybuf(>vb2_vidq, p);
+   return vb2_querybuf(>vb2_vidq, p);
 }
 
 static int soc_camera_qbuf(struct file *file, void *priv,
   struct v4l2_buffer *p)
 {
struct soc_camera_device *icd = file->private_data;
-   struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
 
WARN_ON(priv != file->private_data);
 
if (icd->streamer != file)
return -EBUSY;
 
-   if (ici->ops->init_videobuf)
-   return videobuf_qbuf(>vb_vidq, p);
-   else
-   return vb2_qbuf(>vb2_vidq, p);
+   return vb2_qbuf(>vb2_vidq, p);
 }
 
 static int soc_camera_dqbuf(struct file *file, void *priv,
struct v4l2_buffer *p)
 {
struct soc_camera_device *icd = file->private_data;
-   struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
 
WARN_ON(priv != file->private_data);
 
if (icd->streamer != file)
return -EBUSY;
 
-   if (ici->ops->init_videobuf)
-   return videobuf_dqbuf(>vb_vidq, p, file->f_flags & 
O_NONBLOCK);
-   else
-   return vb2_dqbuf(>vb2_vidq, p, file->f_flags & O_NONBLOCK);
+   return vb2_dqbuf(>vb2_vidq, p, file->f_flags & O_NONBLOCK);
 }
 
 static int soc_camera_create_bufs(struct file *file, void *priv,
struct v4l2_create_buffers *create)
 {
struct soc_camera_device *icd = file->private_data;
-   struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
int ret;
 
-   /* videobuf2 only */
-   if (ici->ops->init_videobuf)
-   return -ENOTTY;
-
if (icd->streamer && icd->streamer != file)
return -EBUSY;
 
@@ -461,24 +428,14 @@ static int soc_camera_prepare_buf(struct file *file, void 
*priv,
  struct v4l2_buffer *b)
 {
struct soc_camera_device *icd = file->private_data;
-   struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
 
-   /* videobuf2 only */
-   if (ici->ops->init_videobuf)
-   return -EINVAL;
-   else
-   return vb2_prepare_buf(>vb2_vidq, b);
+   return vb2_prepare_buf(>vb2_vidq, b);
 }
 
 static int soc_camera_expbuf(struct file *file, void *priv,
 struct v4l2_exportbuffer *p)
 {
struct soc_camera_device *icd = file->private_data;
-   struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
-
-   /* videobuf2 only */
-   if (ici->ops->init_videobuf)
-   return -ENOTTY;
 
if (icd->streamer && icd->streamer != file)
return -EBUSY;

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

[Johannes Thumshirn]

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 use-after-free
situations.


The subject is wrong, should be something like "scsi: libfc convert
fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390.

Other than that
Acked-by: Johannes Thumshirn 


Turns out that it is better that all these patches go through the respective 
maintainer trees, if present.
If I send an updated patch (with subject fixed), could you merge it through 
your tree?


Yes, but this would be the normal scsi tree from Martin and James.

Please include my Ack in the re-sends.

Thanks a lot,
Johannes


--
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

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

[Greg KH]

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 was cc:ed directly, he knew these were coming...

I can take care of the cleanup patches for now, you don't have to review
them if you don't want to.

thanks,

greg k-h

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

[Greg KH]

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 
> > > > 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 was cc:ed directly, he knew these were coming...
> > > 
> > > I can take care of the cleanup patches for now, you don't have to review
> > > them if you don't want to.
> > 
> > Please do.
> > 
> > For the next time if the patches are too large: at least post a message with
> > a link to a repo for people to look at. I would like to know what's going
> > on in staging/media, especially since I will do a lot of the reviewing (at
> > least if it is a V4L2 driver) when they want to move it out of staging.
> 
> Same issue BTW with the bcm2835 driver. That too landed in staging without
> ever being posted to the linux-media mailinglist. Size is no excuse for that
> driver since it isn't that large.
> 
> I'll handle cleanup patches for the bcm2835 driver since it is now in our 
> tree.

Nope, it got moved out as it didn't belong there yet :)

It's now in drivers/staging/vc04_services/ as all of the issues so far
aren't media ones, but vc04 api issues.  Once those get ironed out, then
the media people can have at it :)

thanks,

greg k-h

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

[Hans Verkuil]

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:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.12b

for you to fetch changes up to 76ba73c6af740a4d87364da8423b3992079d2051:

  vivid: fix try_fmt behavior (2017-03-08 15:23:36 +0100)


Arnd Bergmann (1):
  tw5864: use dev_warn instead of WARN to shut up warning

Dmitry Torokhov (2):
  ad5820: remove incorrect __exit markups
  Staging: media: radio-bcm2048: remove incorrect __exit markups

Gustavo Padovan (6):
  vb2: only check ret if we assigned it
  ivtv: improve subscribe_event handling
  solo6x10: improve subscribe event handling
  tw5864: improve subscribe event handling
  vivid: improve subscribe event handling
  go7007: improve subscribe event handling

Hans Verkuil (3):
  coda: enable with COMPILE_TEST
  videodev2.h: map xvYCC601/709 to limited range quantization
  vivid: fix try_fmt behavior

Michael Tretter (1):
  coda: Use && instead of & for non-bitfield conditions

Philipp Zabel (7):
  tc358743: put lanes in STOP state before starting streaming
  coda: implement encoder stop command
  coda: disable BWB for all codecs on CODA 960
  coda: keep queued buffers on a temporary list during start_streaming
  coda: pad first h.264 buffer to 512 bytes
  coda: disable reordering for baseline profile h.264 streams
  coda: restore original firmware locations

 Documentation/media/uapi/v4l/pixfmt-007.rst|  13 --
 drivers/media/i2c/ad5820.c |   4 +-
 drivers/media/i2c/tc358743.c   |   4 ++
 drivers/media/pci/ivtv/ivtv-ioctl.c|   4 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c |   5 +--
 drivers/media/pci/tw5864/tw5864-video.c|  11 +++---
 drivers/media/platform/Kconfig |   3 +-
 drivers/media/platform/coda/coda-bit.c | 100 
+-
 drivers/media/platform/coda/coda-common.c  | 120 
+++-
 drivers/media/platform/coda/coda-h264.c|  87 
+---
 drivers/media/platform/coda/coda.h |   8 +++-
 drivers/media/platform/coda/coda_regs.h|   1 +
 drivers/media/platform/vivid/vivid-vid-cap.c   |  13 --
 drivers/media/platform/vivid/vivid-vid-out.c   |  26 ++--
 drivers/media/usb/go7007/go7007-v4l2.c |   5 +--
 drivers/media/v4l2-core/videobuf2-core.c   |  14 ---
 drivers/staging/media/bcm2048/radio-bcm2048.c  |   4 +-
 include/uapi/linux/videodev2.h |   3 +-
 18 files changed, 345 insertions(+), 80 deletions(-)

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

[Hans Verkuil]

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 cross-posted to linux-media.

 To be polite, I think that's rather impolite.
>>>
>>> They were, but got rejected due to the size :(
>>>
>>> Mauro was cc:ed directly, he knew these were coming...
>>>
>>> I can take care of the cleanup patches for now, you don't have to review
>>> them if you don't want to.
>>
>> Please do.
>>
>> For the next time if the patches are too large: at least post a message with
>> a link to a repo for people to look at. I would like to know what's going
>> on in staging/media, especially since I will do a lot of the reviewing (at
>> least if it is a V4L2 driver) when they want to move it out of staging.
> 
> Same issue BTW with the bcm2835 driver. That too landed in staging without
> ever being posted to the linux-media mailinglist. Size is no excuse for that
> driver since it isn't that large.

Sorry about the noise. This driver *was* cross-posted to us. Ignore this rant 
:-)

Hans

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

[Hans Verkuil]

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 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 was cc:ed directly, he knew these were coming...

 I can take care of the cleanup patches for now, you don't have to review
 them if you don't want to.
>>>
>>> Please do.
>>>
>>> For the next time if the patches are too large: at least post a message with
>>> a link to a repo for people to look at. I would like to know what's going
>>> on in staging/media, especially since I will do a lot of the reviewing (at
>>> least if it is a V4L2 driver) when they want to move it out of staging.
>>
>> Same issue BTW with the bcm2835 driver. That too landed in staging without
>> ever being posted to the linux-media mailinglist. Size is no excuse for that
>> driver since it isn't that large.
>>
>> I'll handle cleanup patches for the bcm2835 driver since it is now in our 
>> tree.
> 
> Nope, it got moved out as it didn't belong there yet :)
> 
> It's now in drivers/staging/vc04_services/ as all of the issues so far
> aren't media ones, but vc04 api issues.  Once those get ironed out, then
> the media people can have at it :)

OK, then I will ignore bcm2835 patches for now.

Good to know!

Hans

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

[Reshetova, Elena]

> 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.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  drivers/xen/gntdev.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> Reviewed-by: Boris Ostrovsky 

Is there a tree that can take this change? Turns out it is better to propagate 
changes via separate trees and only leftovers can be taken via Greg's tree.  

Best Regards,
Elena.

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

[Hans Verkuil]

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 rather impolite.


They were, but got rejected due to the size :(

Mauro was cc:ed directly, he knew these were coming...

I can take care of the cleanup patches for now, you don't have to review
them if you don't want to.


Please do.

For the next time if the patches are too large: at least post a message with
a link to a repo for people to look at. I would like to know what's going
on in staging/media, especially since I will do a lot of the reviewing (at
least if it is a V4L2 driver) when they want to move it out of staging.


Same issue BTW with the bcm2835 driver. That too landed in staging without
ever being posted to the linux-media mailinglist. Size is no excuse for that
driver since it isn't that large.

I'll handle cleanup patches for the bcm2835 driver since it is now in our tree.

Regards,

Hans

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

[Reshetova, Elena]

> 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.
> 
> The subject is wrong, should be something like "scsi: libfc convert
> fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390.
> 
> Other than that
> Acked-by: Johannes Thumshirn 

Turns out that it is better that all these patches go through the respective 
maintainer trees, if present. 
If I send an updated patch (with subject fixed), could you merge it through 
your tree?

Best Regards,
Elena.
> 
> --
> Johannes Thumshirn  Storage
> jthumsh...@suse.de+49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

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

[Hans Verkuil]

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 rejected due to the size :(

Mauro was cc:ed directly, he knew these were coming...

I can take care of the cleanup patches for now, you don't have to review
them if you don't want to.


Please do.

For the next time if the patches are too large: at least post a message with
a link to a repo for people to look at. I would like to know what's going
on in staging/media, especially since I will do a lot of the reviewing (at
least if it is a V4L2 driver) when they want to move it out of staging.

Thanks,

Hans

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

[Sakari Ailus]

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 repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git for-v4.12

for you to fetch changes up to b62e5d5c896052119975cc0b08de4728297a2f9d:

  ad5820: remove incorrect __exit markups (2017-03-08 09:42:02 +0200)


Dmitry Torokhov (1):
  ad5820: remove incorrect __exit markups

Javier Martinez Canillas (1):
  et8ek8: Export OF device ID as module aliases

Sakari Ailus (1):
  docs-rst: media: Explicitly refer to sub-sampling in scaling documentation

 Documentation/media/uapi/mediactl/media-types.rst | 3 ++-
 drivers/media/i2c/ad5820.c| 4 ++--
 drivers/media/i2c/et8ek8/et8ek8_driver.c  | 1 +
 3 files changed, 5 insertions(+), 3 deletions(-)

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

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

[Sakari Ailus]

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   | 77 
> ++
>  1 file changed, 77 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/snps,plat-csi2.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/snps,plat-csi2.txt 
> b/Documentation/devicetree/bindings/media/snps,plat-csi2.txt
> new file mode 100644
> index ..f559257a0a44
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,plat-csi2.txt
> @@ -0,0 +1,77 @@
> +Synopsys DesignWare CSI-2 Host Video Platform
> +
> +The Synopsys DesignWare CSI-2 Host Video Device subsystem comprises of 
> multiple
> +sub-devices represented by separate device tree nodes. Currently this 
> includes:
> +plat-csi2, video-device, and dw-mipi-csi.
> +
> +The sub-subdevices are defined as child nodes of the common 'camera'.
> +
> +Common 'camera' node
> +
> +
> +Required properties:
> +
> +- compatible: must be "snps,plat-csi2", "simple-bus"
> +
> +The 'camera' node must include at least one 'video-device' and one 
> 'dw-mipi-csi'
> +child node.
> +
> +'video-device' device nodes
> +---
> +
> +Required properties:
> +
> +- compatible: "snps,video-device"
> +- dmas, dma-names: List of one DMA specifier and identifier string (as 
> defined
> +  in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
> +  requires a DMA channel with the identifier string set to "vdma" followed by
> +  the port index.
> +
> +Image sensor nodes
> +--
> +
> +The sensor device nodes should be added to their control bus controller (e.g.
> +I2C0) nodes and linked to a port node in the dw-mipi-csi,using the common 
> video
> +interfaces bindings, defined in video-interfaces.txt.

You should defined which properties you explicitly support on endpoints and
elsewhere. There are some optional ones for CSI-2, for instance.

> +
> +Example:
> +
> +
> + camera {
> + compatible = "snps,plat-csi2", "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;

Is there something missing here?

> + video_device: video-device@0x1 {
> + compatible = "snps,video-device";
> + dmas = <_vdma_0 0>;
> + dma-names = "vdma0";
> + };
> +
> + csi2:   csi2@0x03000 {
> + compatible = "snps,dw-mipi-csi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = < 0x03000 0x7FF>;
> + interrupts = <2>;
> + phys = <_phy_ctrl1 0>;
> + resets = <_rst 1>;
> +
> + output-type = <2>;
> + ipi-mode = <0>;
> + ipi-color-mode = <0>;
> + ipi-auto-flush = <1>;
> + virtual-channel = <0>;
> +
> + port@1 {

What are the valid ports for this device?

> + reg = <1>;
> + csi1_ep1: endpoint {
> + remote-endpoint = <>;
> + data-lanes = <1 2>;
> + };
> + };
> + };
> + };
> + };
> +
> +The dw-mipi-csi device binding is defined in snps,dw-mipi-csi.txt.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH] coda: enable with COMPILE_TEST

[Philipp Zabel]

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 a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 53f6f12bff0d..9b9bee4b2323 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -151,7 +151,8 @@ if V4L_MEM2MEM_DRIVERS
> 
>   config VIDEO_CODA
>   tristate "Chips Coda multi-standard codec IP"
> - depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> + depends on VIDEO_DEV && VIDEO_V4L2
> + depends on ARCH_MXC || COMPILE_TEST

Yes, that could be helpful.

Acked-by: Philipp Zabel 

>   depends on HAS_DMA
>   select SRAM
>   select VIDEOBUF2_DMA_CONTIG
> diff --git a/drivers/media/platform/coda/coda-common.c 
> b/drivers/media/platform/coda/coda-common.c
> index bd9e5ca8a640..5ec27626539e 100644
> --- a/drivers/media/platform/coda/coda-common.c
> +++ b/drivers/media/platform/coda/coda-common.c
> @@ -1407,7 +1407,7 @@ int coda_alloc_aux_buf(struct coda_dev *dev, struct 
> coda_aux_buf *buf,
>   GFP_KERNEL);
>   if (!buf->vaddr) {
>   v4l2_err(>v4l2_dev,
> -  "Failed to allocate %s buffer of size %u\n",
> +  "Failed to allocate %s buffer of size %zu\n",
>name, size);
>   return -ENOMEM;
>   }
> 

regards
Philipp

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

[Hans Verkuil]

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 drivers to linux-media!

Regards,

Hans

On 06/03/17 12:21, Alan Cox wrote:

The two drivers were originally merged by tools, and the tools didn't always
spot white space only changes. Fix a few of them found by zero-day and clean
up some more by hand.

Signed-off-by: Alan Cox 
---
 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   |   29 ---
 .../media/atomisp/pci/atomisp2/atomisp_ioctl.c |   21 -
 .../media/atomisp/pci/atomisp2/atomisp_subdev.c|   81 
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  |8 --
 4 files changed, 6 insertions(+), 133 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index e99f7b8..d9a5c24 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -1099,15 +1099,9 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, 
int error,
WARN_ON(!vb);
if (vb)
pipe->frame_config_id[vb->i] = frame->isp_config_id;
-#ifndef ISP2401
if (css_pipe_id == IA_CSS_PIPE_ID_CAPTURE &&
asd->pending_capture_request > 0) {
err = atomisp_css_offline_capture_configure(asd,
-#else
-   if (css_pipe_id == IA_CSS_PIPE_ID_CAPTURE) {
-   if (asd->pending_capture_request > 0) {
-   err = atomisp_css_offline_capture_configure(asd,
-#endif
asd->params.offline_parm.num_captures,
asd->params.offline_parm.skip_frames,
asd->params.offline_parm.offset);
@@ -1298,9 +1292,7 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, int 
error,
 */
wake_up(>done);
}
-#ifndef ISP2401
-
-#else
+#ifdef ISP2401
atomic_set(>wdt_count, 0);
 #endif
/*
@@ -4995,26 +4987,15 @@ int atomisp_try_fmt(struct video_device *vdev, struct 
v4l2_format *f,
 {
struct atomisp_device *isp = video_get_drvdata(vdev);
struct atomisp_sub_device *asd = atomisp_to_video_pipe(vdev)->asd;
-#ifndef ISP2401
struct v4l2_subdev_pad_config pad_cfg;
-#else
-struct v4l2_subdev_pad_config pad_cfg;
-#endif
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_TRY,
-#ifndef ISP2401
};
-#else
-   };
-#endif
+
struct v4l2_mbus_framefmt *snr_mbus_fmt = 
const struct atomisp_format_bridge *fmt;
struct atomisp_input_stream_info *stream_info =
-#ifndef ISP2401
(struct atomisp_input_stream_info *)snr_mbus_fmt->reserved;
-#else
-   (struct atomisp_input_stream_info *)snr_mbus_fmt->reserved;
-#endif
uint16_t stream_index;
int source_pad = atomisp_subdev_source_pad(vdev);
int ret;
@@ -5044,11 +5025,7 @@ int atomisp_try_fmt(struct video_device *vdev, struct 
v4l2_format *f,
snr_mbus_fmt->width, snr_mbus_fmt->height);

ret = v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
-#ifndef ISP2401
   pad, set_fmt, _cfg, );
-#else
-   pad, set_fmt, _cfg, );
-#endif
if (ret)
return ret;

@@ -6454,9 +6431,7 @@ int atomisp_s_ae_window(struct atomisp_sub_device *asd,
struct atomisp_ae_window *arg)
 {
struct atomisp_device *isp = asd->isp;
-#ifndef ISP2401
/* Coverity CID 298071 - initialzize struct */
-#endif
struct v4l2_subdev_selection sel = { 0 };

sel.r.left = arg->x_left;
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
index 1445279..6064bb8 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
@@ -530,13 +530,8 @@ const struct atomisp_format_bridge 
*atomisp_get_format_bridge(
return NULL;
 }

-#ifndef ISP2401
 const struct atomisp_format_bridge *atomisp_get_format_bridge_from_mbus(
u32 mbus_code)
-#else
-const struct atomisp_format_bridge *atomisp_get_format_bridge_from_mbus(u32
-   
mbus_code)
-#endif
 {
unsigned int i;

@@ -1303,14 +1298,8 @@ static int atomisp_qbuf(struct file *file, void *fh, 
struct v4l2_buffer *buf)
/* this buffer will have a per-frame parameter */

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

[Bartosz Golaszewski]

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 board in DT boot mode the i2c adapter ID is actually 0.
>>
>> Make the adapter ID configurable like it already is for vpif capture.
>>
>> Signed-off-by: Bartosz Golaszewski 
>> Acked-by: Kevin Hilman 
>> ---
>>  arch/arm/mach-davinci/board-da850-evm.c   | 1 +
>>  drivers/media/platform/davinci/vpif_display.c | 2 +-
>>  include/media/davinci/vpif_types.h| 1 +
>>  3 files changed, 3 insertions(+), 1 deletion(-)
>>
>
> Acked-by: Lad, Prabhakar 
>

Thanks!

Sekhar let me know, that this should be picked up by media. Also:
there are still two DT bindings patches for vpif that can be picked up
- Rob Herring acked them.

Thanks,
Bartosz

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

[Philipp Zabel]

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 compatibility 
location")
Cc: Baruch Siach 
Signed-off-by: Philipp Zabel 
Acked-by: Baruch Siach 
Reviewed-by: Fabio Estevam 
---
Changes since v1:
 - moved fw assignment after ARRAY_SIZE check, to avoid reading into fw
   from undefined memory
---
 drivers/media/platform/coda/coda-common.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index eb6548f46cbac..5024b460fb66a 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -2126,7 +2126,12 @@ static void coda_fw_callback(const struct firmware *fw, 
void *context);
 
 static int coda_firmware_request(struct coda_dev *dev)
 {
-   char *fw = dev->devtype->firmware[dev->firmware];
+   char *fw;
+
+   if (dev->firmware >= ARRAY_SIZE(dev->devtype->firmware))
+   return -EINVAL;
+
+   fw = dev->devtype->firmware[dev->firmware];
 
dev_dbg(>plat_dev->dev, "requesting firmware '%s' for %s\n", fw,
coda_product_name(dev->devtype->product));
@@ -2142,16 +2147,16 @@ static void coda_fw_callback(const struct firmware *fw, 
void *context)
struct platform_device *pdev = dev->plat_dev;
int i, ret;
 
-   if (!fw && dev->firmware == 1) {
-   v4l2_err(>v4l2_dev, "firmware request failed\n");
-   goto put_pm;
-   }
if (!fw) {
-   dev->firmware = 1;
-   coda_firmware_request(dev);
+   dev->firmware++;
+   ret = coda_firmware_request(dev);
+   if (ret < 0) {
+   v4l2_err(>v4l2_dev, "firmware request failed\n");
+   goto put_pm;
+   }
return;
}
-   if (dev->firmware == 1) {
+   if (dev->firmware > 0) {
/*
 * Since we can't suppress warnings for failed asynchronous
 * firmware requests, report that the fallback firmware was
-- 
2.11.0

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

[Philipp Zabel]

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 pushing an old firmware location
> > off the list.
> >
> > Fixes: 8af7779f3cbc ("[media] coda: add Freescale firmware compatibility 
> > location")
> > Cc: Baruch Siach 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  drivers/media/platform/coda/coda-common.c | 17 ++---
> >  1 file changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/media/platform/coda/coda-common.c 
> > b/drivers/media/platform/coda/coda-common.c
> > index eb6548f46cbac..e1a2e8c70db01 100644
> > --- a/drivers/media/platform/coda/coda-common.c
> > +++ b/drivers/media/platform/coda/coda-common.c
> > @@ -2128,6 +2128,9 @@ static int coda_firmware_request(struct coda_dev *dev)
> >  {
> > char *fw = dev->devtype->firmware[dev->firmware];
> >
> > +   if (dev->firmware >= ARRAY_SIZE(dev->devtype->firmware))
> > +   return -EINVAL;
> > +
> 
> Move the fw assignment after this 'if'. Otherwise it's reading from undefined 
> memory
> if dev->firmware >= ARRAY_SIZE(dev->devtype->firmware).
> 
> Regards,
> 
>   Hans

Will do, thanks for the review.

regards
Philipp

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

[Neil Armstrong]

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 Armstrong 
>> ---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 322 
>> +-
>>  include/drm/bridge/dw_hdmi.h  |  63 ++
>>  2 files changed, 290 insertions(+), 95 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 1ed8bc1..348311c 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -30,17 +30,14 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>> +#include 
>> +
>>  #include "dw-hdmi.h"
>>  #include "dw-hdmi-audio.h"
>>  
>>  #define HDMI_EDID_LEN   512
>>  
>> -#define RGB 0
>> -#define YCBCR4441
>> -#define YCBCR422_16BITS 2
>> -#define YCBCR422_8BITS  3
>> -#define XVYCC4444
>> -
>>  enum hdmi_datamap {
>>  RGB444_8B = 0x01,
>>  RGB444_10B = 0x03,
>> @@ -94,10 +91,10 @@ struct hdmi_vmode {
>>  };
>>  
>>  struct hdmi_data_info {
>> -unsigned int enc_in_format;
>> -unsigned int enc_out_format;
>> -unsigned int enc_color_depth;
>> -unsigned int colorimetry;
>> +unsigned int enc_in_bus_format;
>> +unsigned int enc_out_bus_format;
>> +unsigned int enc_in_encoding;
>> +unsigned int enc_out_encoding;
>>  unsigned int pix_repet_factor;
>>  unsigned int hdcp_enable;
>>  struct hdmi_vmode video_mode;
>> @@ -557,6 +554,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
>>  }
>>  EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
>>  
>> +static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +case MEDIA_BUS_FMT_RGB101010_1X30:
>> +case MEDIA_BUS_FMT_RGB121212_1X36:
>> +case MEDIA_BUS_FMT_RGB161616_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_YUV8_1X24:
>> +case MEDIA_BUS_FMT_YUV10_1X30:
>> +case MEDIA_BUS_FMT_YUV12_1X36:
>> +case MEDIA_BUS_FMT_YUV16_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_UYVY8_1X16:
>> +case MEDIA_BUS_FMT_UYVY10_1X20:
>> +case MEDIA_BUS_FMT_UYVY12_1X24:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_UYVY8_1_1X24:
>> +case MEDIA_BUS_FMT_UYVY10_1_1X30:
>> +case MEDIA_BUS_FMT_UYVY12_1_1X36:
>> +case MEDIA_BUS_FMT_UYVY16_1_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +case MEDIA_BUS_FMT_YUV8_1X24:
>> +case MEDIA_BUS_FMT_UYVY8_1X16:
>> +case MEDIA_BUS_FMT_UYVY8_1_1X24:
>> +return 8;
>> +
>> +case MEDIA_BUS_FMT_RGB101010_1X30:
>> +case MEDIA_BUS_FMT_YUV10_1X30:
>> +case MEDIA_BUS_FMT_UYVY10_1X20:
>> +case MEDIA_BUS_FMT_UYVY10_1_1X30:
>> +return 10;
>> +
>> +case MEDIA_BUS_FMT_RGB121212_1X36:
>> +case MEDIA_BUS_FMT_YUV12_1X36:
>> +case MEDIA_BUS_FMT_UYVY12_1X24:
>> +case MEDIA_BUS_FMT_UYVY12_1_1X36:
>> +return 12;
>> +
>> +case MEDIA_BUS_FMT_RGB161616_1X48:
>> +case MEDIA_BUS_FMT_YUV16_1X48:
>> +case MEDIA_BUS_FMT_UYVY16_1_1X48:
>> +return 16;
>> +
>> +default:
>> +return 0;
> 
> Maybe fallback to 8bpp in case of error as this is the most
> common supported.
> 
>> +}
>> +}
>> +
>>  /*
>>   * this submodule is responsible for the video data synchronization.
>>   * for example, for RGB 4:4:4 input, the data map is defined as
>> @@ -569,37 +652,45 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
>>  int color_format = 0;
>>  u8 val;
>>  
>> -if (hdmi->hdmi_data.enc_in_format == RGB) {
>> -if (hdmi->hdmi_data.enc_color_depth == 8)
>> -color_format = 0x01;
>> -else if (hdmi->hdmi_data.enc_color_depth == 10)
>> -color_format = 0x03;
>> -else if (hdmi->hdmi_data.enc_color_depth == 12)
>> -color_format = 0x05;
>> -else if (hdmi->hdmi_data.enc_color_depth == 16)
>> -

[PATCH] coda: enable with COMPILE_TEST

[Hans Verkuil]

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 53f6f12bff0d..9b9bee4b2323 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -151,7 +151,8 @@ if V4L_MEM2MEM_DRIVERS

 config VIDEO_CODA
tristate "Chips Coda multi-standard codec IP"
-   depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MXC || COMPILE_TEST
depends on HAS_DMA
select SRAM
select VIDEOBUF2_DMA_CONTIG
diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index bd9e5ca8a640..5ec27626539e 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1407,7 +1407,7 @@ int coda_alloc_aux_buf(struct coda_dev *dev, struct 
coda_aux_buf *buf,
GFP_KERNEL);
if (!buf->vaddr) {
v4l2_err(>v4l2_dev,
-"Failed to allocate %s buffer of size %u\n",
+"Failed to allocate %s buffer of size %zu\n",
 name, size);
return -ENOMEM;
}

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

[Neil Armstrong]

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 Armstrong 
>> ---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 322 
>> +-
>>  include/drm/bridge/dw_hdmi.h  |  63 ++
>>  2 files changed, 290 insertions(+), 95 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 1ed8bc1..348311c 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -30,17 +30,14 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>> +#include 
>> +
>>  #include "dw-hdmi.h"
>>  #include "dw-hdmi-audio.h"
>>  
>>  #define HDMI_EDID_LEN   512
>>  
>> -#define RGB 0
>> -#define YCBCR4441
>> -#define YCBCR422_16BITS 2
>> -#define YCBCR422_8BITS  3
>> -#define XVYCC4444
>> -
>>  enum hdmi_datamap {
>>  RGB444_8B = 0x01,
>>  RGB444_10B = 0x03,
>> @@ -94,10 +91,10 @@ struct hdmi_vmode {
>>  };
>>  
>>  struct hdmi_data_info {
>> -unsigned int enc_in_format;
>> -unsigned int enc_out_format;
>> -unsigned int enc_color_depth;
>> -unsigned int colorimetry;
>> +unsigned int enc_in_bus_format;
>> +unsigned int enc_out_bus_format;
>> +unsigned int enc_in_encoding;
>> +unsigned int enc_out_encoding;
>>  unsigned int pix_repet_factor;
>>  unsigned int hdcp_enable;
>>  struct hdmi_vmode video_mode;
>> @@ -557,6 +554,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
>>  }
>>  EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
>>  
>> +static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +case MEDIA_BUS_FMT_RGB101010_1X30:
>> +case MEDIA_BUS_FMT_RGB121212_1X36:
>> +case MEDIA_BUS_FMT_RGB161616_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_YUV8_1X24:
>> +case MEDIA_BUS_FMT_YUV10_1X30:
>> +case MEDIA_BUS_FMT_YUV12_1X36:
>> +case MEDIA_BUS_FMT_YUV16_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_UYVY8_1X16:
>> +case MEDIA_BUS_FMT_UYVY10_1X20:
>> +case MEDIA_BUS_FMT_UYVY12_1X24:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_UYVY8_1_1X24:
>> +case MEDIA_BUS_FMT_UYVY10_1_1X30:
>> +case MEDIA_BUS_FMT_UYVY12_1_1X36:
>> +case MEDIA_BUS_FMT_UYVY16_1_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +case MEDIA_BUS_FMT_YUV8_1X24:
>> +case MEDIA_BUS_FMT_UYVY8_1X16:
>> +case MEDIA_BUS_FMT_UYVY8_1_1X24:
>> +return 8;
>> +
>> +case MEDIA_BUS_FMT_RGB101010_1X30:
>> +case MEDIA_BUS_FMT_YUV10_1X30:
>> +case MEDIA_BUS_FMT_UYVY10_1X20:
>> +case MEDIA_BUS_FMT_UYVY10_1_1X30:
>> +return 10;
>> +
>> +case MEDIA_BUS_FMT_RGB121212_1X36:
>> +case MEDIA_BUS_FMT_YUV12_1X36:
>> +case MEDIA_BUS_FMT_UYVY12_1X24:
>> +case MEDIA_BUS_FMT_UYVY12_1_1X36:
>> +return 12;
>> +
>> +case MEDIA_BUS_FMT_RGB161616_1X48:
>> +case MEDIA_BUS_FMT_YUV16_1X48:
>> +case MEDIA_BUS_FMT_UYVY16_1_1X48:
>> +return 16;
>> +
>> +default:
>> +return 0;
> 
> Maybe fallback to 8bpp in case of error as this is the most
> common supported.

The "return 0" mimics when enc_color_depth was set to 0, and it has a meaning
when used in other functions.
To be honest, I'm not sure if these cases are legit.

> 
>> +}
>> +}
>> +
>>  /*
>>   * this submodule is responsible for the video data synchronization.
>>   * for example, for RGB 4:4:4 input, the data map is defined as
>> @@ -569,37 +652,45 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
>>  int color_format = 0;
>>  u8 val;
>>  
>> -if (hdmi->hdmi_data.enc_in_format == RGB) {
>> -if (hdmi->hdmi_data.enc_color_depth == 8)
>> -color_format = 0x01;
>> -else if (hdmi->hdmi_data.enc_color_depth == 10)
>> -color_format = 0x03;
>> -

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

[Hans Verkuil]

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 ("[media] coda: add Freescale firmware compatibility 
location")
Cc: Baruch Siach 
Signed-off-by: Philipp Zabel 
---
 drivers/media/platform/coda/coda-common.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index eb6548f46cbac..e1a2e8c70db01 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -2128,6 +2128,9 @@ static int coda_firmware_request(struct coda_dev *dev)
 {
char *fw = dev->devtype->firmware[dev->firmware];

+   if (dev->firmware >= ARRAY_SIZE(dev->devtype->firmware))
+   return -EINVAL;
+


Move the fw assignment after this 'if'. Otherwise it's reading from undefined 
memory
if dev->firmware >= ARRAY_SIZE(dev->devtype->firmware).

Regards,

Hans


dev_dbg(>plat_dev->dev, "requesting firmware '%s' for %s\n", fw,
coda_product_name(dev->devtype->product));

@@ -2142,16 +2145,16 @@ static void coda_fw_callback(const struct firmware *fw, 
void *context)
struct platform_device *pdev = dev->plat_dev;
int i, ret;

-   if (!fw && dev->firmware == 1) {
-   v4l2_err(>v4l2_dev, "firmware request failed\n");
-   goto put_pm;
-   }
if (!fw) {
-   dev->firmware = 1;
-   coda_firmware_request(dev);
+   dev->firmware++;
+   ret = coda_firmware_request(dev);
+   if (ret < 0) {
+   v4l2_err(>v4l2_dev, "firmware request failed\n");
+   goto put_pm;
+   }
return;
}
-   if (dev->firmware == 1) {
+   if (dev->firmware > 0) {
/*
 * Since we can't suppress warnings for failed asynchronous
 * firmware requests, report that the fallback firmware was

Re: [PATCH] vivid: fix try_fmt behavior

[Vincent ABRIOU]

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, not the proposed
> (tried)
> format.
>
> Rewrote this code to calculate this correctly.
>
> The vivid_try_fmt_vid_out() code was completely wrong w.r.t. sizeimage, and
> neither did it take the vdownsampling[] factors into account.
>
> Signed-off-by: Hans Verkuil  ---
> diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
> b/drivers/media/platform/vivid/vivid-vid-cap.c
> index a18e6fec219b..01419455e545 100644
> --- a/drivers/media/platform/vivid/vivid-vid-cap.c
> +++ b/drivers/media/platform/vivid/vivid-vid-cap.c
> @@ -616,7 +616,7 @@ int vivid_try_fmt_vid_cap(struct file *file, void
> *priv,
>  /* This driver supports custom bytesperline values */
>
>  mp->num_planes = fmt->buffers;
> -for (p = 0; p < mp->num_planes; p++) {
> +for (p = 0; p < fmt->buffers; p++) {
>  /* Calculate the minimum supported bytesperline value */
>  bytesperline = (mp->width * fmt->bit_depth[p]) >> 3;
>  /* Calculate the maximum supported bytesperline value */
> @@ -626,10 +626,17 @@ int vivid_try_fmt_vid_cap(struct file *file, void
> *priv,
>  pfmt[p].bytesperline = max_bpl;
>  if (pfmt[p].bytesperline < bytesperline)
>  pfmt[p].bytesperline = bytesperline;
> -pfmt[p].sizeimage = tpg_calc_line_width(>tpg, p,
> pfmt[p].bytesperline) *
> -mp->height + fmt->data_offset[p];
> +
> +pfmt[p].sizeimage = (pfmt[p].bytesperline * mp->height) /
> +fmt->vdownsampling[p] + fmt->data_offset[p];
> +
>  memset(pfmt[p].reserved, 0, sizeof(pfmt[p].reserved));
>  }
> +for (p = fmt->buffers; p < fmt->planes; p++)
> +pfmt[0].sizeimage += (pfmt[0].bytesperline * mp->height *
> +(fmt->bit_depth[p] / fmt->vdownsampling[p])) /
> +(fmt->bit_depth[0] / fmt->vdownsampling[0]);
> +
>  mp->colorspace = vivid_colorspace_cap(dev);
>  if (fmt->color_enc == TGP_COLOR_ENC_HSV)
>  mp->hsv_enc = vivid_hsv_enc_cap(dev);
> diff --git a/drivers/media/platform/vivid/vivid-vid-out.c
> b/drivers/media/platform/vivid/vivid-vid-out.c
> index 7ba52ee98371..b3b3b31c873b 100644
> --- a/drivers/media/platform/vivid/vivid-vid-out.c
> +++ b/drivers/media/platform/vivid/vivid-vid-out.c
> @@ -390,22 +390,28 @@ int vivid_try_fmt_vid_out(struct file *file, void
> *priv,
>
>  /* This driver supports custom bytesperline values */
>
> -/* Calculate the minimum supported bytesperline value */
> -bytesperline = (mp->width * fmt->bit_depth[0]) >> 3;
> -/* Calculate the maximum supported bytesperline value */
> -max_bpl = (MAX_ZOOM * MAX_WIDTH * fmt->bit_depth[0]) >> 3;
>  mp->num_planes = fmt->buffers;
> -for (p = 0; p < mp->num_planes; p++) {
> +for (p = 0; p < fmt->buffers; p++) {
> +/* Calculate the minimum supported bytesperline value */
> +bytesperline = (mp->width * fmt->bit_depth[p]) >> 3;
> +/* Calculate the maximum supported bytesperline value */
> +max_bpl = (MAX_ZOOM * MAX_WIDTH * fmt->bit_depth[p]) >> 3;
> +
>  if (pfmt[p].bytesperline > max_bpl)
>  pfmt[p].bytesperline = max_bpl;
>  if (pfmt[p].bytesperline < bytesperline)
>  pfmt[p].bytesperline = bytesperline;
> -pfmt[p].sizeimage = pfmt[p].bytesperline * mp->height;
> +
> +pfmt[p].sizeimage = (pfmt[p].bytesperline * mp->height) /
> +fmt->vdownsampling[p];
> +
>  memset(pfmt[p].reserved, 0, sizeof(pfmt[p].reserved));
>  }
>  for (p = fmt->buffers; p < fmt->planes; p++)
> -pfmt[0].sizeimage += (pfmt[0].bytesperline * fmt->bit_depth[p]) /
> - (fmt->bit_depth[0] * fmt->vdownsampling[p]);
> +pfmt[0].sizeimage += (pfmt[0].bytesperline * mp->height *
> +(fmt->bit_depth[p] / fmt->vdownsampling[p])) /
> +(fmt->bit_depth[0] / fmt->vdownsampling[0]);
> +
>  mp->xfer_func = V4L2_XFER_FUNC_DEFAULT;
>  mp->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
>  mp->quantization = V4L2_QUANTIZATION_DEFAULT;
>

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

[Neil Armstrong]

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 code in a single location and extract
>> it to a separate function.
>>
>> Signed-off-by: Laurent Pinchart 
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 50 
>> ++-
>>  1 file changed, 23 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 026a0dc..1ed8bc1 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -1496,7 +1496,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
>> drm_display_mode *mode)
>>  }
>>  
>>  /* Wait until we are registered to enable interrupts */
>> -static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
>> +static void dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
>>  {
>>  hdmi_writeb(hdmi, HDMI_PHY_I2CM_INT_ADDR_DONE_POL,
>>  HDMI_PHY_I2CM_INT_ADDR);
>> @@ -1504,15 +1504,6 @@ static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
>>  hdmi_writeb(hdmi, HDMI_PHY_I2CM_CTLINT_ADDR_NAC_POL |
>>  HDMI_PHY_I2CM_CTLINT_ADDR_ARBITRATION_POL,
>>  HDMI_PHY_I2CM_CTLINT_ADDR);
>> -
>> -/* enable cable hot plug irq */
>> -hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
>> -
>> -/* Clear Hotplug interrupts */
>> -hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
>> -HDMI_IH_PHY_STAT0);
>> -
>> -return 0;
>>  }
>>  
>>  static void initialize_hdmi_ih_mutes(struct dw_hdmi *hdmi)
>> @@ -1630,6 +1621,26 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi 
>> *hdmi)
>>  hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
>>  }
>>  
>> +static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi)
>> +{
>> +/*
>> + * Configure the PHY RX SENSE and HPD interrupts polarities and clear
>> + * any pending interrupt.
>> + */
>> +hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
>> +hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
>> +HDMI_IH_PHY_STAT0);
>> +
>> +/* Enable cable hot plug irq. */
>> +hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
>> +
>> +/* Clear and unmute interrupts. */
>> +hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
>> +HDMI_IH_PHY_STAT0);
>> +hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
>> +HDMI_IH_MUTE_PHY_STAT0);
>> +}
>> +
>>  static enum drm_connector_status
>>  dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
>>  {
>> @@ -2141,29 +2152,14 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
>>  hdmi->ddc = NULL;
>>  }
>>  
>> -/*
>> - * Configure registers related to HDMI interrupt
>> - * generation before registering IRQ.
>> - */
> 
> 
> I've seen the databook and HPD interrupts are enabled per default
> (actually I think most of the interrupts are). I'm thinking
> whether we could get spurious interrupts because of not
> configuring HPD before registering IRQ (probably thats why the
> comment was there). How did you test this? I think that if you
> insert the cable before loading modules then you can try to
> emulate this condition. What do you think?

In fact the comment was wrong because it happened after the IRQ register,
and right before the IRQ register the initialize_hdmi_ih_mutes() is already
called to mute all the IRQ sources.
The previous rework moved the IRQ code, so this cleanup is welcome.

But indeed, I did not check this condition, I can try this.

Thanks,
Neil

> 
> Best regards,
> Jose Miguel Abreu
> 
>> -hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
>> -
>> -/* Clear Hotplug interrupts */
>> -hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
>> -HDMI_IH_PHY_STAT0);
>> -
>>  hdmi->bridge.driver_private = hdmi;
>>  hdmi->bridge.funcs = _hdmi_bridge_funcs;
>>  #ifdef CONFIG_OF
>>  hdmi->bridge.of_node = pdev->dev.of_node;
>>  #endif
>>  
>> -ret = dw_hdmi_fb_registered(hdmi);
>> -if (ret)
>> -goto err_iahb;
>> -
>> -/* Unmute interrupts */
>> -hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
>> -HDMI_IH_MUTE_PHY_STAT0);
>> +dw_hdmi_fb_registered(hdmi);
>> +dw_hdmi_phy_setup_hpd(hdmi);
>>  
>>  memset(, 0, sizeof(pdevinfo));
>>  pdevinfo.parent = dev;

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

[gre...@linuxfoundation.org]

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 accidental
> > > refcounter overflows that might lead to use-after-free
> > > situations.
> > 
> > Looks good. Let me know how do you want to route the patch to upstream.
> 
> Greg, you previously mentioned that driver's conversions can go via your 
> tree. Does this still apply?
> Or should I be asking maintainers to merge these patches via their trees? 

You should ask them to take them through their trees, if they have them.
I'll be glad to scoop up all of the remaining ones that get missed, or
for subsystems that do not have trees.

thanks,

greg k-h

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

[Reshetova, Elena]

> 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
> > situations.
> 
> Looks good. Let me know how do you want to route the patch to upstream.

Greg, you previously mentioned that driver's conversions can go via your tree. 
Does this still apply?
Or should I be asking maintainers to merge these patches via their trees? 
I am not sure about the correct (and easier for everyone) way, please suggest.  

Best Regards,
Elena.
> 
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  drivers/md/md.c | 6 +++---
> >  drivers/md/md.h | 3 ++-
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/md/md.c b/drivers/md/md.c
> > index 985374f..94c8ebf 100644
> > --- a/drivers/md/md.c
> > +++ b/drivers/md/md.c
> > @@ -449,7 +449,7 @@ EXPORT_SYMBOL(md_unplug);
> >
> >  static inline struct mddev *mddev_get(struct mddev *mddev)
> >  {
> > -   atomic_inc(>active);
> > +   refcount_inc(>active);
> > return mddev;
> >  }
> >
> > @@ -459,7 +459,7 @@ static void mddev_put(struct mddev *mddev)
> >  {
> > struct bio_set *bs = NULL;
> >
> > -   if (!atomic_dec_and_lock(>active, _mddevs_lock))
> > +   if (!refcount_dec_and_lock(>active, _mddevs_lock))
> > return;
> > if (!mddev->raid_disks && list_empty(>disks) &&
> > mddev->ctime == 0 && !mddev->hold_active) {
> > @@ -495,7 +495,7 @@ void mddev_init(struct mddev *mddev)
> > INIT_LIST_HEAD(>all_mddevs);
> > setup_timer(>safemode_timer, md_safemode_timeout,
> > (unsigned long) mddev);
> > -   atomic_set(>active, 1);
> > +   refcount_set(>active, 1);
> > atomic_set(>openers, 0);
> > atomic_set(>active_io, 0);
> > spin_lock_init(>lock);
> > diff --git a/drivers/md/md.h b/drivers/md/md.h
> > index b8859cb..4811663 100644
> > --- a/drivers/md/md.h
> > +++ b/drivers/md/md.h
> > @@ -22,6 +22,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -360,7 +361,7 @@ struct mddev {
> >  */
> > struct mutexopen_mutex;
> > struct mutexreconfig_mutex;
> > -   atomic_tactive;
>   /* general refcount */
> > +   refcount_t  active;
>   /* general refcount */
> > atomic_topeners;/*
> number of active opens */
> >
> > int
>   changed;/* True if we might need to
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Reshetova, Elena]

> 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
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  drivers/md/raid5-cache.c |  8 +++---
> >  drivers/md/raid5.c   | 66 
> > 
> >  drivers/md/raid5.h   |  3 ++-
> >  3 files changed, 39 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> > index 3f307be..6c05e12 100644
> > --- a/drivers/md/raid5-cache.c
> > +++ b/drivers/md/raid5-cache.c
> 
> snip
> >sh->check_state, sh->reconstruct_state);
> >
> > analyse_stripe(sh, );
> > @@ -4924,7 +4924,7 @@ static void activate_bit_delay(struct r5conf *conf,
> > struct stripe_head *sh = list_entry(head.next, struct
> stripe_head, lru);
> > int hash;
> > list_del_init(>lru);
> > -   atomic_inc(>count);
> > +   refcount_inc(>count);
> > hash = sh->hash_lock_index;
> > __release_stripe(conf, sh,
> _inactive_list[hash]);
> > }
> > @@ -5240,7 +5240,7 @@ static struct stripe_head 
> > *__get_priority_stripe(struct
> r5conf *conf, int group)
> > sh->group = NULL;
> > }
> > list_del_init(>lru);
> > -   BUG_ON(atomic_inc_return(>count) != 1);
> > +   BUG_ON(refcount_inc_not_zero(>count));
> 
> This changes the behavior. refcount_inc_not_zero doesn't inc if original 
> value is 0

Hm.. So, you want to inc here in any case and BUG if the end result differs 
from 1. 
So essentially you want to only increment here from zero to one under normal 
conditions... This is a challenge for refcount_t and against the design.
Is it ok just to maybe do this here:

-   BUG_ON(atomic_inc_return(>count) != 1);
+   BUG_ON(refcount_read(>count) != 0);
+   refcount_set((>count, 1);

Do we have an issue with locking in this case? Or maybe it is then better to 
leave this one to be atomic_t without protection since it isn't a real 
refcounter as it turns out. 

Best Regards,
Elena. 

> 
> Thanks,
> Shaohua

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

[Mauro Carvalho Chehab]

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
[ 1025.958853] dvb-usb: downloading firmware from file 
'dvb-usb-wt220u-zl0353-01.fw'
[ 1025.958855] dvb-usb: could not stop the USB controller CPU.
[ 1025.958856] dvb-usb: error while transferring firmware (transferred size: 
-11, block size: 3)
[ 1025.958856] dvb-usb: firmware download failed at 8 with -22
[ 1025.958867] usbcore: registered new interface driver dvb_usb_dtt200u

[2.789902] dvb-usb: downloading firmware from file 
'dvb-usb-wt220u-zl0353-01.fw'
[2.789905] [ cut here ]
[2.789911] WARNING: CPU: 3 PID: 2196 at drivers/usb/core/hcd.c:1584 
usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
[2.789912] transfer buffer not dma capable
[2.789912] Modules linked in: btusb dvb_usb_dtt200u(+) dvb_usb_af9035(+) 
btrtl btbcm dvb_usb dvb_usb_v2 btintel dvb_core bluetooth rc_core rfkill 
x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul aesni_intel 
aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd drm_kms_helper 
syscopyarea sysfillrect pcspkr i2c_i801 sysimgblt fb_sys_fops drm i2c_smbus 
i2c_core r8169 lpc_ich mfd_core mii thermal fan rtc_cmos video button 
acpi_cpufreq processor snd_hda_codec_realtek snd_hda_codec_generic 
snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd 
crc32c_intel ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd usbcore 
usb_common dm_mirror dm_region_hash dm_log dm_mod
[2.789936] CPU: 3 PID: 2196 Comm: systemd-udevd Not tainted 4.9.0-gentoo #1
[2.789937] Hardware name: ASUS All Series/H81I-PLUS, BIOS 0401 07/23/2013
[2.789938]  c9000339b690 812bd397 c9000339b6e0 

[2.789939]  c9000339b6d0 81055c86 06300339b6a0 
880116c0c000
[2.789941]    0001 
880116c08000
[2.789942] Call Trace:
[2.789945]  [] dump_stack+0x4d/0x66
[2.789947]  [] __warn+0xc6/0xe0
[2.789948]  [] warn_slowpath_fmt+0x4a/0x50
[2.789952]  [] usb_hcd_map_urb_for_dma+0x430/0x560 
[usbcore]
[2.789954]  [] ? io_schedule_timeout+0xd8/0x110
[2.789956]  [] usb_hcd_submit_urb+0x9c/0x980 [usbcore]
[2.789958]  [] ? copy_page_to_iter+0x14f/0x2b0
[2.789960]  [] ? pagecache_get_page+0x28/0x240
[2.789962]  [] ? touch_atime+0x20/0xa0
[2.789964]  [] usb_submit_urb+0x2c4/0x520 [usbcore]
[2.789967]  [] usb_start_wait_urb+0x5a/0xe0 [usbcore]
[2.789969]  [] usb_control_msg+0xbc/0xf0 [usbcore]
[2.789970]  [] usb_cypress_writemem+0x3d/0x40 [dvb_usb]
[2.789972]  [] usb_cypress_load_firmware+0x4f/0x130 
[dvb_usb]
[2.789973]  [] ? console_unlock+0x2fe/0x5d0
[2.789974]  [] ? vprintk_emit+0x27c/0x410
[2.789975]  [] ? vprintk_default+0x1a/0x20
[2.789976]  [] ? printk+0x43/0x4b
[2.789977]  [] dvb_usb_download_firmware+0x60/0xd0 
[dvb_usb]
[2.789979]  [] dvb_usb_device_init+0x3d8/0x610 [dvb_usb]
[2.789981]  [] dtt200u_usb_probe+0x92/0xd0 
[dvb_usb_dtt200u]
[2.789984]  [] usb_probe_interface+0xfc/0x270 [usbcore]
[2.789985]  [] driver_probe_device+0x215/0x2d0
[2.789986]  [] __driver_attach+0x96/0xa0
[2.789987]  [] ? driver_probe_device+0x2d0/0x2d0
[2.789988]  [] bus_for_each_dev+0x5b/0x90
[2.789989]  [] driver_attach+0x19/0x20
[2.789990]  [] bus_add_driver+0x11c/0x220
[2.789991]  [] driver_register+0x5b/0xd0
[2.789994]  [] usb_register_driver+0x7c/0x130 [usbcore]
[2.789994]  [] ? 0xa06a5000
[2.789996]  [] dtt200u_usb_driver_init+0x1e/0x20 
[dvb_usb_dtt200u]
[2.789997]  [] do_one_initcall+0x38/0x140
[2.789998]  [] ? __vunmap+0x7c/0xc0
[2.78]  [] ? do_init_module+0x22/0x1d2
[2.79]  [] do_init_module+0x5a/0x1d2
[2.790002]  [] load_module+0x1e11/0x2580
[2.790003]  [] ? show_taint+0x30/0x30
[2.790004]  [] ? kernel_read_file+0x100/0x190
[2.790005]  [] SyS_finit_module+0xba/0xc0
[2.790007]  [] entry_SYSCALL_64_fastpath+0x13/0x94
[2.790008] ---[ end trace c78a74e78baec6fc ]---

So, allocate the structure dynamically.

Cc: sta...@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab 

---

The original patch failed to apply on Kernel 4.9, due to a trivial change
inside an error message. Original upstream patch:

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

Greg,

There is one additional fix for dvb-usb-firmware for it to work fine with
non-DMA capable stack. I'm submitting it upstream later today. It should 
apply fine after this one (I tested).

diff --git a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c 
b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
index dd048a7c461c..9fc91cd2e029 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c