This fixes up the remaining "dev is used before it is set" issues in the
go7007 driver that were originally caused by commit
b6ea5ef80aa7fd6f4b18ff2e4174930e8772e812 but not fixed up by reverting
it due to other patches later on adding these "fixes".

Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Dulshani Gunawardhana <dulshani.gunawardhana89@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit b6ea5ef80aa7fd6f4b18ff2e4174930e8772e812.

Turns out to have lots of run-time issues in that the structure is not
initialized before it is used in the debugging messages.

Reported-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Dulshani Gunawardhana <dulshani.gunawardhana89@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull media build fixes from Mauro Carvalho Chehab:
 "A series of patches that fix compilation on non-x86 archs.

  While most of them are just build fixes, there are some fixes for real
  bugs, as there are a number of drivers using dynamic stack allocation.
  A few of those might be considered a security risk, if the i2c-dev
  module is loaded, as someone could be sending very long I2C data that
  could potentially overflow the Kernel stack.  Ok, as using /dev/i2c-*
  devnodes usually requires root on usual distros, and exploiting it
  would require a DVB board or USB stick, the risk is not high"

* 'topic/kbuild-fixes-for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (28 commits)
  [media] platform drivers: Fix build on frv arch
  [media] lirc_zilog: Don't use dynamic static allocation
  [media] mxl111sf: Don't use dynamic static allocation
  [media] af9035: Don't use dynamic static allocation
  [media] af9015: Don't use dynamic static allocation
  [media] dw2102: Don't use dynamic static allocation
  [media] dibusb-common: Don't use dynamic static allocation
  [media] cxusb: Don't use dynamic static allocation
  [media] v4l2-async: Don't use dynamic static allocation
  [media] cimax2: Don't use dynamic static allocation
  [media] tuner-xc2028: Don't use dynamic static allocation
  [media] tuners: Don't use dynamic static allocation
  [media] av7110_hw: Don't use dynamic static allocation
  [media] stv090x: Don't use dynamic static allocation
  [media] stv0367: Don't use dynamic static allocation
  [media] stb0899_drv: Don't use dynamic static allocation
  [media] dvb-frontends: Don't use dynamic static allocation
  [media] dvb-frontends: Don't use dynamic static allocation
  [media] s5h1420: Don't use dynamic static allocation
  [media] uvc/lirc_serial: Fix some warnings on parisc arch
  ...

Pull media updates from Mauro Carvalho Chehab:
 "This series include:
   - a new Remote Controller driver for ST SoC with the corresponding DT
     bindings
   - a new frontend (cx24117)
   - a new I2C camera flash driver (lm3560)
   - a new mem2mem driver for TI SoC (ti-vpe)
   - support for Raphael r828d added to r820t driver
   - some improvements on buffer allocation at VB2 core
   - usual driver fixes and improvements

  PS this time, we have a smaller number of patches.  While it is hard
  to pinpoint to the reasons, I believe that it is mainly due to:

   1) there are several patch series ready, but depending on DT review.
      I decided to grant some extra time for DT maintainers to look on
      it, as they're expecting to have more time with the changes agreed
      during ARM mini-summit and KS.  If they can't review in time for
      3.14, I'll review myself and apply for the next merge window.

   2) I suspect that having both LinuxCon EU and LinuxCon NA happening
      during the same merge window affected the development
      productivity, as several core media developers participated on
      both events"

* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (151 commits)
  [media] media: st-rc: Add ST remote control driver
  [media] gpio-ir-recv: Include linux/of.h header
  [media] tvp7002: Include linux/of.h header
  [media] tvp514x: Include linux/of.h header
  [media] ths8200: Include linux/of.h header
  [media] adv7343: Include linux/of.h header
  [media] v4l: Fix typo in v4l2_subdev_get_try_crop()
  [media] media: i2c: add driver for dual LED Flash, lm3560
  [media] rtl28xxu: add 15f4:0131 Astrometa DVB-T2
  [media] rtl28xxu: add RTL2832P + R828D support
  [media] rtl2832: add new tuner R828D
  [media] r820t: add support for R828D
  [media] media/i2c: ths8200: fix build failure with gcc 4.5.4
  [media] Add support for KWorld UB435-Q V2
  [media] staging/media: fix msi3101 build errors
  [media] ddbridge: Remove casting the return value which is a void pointer
  [media] ngene: Remove casting the return value which is a void pointer
  [media] dm1105: remove unneeded not-null test
  [media] sh_mobile_ceu_camera: remove deprecated IRQF_DISABLED
  [media] media: rcar_vin: Add preliminary r8a7790 support
  ...

Use this new function to make code more comprehensible, since we are
reinitialzing the completion, not initializing.

[akpm@linux-foundation.org: linux-next resyncs]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13)
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull DMA mask updates from Russell King:
 "This series cleans up the handling of DMA masks in a lot of drivers,
  fixing some bugs as we go.

  Some of the more serious errors include:
   - drivers which only set their coherent DMA mask if the attempt to
     set the streaming mask fails.
   - drivers which test for a NULL dma mask pointer, and then set the
     dma mask pointer to a location in their module .data section -
     which will cause problems if the module is reloaded.

  To counter these, I have introduced two helper functions:
   - dma_set_mask_and_coherent() takes care of setting both the
     streaming and coherent masks at the same time, with the correct
     error handling as specified by the API.
   - dma_coerce_mask_and_coherent() which resolves the problem of
     drivers forcefully setting DMA masks.  This is more a marker for
     future work to further clean these locations up - the code which
     creates the devices really should be initialising these, but to fix
     that in one go along with this change could potentially be very
     disruptive.

  The last thing this series does is prise away some of Linux's addition
  to "DMA addresses are physical addresses and RAM always starts at
  zero".  We have ARM LPAE systems where all system memory is above 4GB
  physical, hence having DMA masks interpreted by (eg) the block layers
  as describing physical addresses in the range 0..DMAMASK fails on
  these platforms.  Santosh Shilimkar addresses this in this series; the
  patches were copied to the appropriate people multiple times but were
  ignored.

  Fixing this also gets rid of some ARM weirdness in the setup of the
  max*pfn variables, and brings ARM into line with every other Linux
  architecture as far as those go"

* 'for-linus-dma-masks' of git://git.linaro.org/people/rmk/linux-arm: (52 commits)
  ARM: 7805/1: mm: change max*pfn to include the physical offset of memory
  ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations
  ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations
  ARM: 7795/1: mm: dma-mapping: Add dma_max_pfn(dev) helper function
  ARM: 7794/1: block: Rename parameter dma_mask to max_addr for blk_queue_bounce_limit()
  ARM: DMA-API: better handing of DMA masks for coherent allocations
  ARM: 7857/1: dma: imx-sdma: setup dma mask
  DMA-API: firmware/google/gsmi.c: avoid direct access to DMA masks
  DMA-API: dcdbas: update DMA mask handing
  DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
  DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
  DMA-API: crypto: remove last references to 'static struct device *dev'
  DMA-API: crypto: fix ixp4xx crypto platform device support
  DMA-API: others: use dma_set_coherent_mask()
  DMA-API: staging: use dma_set_coherent_mask()
  DMA-API: usb: use new dma_coerce_mask_and_coherent()
  DMA-API: usb: use dma_set_coherent_mask()
  DMA-API: parport: parport_pc.c: use dma_coerce_mask_and_coherent()
  DMA-API: net: octeon: use dma_coerce_mask_and_coherent()
  DMA-API: net: nxp/lpc_eth: use dma_coerce_mask_and_coherent()
  ...

Pull GPIO changes from Linus Walleij:
 "Here is the bulk of GPIO changes for the v3.13 development cycle.

  I've got ACKs for the things that affect other subsystems (or it's my
  own subsystem, like pinctrl).  Most of that pertain to an attempt from
  my side to consolidate and get rid of custom GPIO implementations in
  the ARM tree.  I will continue doing this.

  The main change this time is the new GPIO descriptor API, background
  for this can be found in Corbet's summary from this january in LWN:

    http://lwn.net/Articles/533632/

  Summary:

   - Merged the GPIO descriptor API from Alexandre Courbot.  This is a
     first step toward trying to get rid of the global GPIO numberspace
     for the future.

   - Add an API so that driver can flag that a certain GPIO line is
     being used by a irqchip backend for generating IRQs, so that we can
     enforce checks, like not allowing users to switch that line to an
     output at runtime, since this makes no sense.  Implemented
     corresponding calls in a few select drivers.

   - ACPI GPIO cleanups, refactorings and switch to using the
     descriptor-based interface.

   - Support for the TPS80036 Palmas GPIO variant.

   - A new driver for the Broadcom Kona GPIO SoC IP block.

   - Device tree support for the PCF857x driver.

   - A set of ARM GPIO refactorings with the goal of getting rid of a
     bunch of custom GPIO implementations from the arch/arm/* tree:

     * Move the IOP GPIO driver to the GPIO subsystem and fix all users
       to use the gpiolib API for accessing GPIOs.  Delete the old
       custom GPIO implementation.

     * Delete the unused custom PXA GPIO implemention.

     * Convert all users of the IXP4 custom GPIO implementation to use
       gpiolib and delete the custom implementation.

     * Delete the custom Gemini GPIO implementation, also completely
       unused.

   - Various cleanups and renamings"

* tag 'gpio-v3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (85 commits)
  gpio: gpio-mxs: Remove unneeded dt checks
  gpio: pl061: don't depend on CONFIG_ARM
  gpio: bcm-kona: add missing .owner to struct gpio_chip
  gpiolib: provide a declaration of seq_file in gpio/driver.h
  gpiolib: include gpio/consumer.h in of_gpio.h for desc_to_gpio()
  gpio: provide stubs for devres gpio functions
  gpiolib: devres: add missing headers
  gpiolib: make GPIO_DEVRES depend on GPIOLIB
  gpiolib: devres: fix devm_gpiod_get_index()
  gpiolib / ACPI: document the GPIO descriptor based interface
  gpiolib / ACPI: allow passing GPIOF_ACTIVE_LOW for GpioInt resources
  gpiolib / ACPI: add ACPI support for gpiod_get_index()
  gpiolib / ACPI: convert to gpiod interfaces
  gpiolib: add gpiod_get() and gpiod_put() functions
  gpiolib: port of_ functions to use gpiod
  gpiolib: export descriptor-based GPIO interface
  Fixup "MAINTAINERS: GPIO-INTEL-MID: add maintainer"
  gpio: bcm281xx: Don't print addresses of GPIO area in probe()
  gpio: tegra: use new gpio_lock_as_irq() API
  gpio: rcar: Include linux/of.h header
  ...

Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
	drivers/staging/media/lirc/lirc_zilog.c:967:1: warning: 'read' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be 64. That should
be more than enough.

Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>

On this arch, usec is not unsigned long. So, we need to typecast,
in order to remove those warnings:
	drivers/media/usb/uvc/uvc_video.c: In function 'uvc_video_clock_update':
	drivers/media/usb/uvc/uvc_video.c:678:2: warning: format '%lu' expects argument of type 'long unsigned int', but argument 9 has type '__kernel_suseconds_t' [-Wformat]
	drivers/staging/media/lirc/lirc_serial.c: In function 'irq_handler':
	drivers/staging/media/lirc/lirc_serial.c:707:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type '__kernel_suseconds_t' [-Wformat]
	drivers/staging/media/lirc/lirc_serial.c:707:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type '__kernel_suseconds_t' [-Wformat]
	drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type '__kernel_suseconds_t' [-Wformat]
	drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type '__kernel_suseconds_t' [-Wformat]
	drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type '__kernel_suseconds_t' [-Wformat]
	drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type '__kernel_suseconds_t' [-Wformat]

Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>

Pull staging driver update from Greg KH:
 "Here's the big drivers/staging/ update for 3.13-rc1.

  Nothing major here, just a _ton_ of fixes and cleanups, mostly driven
  by the new round of OPW applicants, but also there are lots of other
  people doing staging tree cleanups these days in order to help get the
  drivers into mergable shape.

  We also merge, and then revert, the ktap code, as Ingo and the other
  perf/ftrace developers feel it should go into the "real" part of the
  kernel with only a bit more work, so no need to put it in staging for
  now.

  All of this has been in linux-next for a while with no reported
  issues"

* tag 'staging-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (1045 commits)
  staging: drm/imx: fix return value check in ipu_add_subdevice_pdata()
  Staging: zram: Fix access of NULL pointer
  Staging: zram: Fix variable dereferenced before check
  Staging: rtl8187se: space prohibited before semicolon in r8185b_init.c
  Staging: rtl8187se: fix space prohibited after that open parenthesis '(' in r8185b_init.c
  Staging: rtl8187se: fix braces {} are not necessary for single statement blocks in r8185b_init.c
  Staging: rtl8187se: fix trailing whitespace in r8185b_init.c
  Staging: rtl8187se: fix please, no space before tabs in r8185b_init.c
  drivers/staging/nvec/Kconfig: remove trailing whitespace
  Staging: dwc2: Fix variable dereferenced before check
  Staging: xgifb: fix braces {} are not necessary for any arm of this statement
  staging: rtl8192e: remove unneeded semicolons
  staging: rtl8192e: use true and false for bool variables
  staging: ft1000: return values corrected in scram_start_dwnld
  staging: ft1000: change values of status return variable in write_dpram32_and_check
  staging: bcm: Remove unnecessary pointer casting
  imx-drm: ipuv3-crtc: Invert IPU DI0 clock polarity
  staging: r8188eu: Fix sparse warnings in rtl_p2p.c
  staging: r8188eu: Fix sparse warnings in rtw_mlme_ext.c
  staging: r8188eu: Fix sparse warnings in rtl8188e.cmd.c
  ...