media: omap3isp: fix unbalanced dma_iommu_mapping

The OMAP3 ISP driver manages its MMU mappings through the IOMMU-aware
ARM DMA backend. The current code creates a dma_iommu_mapping and
attaches this to the ISP device, but never detaches the mapping in
either the probe failure paths or the driver remove path resulting
in an unbalanced mapping refcount and a memory leak. Fix this properly.

Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Suman Anna <s-anna@ti.com>
Tested-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: v4l2-compat-ioctl32: better document the code

This file does a lot of non-trivial struff. Document it using
kernel-doc markups where needed and improve the comments inside
do_video_ioctl().

Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: v4l2-compat-ioctl32: simplify casts

Making the cast right for get_user/put_user is not trivial, as
it needs to ensure that the types are the correct ones.

Improve it by using macros.

Tested with vivid with:
$ sudo modprobe vivid no_error_inj=1
$ v4l2-compliance-32bits -a -s10 >32bits && v4l2-compliance-64bits -a -s10 > 64bits && diff -U0 32bits 64bits
--- 32bits 2018-04-17 11:18:29.141240772 -0300
+++ 64bits 2018-04-17 11:18:40.635282341 -0300
@@ -1 +1 @@
-v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 32 bits
+v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 64 bits

Using the latest version of v4l-utils with this patch applied:
https://patchwork.linuxtv.org/patch/48746/

Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: v4l2-compat-ioctl32: better name userspace pointers

In the past, "up" were an acronym for "user pointer" and "kp" for
"kernel pointer". However, since commit a1dfb4c48cc1 ("media:
v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"), both
are now __user pointers.

So, the usage of "kp" is really misleading there. So, rename
both to just "p32" and "p64" everywhere it occurs, in order to
make peace with this file's namespace.

There are two exceptions to "up/kp" nomenclature: at
alloc_userspace() and at do_video_ioctl().

There, a new userspace pointer were allocated, in order to store
the 64 bits version of the ioctl. Those were called as "up_native",
with is, IMHO, an even worse name, as "native" could mislead of
being the arguments that were filled from userspace. I almost
renamed it to just "p64", but, after thinking more about that,
it sounded better to call it as "new_p64", as this makes clearer
that this is the data structure that was allocated inside this
file in order to be used to pass/retrieve data when calling the
64-bit ready file->f_op->unlocked_ioctl() function.

Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Suggested-by: Hans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: v4l2-compat-ioctl32: fix several __user annotations

Smatch report several issues with bad __user annotations:

  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect type in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:    expected void [noderef] <asn:1>*uptr
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:    got void *<noident>
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: warning: incorrect type in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:    expected void const volatile [noderef] <asn:1>*<noident>
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:    got struct v4l2_plane [noderef] <asn:1>**<noident>
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: warning: incorrect type in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:    expected void [noderef] <asn:1>*uptr
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:    got void *[assigned] base
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: warning: incorrect type in assignment (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:    expected struct v4l2_ext_control [noderef] <asn:1>*kcontrols
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:    got struct v4l2_ext_control *<noident>
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: warning: incorrect type in assignment (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:    expected unsigned char [usertype] *__pu_val
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:    got void [noderef] <asn:1>*
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: warning: incorrect type in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:    expected void [noderef] <asn:1>*uptr
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:    got void *[assigned] edid

Fix them.

Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: si470x: fix a typo at the Makefile causing build issues

Instead of +=, the rule had :=, with actually disables build
of everything else.

Fixes: 58757984ca3c ("media: si470x: allow build both USB and I2C at the same time")
Reported-by: Daniel Scheller <d.scheller.oss@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: ddbridge: don't uselessly check for dma in start/stop functions

The check for a valid ptr in ddb_io->dma isn't really necessary since only
devices that do data transport using DMA are supported by the driver, and
all previous initialisation code (through input_init(), output_init() and
dma_init(), has_dma is always true as it's set in ddb_probe() during
driver load) guarantees the ptr is set.

As a side effect, this silences these sparse warnings (albeit them being
false positives as ddb_io->dma won't change in these functions so the
condition always equals to the same result):

    drivers/media/pci/ddbridge/ddbridge-core.c:495:9: warning: context imbalance in 'ddb_output_start' - different lock contexts for basic block
    drivers/media/pci/ddbridge/ddbridge-core.c:510:9: warning: context imbalance in 'ddb_output_stop' - different lock contexts for basic block
    drivers/media/pci/ddbridge/ddbridge-core.c:525:9: warning: context imbalance in 'ddb_input_stop' - different lock contexts for basic block
    drivers/media/pci/ddbridge/ddbridge-core.c:560:9: warning: context imbalance in 'ddb_input_start' - different lock contexts for basic block

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: mantis: prevent staying forever in a loop at IRQ

As warned by smatch:
drivers/media/pci/mantis/mantis_uart.c:105 mantis_uart_work() warn: this loop depends on readl() succeeding

If something goes wrong at readl(), the logic will stay there
inside an IRQ code forever. This is not the nicest thing to
do :-)

So, add a timeout there, preventing staying inside the IRQ
for more than 10ms.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: st_rc: Don't stay on an IRQ handler forever

As warned by smatch:
drivers/media/rc/st_rc.c:110 st_rc_rx_interrupt() warn: this loop depends on readl() succeeding

If something goes wrong at readl(), the logic will stay there
inside an IRQ code forever. This is not the nicest thing to
do :-)

So, add a timeout there, preventing staying inside the IRQ
for more than 10ms.

Acked-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: atomisp: get rid of a warning

On smatch, this warning is trigged:

drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c:324 __bo_take_off_handling() error: we previously assumed 'bo->prev' could be null (see line 314)

Because it can't properly analize the truth table for the above
function. So, add an explicit check for the final condition there.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: atomisp: compat32: fix __user annotations

The __user annotations at the compat32 code is not right:

   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18:    expected void *base
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23:    expected unsigned int [usertype] *xcoords_y
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23:    expected unsigned int [usertype] *ycoords_y
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24:    expected unsigned int [usertype] *xcoords_uv
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24:    expected unsigned int [usertype] *ycoords_uv
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29:    expected unsigned int [usertype] *effective_width
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29:    expected unsigned int [usertype] *effective_width
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19:    expected struct v4l2_framebuffer *frame
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29:    expected unsigned short *calb_grp_values
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:701:39: warning: cast removes address space of expression
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21: warning: incorrect type in argument 1 (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21:    expected void const volatile [noderef] <asn:1>*<noident>
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21:    got unsigned int [usertype] *src
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43:    expected struct atomisp_shading_table *shading_table
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44: warning: incorrect type in argument 1 (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44:    expected void [noderef] <asn:1>*to
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44:    got struct atomisp_shading_table *shading_table
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41:    expected struct atomisp_morph_table *morph_table
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44: warning: incorrect type in argument 1 (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44:    expected void [noderef] <asn:1>*to
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44:    got struct atomisp_morph_table *morph_table
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40:    expected struct atomisp_dvs2_coefficients *dvs2_coefs
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44: warning: incorrect type in argument 1 (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44:    expected void [noderef] <asn:1>*to
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44:    got struct atomisp_dvs2_coefficients *dvs2_coefs
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46:    expected struct atomisp_dvs_6axis_config *dvs_6axis_config
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46:    got void [noderef] <asn:1>*
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44: warning: incorrect type in argument 1 (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44:    expected void [noderef] <asn:1>*to
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44:    got struct atomisp_dvs_6axis_config *dvs_6axis_config
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17: warning: incorrect type in assignment (different address spaces)
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17:    expected struct atomisp_sensor_ae_bracketing_lut_entry *lut
   drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17:    got void [noderef] <asn:1>*

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: staging: atomisp: add missing include

There are two functions used externally:
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:866:6: warning: symbol 'atomisp_do_compat_ioctl' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:1110:6: warning: symbol 'atomisp_compat_ioctl32' was not declared. Should it be static?

whose include header is missing. Add it.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: atomisp: compat32: use get_user() before referencing user data

The logic at get_atomisp_parameters32() is broken, as pointed by
smatch:

drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:21: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:744:60: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:763:21: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:770:60: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:21: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:795:60: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:812:21: warning: dereference of noderef expression
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:819:60: warning: dereference of noderef expression

It tries to access userspace data directly, without calling
get_user(). That should generate OOPS. Thankfully, the right
logic is already there (although commented out).

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: v4l2-compat-ioctl32: prevent go past max size

As warned by smatch:
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:879 put_v4l2_ext_controls32() warn: check for integer overflow 'count'

The access_ok() logic should check for too big arrays too.

Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: platform: fix some 64-bits warnings

The omap/omap3 and viu drivers are for 32 bit platforms only.
There, a pointer has 32 bits. Now that those drivers build
for 64 bits with COMPILE_TEST, they produce the following
warnings:

drivers/media/platform/omap/omap_vout_vrfb.c: In function 'omap_vout_allocate_vrfb_buffers':
drivers/media/platform/omap/omap_vout_vrfb.c:57:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   memset((void *) vout->smsshado_virt_addr[i], 0,
          ^
drivers/media/platform/fsl-viu.c: In function 'viu_setup_preview':
drivers/media/platform/fsl-viu.c:753:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  reg_val.field_base_addr = (u32)dev->ovbuf.base;
                            ^
drivers/media/platform/omap/omap_vout.c: In function 'omap_vout_get_userptr':
drivers/media/platform/omap/omap_vout.c:209:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   *physp = virt_to_phys((void *)virtp);
                         ^
drivers/media/platform/omap3isp/ispccdc.c: In function 'ccdc_config':
drivers/media/platform/omap3isp/ispccdc.c:738:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
         (__force void __user *)fpc.fpcaddr,
         ^

Add some typecasts to remove those warnings when building for
64 bits.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: atomisp: remove an impossible condition

Changeset dc9f65cf9aea ("media: staging: atomisp: avoid a warning if 32
bits build") was meant to solve an impossible condition when building
with 32 bits. It turns that this impossible condition also happens wit
64 bits:
drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:698 gmin_get_config_var() warn: impossible condition '(*out_len > (~0)) => (0-u64max > u64max)'

After a further analysis, this condition will always be false as, on
all architectures, size_t doesn't have more bits than unsigned long.

Also, the only two archs that really matter are x86 and x86_64, as this
driver doesn't build on other archs (as it depends on X86-specific UEFI
support).

So, just drop the useless code.

Fixes: dc9f65cf9aea ("media: staging: atomisp: avoid a warning if 32 bits build")

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: cec: fix smatch error

drivers/media/cec/cec-pin-error-inj.c:231
cec_pin_error_inj_parse_line() error: uninitialized symbol 'pos'.

The tx-add-bytes command didn't check for the presence of an argument, and
also didn't check that it was > 0.

This should fix this error.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: v4l2-fwnode: simplify v4l2_fwnode_reference_parse_int_props()

The logic at v4l2_fwnode_reference_parse_int_props() is somewhat
complex and violates Linux coding style, as it does multiple
statements on a single line. That makes static analyzers to
be confused, as warned by smatch:

drivers/media/v4l2-core/v4l2-fwnode.c:832 v4l2_fwnode_reference_parse_int_props() warn: passing zero to 'PTR_ERR'

Simplify the logic, in order to make clearer about what happens
when v4l2_fwnode_reference_get_int_prop() returns an error.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: dvb_frontend: fix locking issues at dvb_frontend_get_event()

As warned by smatch:
drivers/media/dvb-core/dvb_frontend.c:314 dvb_frontend_get_event() warn: inconsistent returns 'sem:&fepriv->sem'.
  Locked on:   line 288
               line 295
               line 306
               line 314
  Unlocked on: line 303

The lock implementation for get event is wrong, as, if an
interrupt occurs, down_interruptible() will fail, and the
routine will call up() twice when userspace calls the ioctl
again.

The bad code is there since when Linux migrated to git, in
2005.

Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: staging: atomisp: fix string comparation logic

it makes no sense to use strncmp() with a size with is
bigger than the string we're comparing with.

Fix those warnings:

    drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c:776 atomisp_open() error: strncmp() '"ATOMISP ISP ACC"' too small (16 vs 32)
    drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c:913 atomisp_release() error: strncmp() '"ATOMISP ISP ACC"' too small (16 vs 32)
    drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c:2751 atomisp_vidioc_default() error: strncmp() '"ATOMISP ISP ACC"' too small (16 vs 32)

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: atomisp: fix __user annotations

There are lots of troubles with atomisp __user annotations. Fix them.

drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c:357:49: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c:357:49:    expected void *userptr
drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c:357:49:    got void [noderef] <asn:1>*user_ptr
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:3302:43: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:3302:43:    expected void const [noderef] <asn:1>*from
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:3302:43:    got void const *from
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4070:58: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4070:58:    expected void const *from
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4070:58:    got unsigned short [noderef] <asn:1>*<noident>
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4082:58: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4082:58:    expected void const *from
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:4082:58:    got unsigned short [noderef] <asn:1>*<noident>
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62:    expected void const [noderef] <asn:1>*from
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62:    got unsigned short [usertype] *<noident>

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: staging: atomisp: don't declare the same vars as both private and public

The mmu_private.h header is included at mmu.c, with duplicates the
already existing definitions at mmu_public.h.

Fix this by removing the erroneous header file.

Solve those issues:

    drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:24:26: warning: function 'mmu_reg_store' with external linkage has definition
    drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:35:30: warning: function 'mmu_reg_load' with external linkage has definition
    drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:24:26: warning: function 'mmu_reg_store' with external linkage has definition
    drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:35:30: warning: function 'mmu_reg_load' with external linkage has definition

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: staging: atomisp: fix number conversion

smatch says that there's an issue with number
conversion:

   drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:4154 sh_css_params_write_to_ddr_internal() warn: '((-(1 << ((14 - 1)))))' 4294959104 can't fit into 32767 'converted_macc_table.data[idx]'
   drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:4157 sh_css_params_write_to_ddr_internal() warn: '((-(1 << ((14 - 1)))))' 4294959104 can't fit into 32767 'converted_macc_table.data[idx + 1]'
   drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:4160 sh_css_params_write_to_ddr_internal() warn: '((-(1 << ((14 - 1)))))' 4294959104 can't fit into 32767 'converted_macc_table.data[idx + 2]'
   drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_params.c:4163 sh_css_params_write_to_ddr_internal() warn: '((-(1 << ((14 - 1)))))' 4294959104 can't fit into 32767 'converted_macc_table.data[idx + 3]'
   drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c:168 ia_css_eed1_8_vmem_encode() warn: assigning (-8192) to unsigned variable 'to->e_dew_enh_a[0][base + j]'

That's probably because min() and max() definition used there
are really poor ones. So, replace by the in-kernel macro.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: omap_vout: fix wrong identing

As warned:
drivers/media/platform/omap/omap_vout.c:711 omap_vout_buffer_setup() warn: inconsistent indenting

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: fsl-viu: fix __iomem annotations

Those annotations are wrong, causing this warning:

    drivers/media/platform/fsl-viu.c:1440:21: warning: incorrect type in assignment (different address spaces)
    drivers/media/platform/fsl-viu.c:1440:21:    expected struct viu_reg *vr
    drivers/media/platform/fsl-viu.c:1440:21:    got struct viu_reg [noderef] <asn:2>*[assigned] viu_regs

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: fsl-viu: use %p to print pointers

Solve those warnings:

    drivers/media/platform/fsl-viu.c:299 restart_video_queue() warn: argument 3 to %08lx specifier is cast from pointer
    drivers/media/platform/fsl-viu.c:506 buffer_queue() warn: argument 2 to %08lx specifier is cast from pointer
    drivers/media/platform/fsl-viu.c:518 buffer_queue() warn: argument 2 to %08lx specifier is cast from pointer
    drivers/media/platform/fsl-viu.c:528 buffer_queue() warn: argument 2 to %08lx specifier is cast from pointer
    drivers/media/platform/fsl-viu.c:1219 viu_open() warn: argument 2 to %08lx specifier is cast from pointer
    drivers/media/platform/fsl-viu.c:1219 viu_open() warn: argument 3 to %08lx specifier is cast from pointer
    drivers/media/platform/fsl-viu.c:1219 viu_open() warn: argument 4 to %08lx specifier is cast from pointer
    drivers/media/platform/fsl-viu.c:1329 viu_mmap() warn: argument 2 to %08lx specifier is cast from pointer
    drivers/media/platform/fsl-viu.c:1334 viu_mmap() warn: argument 2 to %08lx specifier is cast from pointer

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: isppreview: fix __user annotations

The 'from' variable at preview_config() expects an __user * type.

However, the logic there does:

    from = *(void * __user *) ((void *)cfg + attr->config_offset);

With actually means a void pointer, pointing to a void __ user
pointer. When the first pointer is de-referenced with *(foo),
the type it returns is "void *" instead of "void __user *".

Change it to:
    from = *(void __user **) ((void *)cfg + attr->config_offset);

in order to obtain, when de-referenced, a void __user pointer,
as desired.

That prevent those warnings:
   drivers/media/platform/omap3isp/isppreview.c:893:45: warning: incorrect type in initializer (different address spaces)
   drivers/media/platform/omap3isp/isppreview.c:893:45:    expected void [noderef] <asn:1>*from
   drivers/media/platform/omap3isp/isppreview.c:893:45:    got void *[noderef] <asn:1><noident>
   drivers/media/platform/omap3isp/isppreview.c:893:47: warning: dereference of noderef expression

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: ispstat: use %p to print the address of a buffer

Instead of converting to int, use %p. That prevents this
warning:
drivers/media/platform/omap3isp/ispstat.c:451 isp_stat_bufs_alloc() warn: argument 7 to %08lx specifier is cast from pointer

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: vpbe_display: get rid of warnings

Solve those warnings:

    drivers/media/platform/davinci/vpbe_display.c:288 vpbe_start_streaming() warn: inconsistent indenting
    drivers/media/platform/davinci/vpbe_display.c:1356 register_device() warn: argument 3 to %x specifier is cast from pointer
    drivers/media/platform/davinci/vpbe_display.c:1356 register_device() warn: argument 4 to %x specifier is cast from pointer

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: vpbe_display: properly handle error case

if v4l2_subdev_call(..., VENC_GET_FLD,...) fails, it
currently returns a random value. Instead, return 1.

That's probably better than returning 0, as this is very
likely what happens in practice with the current code, as
as the probably of an unititialized 32 bits integer to
have an specific value (0, in this case), is 1/(2^32).

An alternative would be to return an error code, and
let the caller to hint, based on the past received
frame, but that sounds weird.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: mmp-driver: add needed __iomem marks to power_regs

Solve those warnings:

    drivers/media/platform/marvell-ccic/mmp-driver.c:135:41: warning: incorrect type in argument 2 (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:135:41:    expected void [noderef] <asn:2>*<noident>
    drivers/media/platform/marvell-ccic/mmp-driver.c:135:41:    got void *
    drivers/media/platform/marvell-ccic/mmp-driver.c:136:44: warning: incorrect type in argument 2 (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:136:44:    expected void [noderef] <asn:2>*<noident>
    drivers/media/platform/marvell-ccic/mmp-driver.c:136:44:    got void *
    drivers/media/platform/marvell-ccic/mmp-driver.c:174:38: warning: incorrect type in argument 2 (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:174:38:    expected void [noderef] <asn:2>*<noident>
    drivers/media/platform/marvell-ccic/mmp-driver.c:174:38:    got void *
    drivers/media/platform/marvell-ccic/mmp-driver.c:175:38: warning: incorrect type in argument 2 (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:175:38:    expected void [noderef] <asn:2>*<noident>
    drivers/media/platform/marvell-ccic/mmp-driver.c:175:38:    got void *
    drivers/media/platform/marvell-ccic/mmp-driver.c:195:48: warning: incorrect type in argument 1 (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:195:48:    expected void [noderef] <asn:2>*<noident>
    drivers/media/platform/marvell-ccic/mmp-driver.c:195:48:    got void *
    drivers/media/platform/marvell-ccic/mmp-driver.c:196:55: warning: incorrect type in argument 2 (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:196:55:    expected void [noderef] <asn:2>*<noident>
    drivers/media/platform/marvell-ccic/mmp-driver.c:196:55:    got void *
    drivers/media/platform/marvell-ccic/mmp-driver.c:197:54: warning: incorrect type in argument 2 (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:197:54:    expected void [noderef] <asn:2>*<noident>
    drivers/media/platform/marvell-ccic/mmp-driver.c:197:54:    got void *
    drivers/media/platform/marvell-ccic/mmp-driver.c:202:48: warning: incorrect type in argument 1 (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:202:48:    expected void [noderef] <asn:2>*<noident>
    drivers/media/platform/marvell-ccic/mmp-driver.c:202:48:    got void *
    drivers/media/platform/marvell-ccic/mmp-driver.c:203:55: warning: incorrect type in argument 2 (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:203:55:    expected void [noderef] <asn:2>*<noident>
    drivers/media/platform/marvell-ccic/mmp-driver.c:203:55:    got void *
    drivers/media/platform/marvell-ccic/mmp-driver.c:204:54: warning: incorrect type in argument 2 (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:204:54:    expected void [noderef] <asn:2>*<noident>
    drivers/media/platform/marvell-ccic/mmp-driver.c:204:54:    got void *
    drivers/media/platform/marvell-ccic/mmp-driver.c:389:25: warning: incorrect type in assignment (different address spaces)
    drivers/media/platform/marvell-ccic/mmp-driver.c:389:25:    expected void *power_regs
    drivers/media/platform/marvell-ccic/mmp-driver.c:389:25:    got void [noderef] <asn:2>*

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci: fix an inconsistent ident

drivers/media/platform/davinci/vpbe_osd.c:849 try_layer_config() warn: inconsistent indenting

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: isif: reorder a statement to match coding style

On all places, we do:
void <asn_ref> *foo;

Here, it is doing, instead:
void * <asn_ref> foo;

That tricks static analyzers, making it see errors where
there's none. So, just reorder in order to cleanup those
warnings:

    drivers/media/platform/davinci/isif.c:1066:22: warning: incorrect type in assignment (different address spaces)
    drivers/media/platform/davinci/isif.c:1066:22:    expected void *[noderef] <asn:2>addr
    drivers/media/platform/davinci/isif.c:1066:22:    got void [noderef] <asn:2>*
    drivers/media/platform/davinci/isif.c:1074:44: warning: incorrect type in assignment (different address spaces)
    drivers/media/platform/davinci/isif.c:1074:44:    expected void [noderef] <asn:2>*static [toplevel] [assigned] base_addr
    drivers/media/platform/davinci/isif.c:1074:44:    got void *[noderef] <asn:2>addr
    drivers/media/platform/davinci/isif.c:1078:51: warning: incorrect type in assignment (different address spaces)
    drivers/media/platform/davinci/isif.c:1078:51:    expected void [noderef] <asn:2>*static [toplevel] [assigned] linear_tbl0_addr
    drivers/media/platform/davinci/isif.c:1078:51:    got void *[noderef] <asn:2>addr
    drivers/media/platform/davinci/isif.c:1082:51: warning: incorrect type in assignment (different address spaces)
    drivers/media/platform/davinci/isif.c:1082:51:    expected void [noderef] <asn:2>*static [toplevel] [assigned] linear_tbl1_addr
    drivers/media/platform/davinci/isif.c:1082:51:    got void *[noderef] <asn:2>addr
    drivers/media/platform/davinci/isif.c:1067:22: warning: dereference of noderef expression

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: si470x: fix __be16 annotations

The annotations there are wrong as warned:
   drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16
   drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16
   drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16
   drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16
   drivers/media/radio/si470x/radio-si470x-i2c.c:129:24: warning: incorrect type in assignment (different base types)
   drivers/media/radio/si470x/radio-si470x-i2c.c:129:24:    expected unsigned short [unsigned] [short] <noident>
   drivers/media/radio/si470x/radio-si470x-i2c.c:129:24:    got restricted __be16 [usertype] <noident>
   drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16
   drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16
   drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16
   drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci_vpfe: fix __user annotations

The __user annotations on this driver are wrong, causing lots
of warnings:

    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1269:22: warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1269:22:    expected void [noderef] <asn:1>*from
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1269:22:    got void *[noderef] <asn:1><noident>
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1313:20: warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1313:20:    expected void [noderef] <asn:1>*to
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1313:20:    got void *[noderef] <asn:1><noident>
    drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:424:41: warning: incorrect type in initializer (different address spaces)
    drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:424:41:    expected struct ipipeif_params *config
    drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:424:41:    got void [noderef] <asn:1>*arg
    drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:474:46: warning: incorrect type in argument 2 (different address spaces)
    drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:474:46:    expected void [noderef] <asn:1>*arg
    drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:474:46:    got void *arg
    drivers/staging/media/davinci_vpfe/dm365_resizer.c:922:32: warning: incorrect type in argument 2 (different address spaces)
    drivers/staging/media/davinci_vpfe/dm365_resizer.c:922:32:    expected void const [noderef] <asn:1>*from
    drivers/staging/media/davinci_vpfe/dm365_resizer.c:922:32:    got struct vpfe_rsz_config_params *config
    drivers/staging/media/davinci_vpfe/dm365_resizer.c:945:27: warning: incorrect type in argument 1 (different address spaces)
    drivers/staging/media/davinci_vpfe/dm365_resizer.c:945:27:    expected void [noderef] <asn:1>*to
    drivers/staging/media/davinci_vpfe/dm365_resizer.c:945:27:    got void *<noident>

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci_vpfe: cleanup ipipe_[g|s]_config logic

Reduce one ident level inside those functions and use BIT()
macro.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci_vpfe: fix a typo for "default"

resizer_set_defualt_configuration -> resizer_set_default_configuration

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci_vpfe: don't use kernel-doc markup for simple comments

Fix those two warnings:
   drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c:90: warning: Function parameter or member 'interface' not described in 'MODULE_PARM_DESC'
   drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c:90: warning: Function parameter or member '(default' not described in 'MODULE_PARM_DESC'

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci_vpfe: vpfe_video: remove an unused var

as warned:

  drivers/staging/media/davinci_vpfe/vpfe_video.c: In function 'vpfe_streamon':
  drivers/staging/media/davinci_vpfe/vpfe_video.c:1471:31: warning: variable 'sdinfo' set but not used [-Wunused-but-set-variable]
    struct vpfe_ext_subdev_info *sdinfo;
                               ^~~~~~

While here, cleanup this kernel-doc warning:

  drivers/staging/media/davinci_vpfe/vpfe_video.c:225: warning: Function parameter or member 'pipe' not described in 'vpfe_video_validate_pipeline'

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci_vpfe: get rid of an unused var at dm365_isif.c

Not sure what was the original idea here, but the implementation
went into a different way, and the fmt var is not used
anymore, as warned:

drivers/staging/media/davinci_vpfe/dm365_isif.c: In function '__isif_get_format':
drivers/staging/media/davinci_vpfe/dm365_isif.c:1401:29: warning: variable 'fmt' set but not used [-Wunused-but-set-variable]
   struct v4l2_subdev_format fmt;
                             ^~~

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci_vpfe: mark __iomem as such

There are several usages of an __iomem memory that aren't
marked as such, causing those warnings:

drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:201:27: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:201:27:    expected void *ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:201:27:    got void [noderef] <asn:2>*ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27:    expected void const volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27:    expected void const volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:510:42: warning: incorrect type in initializer (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:510:42:    expected void *ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:510:42:    got void [noderef] <asn:2>*ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27:    expected void const volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:71:27:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:797:42: warning: incorrect type in initializer (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:797:42:    expected void *ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:797:42:    got void [noderef] <asn:2>*ipipeif_base_addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    expected void volatile [noderef] <asn:2>*addr
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:76:26:    got void *

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci_vpfe: fix vpfe_ipipe_init() error handling

As warned:
drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1834 vpfe_ipipe_init() error: we previously assumed 'res' could be null (see line 1797)

There's something wrong at vpfe_ipipe_init():

1) it caches the resourse_size() from from the first region
   and reuses to the second region;

2) the "res" var is overridden 3 times;

3) at free logic, it assumes that "res->start" is not
   overridden by platform_get_resource(pdev, IORESOURCE_MEM, 6),
   but that's not true, as it can even be NULL there.

This patch fixes the above issues by:

a) store the resources used by release_mem_region() on
   a separate var;

b) stop caching resource_size(), using the function where
   needed.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: dm365_ipipe: remove an unused var

drivers/staging/media/davinci_vpfe/dm365_ipipe.c:74:17: warning: variable 'dev' set but not used [-Wunused-but-set-variable]
  struct device *dev;
                 ^~~

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci_vpfe: remove useless checks from ipipe

The dm365_ipipe_hw.c and dm365_ipipe.c file check if several table
pointers, declared at davinci_vpfe_user.h, are filled before using
them.

The problem is that those pointers come from struct declarations
like:

struct vpfe_ipipe_yee {
...
short table[VPFE_IPIPE_MAX_SIZE_YEE_LUT];
};

So, they can't be NULL! Solve those warnings:

    drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:433 ipipe_set_lutdpc_regs() warn: this array is probably non-NULL. 'dpc->table'
    drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:763 ipipe_set_gamma_regs() warn: this array is probably non-NULL. 'gamma->table_r'
    drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:766 ipipe_set_gamma_regs() warn: this array is probably non-NULL. 'gamma->table_b'
    drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:769 ipipe_set_gamma_regs() warn: this array is probably non-NULL. 'gamma->table_g'
    drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:791 ipipe_set_3d_lut_regs() warn: this array is probably non-NULL. 'lut_3d->table'
    drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:903 ipipe_set_gbce_regs() warn: this array is probably non-NULL. 'gbce->table'
    drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c:946 ipipe_set_ee_regs() warn: this array is probably non-NULL. 'ee->table'
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:59 ipipe_validate_lutdpc_params() warn: this array is probably non-NULL. 'lutdpc->table'
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:697 ipipe_get_gamma_params() warn: this array is probably non-NULL. 'gamma_param->table_r'
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:705 ipipe_get_gamma_params() warn: this array is probably non-NULL. 'gamma_param->table_g'
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:712 ipipe_get_gamma_params() warn: this array is probably non-NULL. 'gamma_param->table_b'
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:745 ipipe_get_3d_lut_params() warn: this array is probably non-NULL. 'lut_param->table'
    drivers/staging/media/davinci_vpfe/dm365_ipipe.c:926 ipipe_get_gbce_params() warn: this array is probably non-NULL. 'gbce_param->table'

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: staging: davinci_vpfe: allow building with COMPILE_TEST

This is a little bit hashish, but this driver is at staging,
so it won't become worse.

With this small change at Makefile, we can now build it with
COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: si470x: allow build both USB and I2C at the same time

Currently, either USB or I2C is built. Change it to allow
having both enabled at the same time.

The main reason is that COMPILE_TEST all[yes/mod]builds will
now contain all drivers under drivers/media.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: omap4iss: make it build with COMPILE_TEST

This driver compile as-is with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: omap: allow building it with COMPILE_TEST

Now that we have stubs for omap FB driver, let it build with
COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: omap2: omapfb: allow building it with COMPILE_TEST

This driver builds cleanly with COMPILE_TEST, and it is
needed in order to allow building drivers/media omap2
driver.

So, change the logic there to allow building it.

Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci: get rid of lots of kernel-doc warnings

Driver build produce lots of warnings due to wrong kernel-doc markups:

    drivers/media/platform/davinci/vpbe.c:60: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_current_encoder_info'
    drivers/media/platform/davinci/vpbe.c:78: warning: Function parameter or member 'cfg' not described in 'vpbe_find_encoder_sd_index'
    drivers/media/platform/davinci/vpbe.c:78: warning: Function parameter or member 'index' not described in 'vpbe_find_encoder_sd_index'
    drivers/media/platform/davinci/vpbe.c:105: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_g_cropcap'
    drivers/media/platform/davinci/vpbe.c:105: warning: Function parameter or member 'cropcap' not described in 'vpbe_g_cropcap'
    drivers/media/platform/davinci/vpbe.c:127: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_enum_outputs'
    drivers/media/platform/davinci/vpbe.c:127: warning: Function parameter or member 'output' not described in 'vpbe_enum_outputs'
    drivers/media/platform/davinci/vpbe.c:221: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_set_output'
    drivers/media/platform/davinci/vpbe.c:221: warning: Function parameter or member 'index' not described in 'vpbe_set_output'
    drivers/media/platform/davinci/vpbe.c:316: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_get_output'
    drivers/media/platform/davinci/vpbe.c:328: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_s_dv_timings'
    drivers/media/platform/davinci/vpbe.c:328: warning: Function parameter or member 'dv_timings' not described in 'vpbe_s_dv_timings'
    drivers/media/platform/davinci/vpbe.c:380: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_g_dv_timings'
    drivers/media/platform/davinci/vpbe.c:380: warning: Function parameter or member 'dv_timings' not described in 'vpbe_g_dv_timings'
    drivers/media/platform/davinci/vpbe.c:405: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_enum_dv_timings'
    drivers/media/platform/davinci/vpbe.c:405: warning: Function parameter or member 'timings' not described in 'vpbe_enum_dv_timings'
    drivers/media/platform/davinci/vpbe.c:436: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_s_std'
    drivers/media/platform/davinci/vpbe.c:436: warning: Function parameter or member 'std_id' not described in 'vpbe_s_std'
    drivers/media/platform/davinci/vpbe.c:475: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_g_std'
    drivers/media/platform/davinci/vpbe.c:475: warning: Function parameter or member 'std_id' not described in 'vpbe_g_std'
    drivers/media/platform/davinci/vpbe.c:500: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_set_mode'
    drivers/media/platform/davinci/vpbe.c:500: warning: Function parameter or member 'mode_info' not described in 'vpbe_set_mode'
    drivers/media/platform/davinci/vpbe.c:585: warning: Function parameter or member 'dev' not described in 'vpbe_initialize'
    drivers/media/platform/davinci/vpbe.c:585: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_initialize'
    drivers/media/platform/davinci/vpbe.c:779: warning: Function parameter or member 'dev' not described in 'vpbe_deinitialize'
    drivers/media/platform/davinci/vpbe.c:779: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_deinitialize'
    drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter or member 'sd' not described in '_osd_dm6446_vid0_pingpong'
    drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter or member 'field_inversion' not described in '_osd_dm6446_vid0_pingpong'
    drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter or member 'fb_base_phys' not described in '_osd_dm6446_vid0_pingpong'
    drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter or member 'lconfig' not described in '_osd_dm6446_vid0_pingpong'
    drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter or member 'sd' not described in 'try_layer_config'
    drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter or member 'layer' not described in 'try_layer_config'
    drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter or member 'lconfig' not described in 'try_layer_config'
    drivers/media/platform/davinci/vpbe_display.c:578: warning: Function parameter or member 'disp_dev' not described in 'vpbe_try_format'
    drivers/media/platform/davinci/vpbe_display.c:578: warning: Function parameter or member 'pixfmt' not described in 'vpbe_try_format'
    drivers/media/platform/davinci/vpbe_display.c:578: warning: Function parameter or member 'check' not described in 'vpbe_try_format'
    drivers/media/platform/davinci/vpbe_display.c:943: warning: Function parameter or member 'file' not described in 'vpbe_display_s_std'
    drivers/media/platform/davinci/vpbe_display.c:943: warning: Function parameter or member 'priv' not described in 'vpbe_display_s_std'
    drivers/media/platform/davinci/vpbe_display.c:943: warning: Function parameter or member 'std_id' not described in 'vpbe_display_s_std'
    drivers/media/platform/davinci/vpbe_display.c:975: warning: Function parameter or member 'file' not described in 'vpbe_display_g_std'
    drivers/media/platform/davinci/vpbe_display.c:975: warning: Function parameter or member 'priv' not described in 'vpbe_display_g_std'
    drivers/media/platform/davinci/vpbe_display.c:975: warning: Function parameter or member 'std_id' not described in 'vpbe_display_g_std'
    drivers/media/platform/davinci/vpbe_display.c:998: warning: Function parameter or member 'file' not described in 'vpbe_display_enum_output'
    drivers/media/platform/davinci/vpbe_display.c:998: warning: Function parameter or member 'priv' not described in 'vpbe_display_enum_output'
    drivers/media/platform/davinci/vpbe_display.c:998: warning: Function parameter or member 'output' not described in 'vpbe_display_enum_output'
    drivers/media/platform/davinci/vpbe_display.c:1025: warning: Function parameter or member 'file' not described in 'vpbe_display_s_output'
    drivers/media/platform/davinci/vpbe_display.c:1025: warning: Function parameter or member 'priv' not described in 'vpbe_display_s_output'
    drivers/media/platform/davinci/vpbe_display.c:1025: warning: Function parameter or member 'i' not described in 'vpbe_display_s_output'
    drivers/media/platform/davinci/vpbe_display.c:1054: warning: Function parameter or member 'file' not described in 'vpbe_display_g_output'
    drivers/media/platform/davinci/vpbe_display.c:1054: warning: Function parameter or member 'priv' not described in 'vpbe_display_g_output'
    drivers/media/platform/davinci/vpbe_display.c:1054: warning: Function parameter or member 'i' not described in 'vpbe_display_g_output'
    drivers/media/platform/davinci/vpbe_display.c:1074: warning: Function parameter or member 'file' not described in 'vpbe_display_enum_dv_timings'
    drivers/media/platform/davinci/vpbe_display.c:1074: warning: Function parameter or member 'priv' not described in 'vpbe_display_enum_dv_timings'
    drivers/media/platform/davinci/vpbe_display.c:1074: warning: Function parameter or member 'timings' not described in 'vpbe_display_enum_dv_timings'
    drivers/media/platform/davinci/vpbe_display.c:1104: warning: Function parameter or member 'file' not described in 'vpbe_display_s_dv_timings'
    drivers/media/platform/davinci/vpbe_display.c:1104: warning: Function parameter or member 'priv' not described in 'vpbe_display_s_dv_timings'
    drivers/media/platform/davinci/vpbe_display.c:1104: warning: Function parameter or member 'timings' not described in 'vpbe_display_s_dv_timings'
    drivers/media/platform/davinci/vpbe_display.c:1137: warning: Function parameter or member 'file' not described in 'vpbe_display_g_dv_timings'
    drivers/media/platform/davinci/vpbe_display.c:1137: warning: Function parameter or member 'priv' not described in 'vpbe_display_g_dv_timings'
    drivers/media/platform/davinci/vpbe_display.c:1137: warning: Function parameter or member 'dv_timings' not described in 'vpbe_display_g_dv_timings'

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: vpbe_venc: don't store return codes if they won't be used

Fix those two warnings

drivers/media/platform/davinci/vpbe_venc.c: In function ‘venc_set_ntsc’:
drivers/media/platform/davinci/vpbe_venc.c:230:6: warning: variable ‘val’ set but not used [-Wunused-but-set-variable]
  u32 val;
      ^~~
drivers/media/platform/davinci/vpbe_venc.c: In function ‘venc_sub_dev_init’:
drivers/media/platform/davinci/vpbe_venc.c:611:6: warning: variable ‘err’ set but not used [-Wunused-but-set-variable]
  int err;
      ^~~
  AR      drivers/media/platform/davinci/built-in.a

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci: allow build vpbe_display with COMPILE_TEST

Except for some includes (with doesn't seem to be used), this
driver builds fine with COMPILE_TEST.

So, add checks there to avoid building it if ARCH_DAVINCI
is not selected.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: davinci: allow building isif code

The only reason why this driver doesn't build with COMPILE_TEST
is because it includes mach/mux.h. It turns that none of the
macros defined there are used.

So, get rid of it, in order to allow it to build with
COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: mmp-driver: make two functions static

Those functions are used only internally:

  CC      drivers/media/platform/marvell-ccic/mmp-driver.o
drivers/media/platform/marvell-ccic/mmp-driver.c:186:6: warning: no previous prototype for ‘mcam_ctlr_reset’ [-Wmissing-prototypes]
 void mcam_ctlr_reset(struct mcam_camera *mcam)
      ^~~~~~~~~~~~~~~
drivers/media/platform/marvell-ccic/mmp-driver.c:217:6: warning: no previous prototype for ‘mmpcam_calc_dphy’ [-Wmissing-prototypes]
 void mmpcam_calc_dphy(struct mcam_camera *mcam)
      ^~~~~~~~~~~~~~~~

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: marvel-ccic: re-enable mmp-driver build

This driver was disabled back in 2015 from builds because
of some troubles with the platform_data definition. Now
that this got fixed, re-enable it.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: mmp-camera.h: add missing platform data

Those definitions used to be part of the original patch:
https://patchwork.kernel.org/patch/2815221/

But, somehow, nobody ever noticed until today. Years later,
Arnd discovered that mmp-camera driver doesn't build and make
it depend on BROKEN.

Add the missing bits here, in order to remove BROKEN dependency.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: exymos4-is: allow compile test for EXYNOS FIMC-LITE

There's nothing that prevents building this driver with
COMPILE_TEST. So, enable it.

While here, make the Kconfig dependency cleaner by removing
the unneeded if block.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: cec_gpio: allow building CEC_GPIO with COMPILE_TEST

At least on i386, building with allyesconfig doesn't enable
PREEMPT, causing cec_gpio to not build.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: fsl-viu: allow building it with COMPILE_TEST

There aren't many things that would be needed to allow it
to build with compile test.

Add the needed bits.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: fsl-viu: mark static functions as such

There are several functions that are used only inside the
driver. Stop exposing that to global symbolspace.

Get rid of the following gcc warnings:

drivers/media/platform/fsl-viu.c:240:17: warning: no previous prototype for ‘format_by_fourcc’ [-Wmissing-prototypes]
 struct viu_fmt *format_by_fourcc(int fourcc)
                 ^~~~~~~~~~~~~~~~
drivers/media/platform/fsl-viu.c:253:6: warning: no previous prototype for ‘viu_start_dma’ [-Wmissing-prototypes]
 void viu_start_dma(struct viu_dev *dev)
      ^~~~~~~~~~~~~
drivers/media/platform/fsl-viu.c:262:6: warning: no previous prototype for ‘viu_stop_dma’ [-Wmissing-prototypes]
 void viu_stop_dma(struct viu_dev *dev)
      ^~~~~~~~~~~~
drivers/media/platform/fsl-viu.c:807:5: warning: no previous prototype for ‘vidioc_g_fbuf’ [-Wmissing-prototypes]
 int vidioc_g_fbuf(struct file *file, void *priv, struct v4l2_framebuffer *arg)
     ^~~~~~~~~~~~~
drivers/media/platform/fsl-viu.c:818:5: warning: no previous prototype for ‘vidioc_s_fbuf’ [-Wmissing-prototypes]
 int vidioc_s_fbuf(struct file *file, void *priv, const struct v4l2_framebuffer *arg)
     ^~~~~~~~~~~~~
drivers/media/platform/fsl-viu.c: In function ‘viu_open’:
drivers/media/platform/fsl-viu.c:1170:6: warning: variable ‘status_cfg’ set but not used [-Wunused-but-set-variable]
  u32 status_cfg;
      ^~~~~~~~~~
drivers/media/platform/fsl-viu.c: At top level:
drivers/media/platform/fsl-viu.c:1304:6: warning: no previous prototype for ‘viu_reset’ [-Wmissing-prototypes]
 void viu_reset(struct viu_reg *reg)
      ^~~~~~~~~

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: omap3isp/isp: remove an unused static var

The isp_xclk_init_data const data isn't used anywere.

drivers/media/platform/omap3isp/isp.c:294:35: warning: ‘isp_xclk_init_data’ defined but not used [-Wunused-const-variable=]
 static const struct clk_init_data isp_xclk_init_data = {
                                   ^~~~~~~~~~~~~~~~~~

Fixes: 9b28ee3c9122 ("[media] omap3isp: Use the common clock framework")

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

Linux 4.17-rc1

Merge tag 'for-4.17-part2-tag' of git://git./linux/kernel/git/kdave/linux

Pull more btrfs updates from David Sterba:
 "We have queued a few more fixes (error handling, log replay,
  softlockup) and the rest is SPDX updates that touche almost all files
  so the diffstat is long"

* tag 'for-4.17-part2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: Only check first key for committed tree blocks
  btrfs: add SPDX header to Kconfig
  btrfs: replace GPL boilerplate by SPDX -- sources
  btrfs: replace GPL boilerplate by SPDX -- headers
  Btrfs: fix loss of prealloc extents past i_size after fsync log replay
  Btrfs: clean up resources during umount after trans is aborted
  btrfs: Fix possible softlock on single core machines
  Btrfs: bail out on error during replay_dir_deletes
  Btrfs: fix NULL pointer dereference in log_dir_items

Merge tag '4.17-rc1SMB3-Fixes' of git://git.samba.org/sfrench/cifs-2.6

Pull cifs fixes from Steve French:
 "SMB3 fixes, a few for stable, and some important cleanup work from
  Ronnie of the smb3 transport code"

* tag '4.17-rc1SMB3-Fixes' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: change validate_buf to validate_iov
  cifs: remove rfc1002 hardcoded constants from cifs_discard_remaining_data()
  cifs: Change SMB2_open to return an iov for the error parameter
  cifs: add resp_buf_size to the mid_q_entry structure
  smb3.11: replace a 4 with server->vals->header_preamble_size
  cifs: replace a 4 with server->vals->header_preamble_size
  cifs: add pdu_size to the TCP_Server_Info structure
  SMB311: Improve checking of negotiate security contexts
  SMB3: Fix length checking of SMB3.11 negotiate request
  CIFS: add ONCE flag for cifs_dbg type
  cifs: Use ULL suffix for 64-bit constant
  SMB3: Log at least once if tree connect fails during reconnect
  cifs: smb2pdu: Fix potential NULL pointer dereference

Merge tag 'scsi-fixes' of git://git./linux/kernel/git/jejb/scsi

Pull SCSI fixes from James Bottomley:
 "This is a set of minor (and safe changes) that didn't make the initial
  pull request plus some bug fixes.

  The status handling code is actually a running regression from the
  previous merge window which had an incomplete fix (now reverted) and
  most of the remaining bug fixes are for problems older than the
  current merge window"

[ Side note: this merge also takes the base kernel git repository to 6+
  million objects for the first time. Technically we hit it a couple of
  merges ago already if you count all the tag objects, but now it
  reaches 6M+ objects reachable from HEAD.

  I was joking around that that's when I should switch to 5.0, because
  3.0 happened at the 2M mark, and 4.0 happened at 4M objects. But
  probably not, even if numerology is about as good a reason as any.

                                                              - Linus ]

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: devinfo: Add Microsoft iSCSI target to 1024 sector blacklist
  scsi: cxgb4i: silence overflow warning in t4_uld_rx_handler()
  scsi: dpt_i2o: Use after free in I2ORESETCMD ioctl
  scsi: core: Make scsi_result_to_blk_status() recognize CONDITION MET
  scsi: core: Rename __scsi_error_from_host_byte() into scsi_result_to_blk_status()
  Revert "scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"
  scsi: aacraid: Insure command thread is not recursively stopped
  scsi: qla2xxx: Correct setting of SAM_STAT_CHECK_CONDITION
  scsi: qla2xxx: correctly shift host byte
  scsi: qla2xxx: Fix race condition between iocb timeout and initialisation
  scsi: qla2xxx: Avoid double completion of abort command
  scsi: qla2xxx: Fix small memory leak in qla2x00_probe_one on probe failure
  scsi: scsi_dh: Don't look for NULL devices handlers by name
  scsi: core: remove redundant assignment to shost->use_blk_mq

Merge tag 'kbuild-v4.17-2' of git://git./linux/kernel/git/masahiroy/linux-kbuild

Pull more Kbuild updates from Masahiro Yamada:

 - pass HOSTLDFLAGS when compiling single .c host programs

 - build genksyms lexer and parser files instead of using shipped
   versions

 - rename *-asn1.[ch] to *.asn1.[ch] for suffix consistency

 - let the top .gitignore globally ignore artifacts generated by flex,
   bison, and asn1_compiler

 - let the top Makefile globally clean artifacts generated by flex,
   bison, and asn1_compiler

 - use safer .SECONDARY marker instead of .PRECIOUS to prevent
   intermediate files from being removed

 - support -fmacro-prefix-map option to make __FILE__ a relative path

 - fix # escaping to prepare for the future GNU Make release

 - clean up deb-pkg by using debian tools instead of handrolled
   source/changes generation

 - improve rpm-pkg portability by supporting kernel-install as a
   fallback of new-kernel-pkg

 - extend Kconfig listnewconfig target to provide more information

* tag 'kbuild-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  kconfig: extend output of 'listnewconfig'
  kbuild: rpm-pkg: use kernel-install as a fallback for new-kernel-pkg
  Kbuild: fix # escaping in .cmd files for future Make
  kbuild: deb-pkg: split generating packaging and build
  kbuild: use -fmacro-prefix-map to make __FILE__ a relative path
  kbuild: mark $(targets) as .SECONDARY and remove .PRECIOUS markers
  kbuild: rename *-asn1.[ch] to *.asn1.[ch]
  kbuild: clean up *-asn1.[ch] patterns from top-level Makefile
  .gitignore: move *-asn1.[ch] patterns to the top-level .gitignore
  kbuild: add %.dtb.S and %.dtb to 'targets' automatically
  kbuild: add %.lex.c and %.tab.[ch] to 'targets' automatically
  genksyms: generate lexer and parser during build instead of shipping
  kbuild: clean up *.lex.c and *.tab.[ch] patterns from top-level Makefile
  .gitignore: move *.lex.c *.tab.[ch] patterns to the top-level .gitignore
  kbuild: use HOSTLDFLAGS for single .c executables

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Thomas Gleixner:
 "A set of fixes and updates for x86:

   - Address a swiotlb regression which was caused by the recent DMA
     rework and made driver fail because dma_direct_supported() returned
     false

   - Fix a signedness bug in the APIC ID validation which caused invalid
     APIC IDs to be detected as valid thereby bloating the CPU possible
     space.

   - Fix inconsisten config dependcy/select magic for the MFD_CS5535
     driver.

   - Fix a corruption of the physical address space bits when encryption
     has reduced the address space and late cpuinfo updates overwrite
     the reduced bit information with the original value.

   - Dominiks syscall rework which consolidates the architecture
     specific syscall functions so all syscalls can be wrapped with the
     same macros. This allows to switch x86/64 to struct pt_regs based
     syscalls. Extend the clearing of user space controlled registers in
     the entry patch to the lower registers"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/apic: Fix signedness bug in APIC ID validity checks
  x86/cpu: Prevent cpuinfo_x86::x86_phys_bits adjustment corruption
  x86/olpc: Fix inconsistent MFD_CS5535 configuration
  swiotlb: Use dma_direct_supported() for swiotlb_ops
  syscalls/x86: Adapt syscall_wrapper.h to the new syscall stub naming convention
  syscalls/core, syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()
  syscalls/core, syscalls/x86: Clean up compat syscall stub naming convention
  syscalls/core, syscalls/x86: Clean up syscall stub naming convention
  syscalls/x86: Extend register clearing on syscall entry to lower registers
  syscalls/x86: Unconditionally enable 'struct pt_regs' based syscalls on x86_64
  syscalls/x86: Use 'struct pt_regs' based syscall calling for IA32_EMULATION and x32
  syscalls/core: Prepare CONFIG_ARCH_HAS_SYSCALL_WRAPPER=y for compat syscalls
  syscalls/x86: Use 'struct pt_regs' based syscall calling convention for 64-bit syscalls
  syscalls/core: Introduce CONFIG_ARCH_HAS_SYSCALL_WRAPPER=y
  x86/syscalls: Don't pointlessly reload the system call number
  x86/mm: Fix documentation of module mapping range with 4-level paging
  x86/cpuid: Switch to 'static const' specifier

Merge branch 'x86-pti-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 pti updates from Thomas Gleixner:
 "Another series of PTI related changes:

   - Remove the manual stack switch for user entries from the idtentry
     code. This debloats entry by 5k+ bytes of text.

   - Use the proper types for the asm/bootparam.h defines to prevent
     user space compile errors.

   - Use PAGE_GLOBAL for !PCID systems to gain back performance

   - Prevent setting of huge PUD/PMD entries when the entries are not
     leaf entries otherwise the entries to which the PUD/PMD points to
     and are populated get lost"

* 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/pgtable: Don't set huge PUD/PMD on non-leaf entries
  x86/pti: Leave kernel text global for !PCID
  x86/pti: Never implicitly clear _PAGE_GLOBAL for kernel image
  x86/pti: Enable global pages for shared areas
  x86/mm: Do not forbid _PAGE_RW before init for __ro_after_init
  x86/mm: Comment _PAGE_GLOBAL mystery
  x86/mm: Remove extra filtering in pageattr code
  x86/mm: Do not auto-massage page protections
  x86/espfix: Document use of _PAGE_GLOBAL
  x86/mm: Introduce "default" kernel PTE mask
  x86/mm: Undo double _PAGE_PSE clearing
  x86/mm: Factor out pageattr _PAGE_GLOBAL setting
  x86/entry/64: Drop idtentry's manual stack switch for user entries
  x86/uapi: Fix asm/bootparam.h userspace compilation errors

Merge branch 'sched-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull scheduler fixes from Thomas Gleixner:
 "A few scheduler fixes:

   - Prevent a bogus warning vs. runqueue clock update flags in
     do_sched_rt_period_timer()

   - Simplify the helper functions which handle requests for skipping
     the runqueue clock updat.

   - Do not unlock the tunables mutex in the error path of the cpu
     frequency scheduler utils. Its not held.

   - Enforce proper alignement for 'struct util_est' in sched_avg to
     prevent a misalignment fault on IA64"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/core: Force proper alignment of 'struct util_est'
  sched/core: Simplify helpers for rq clock update skip requests
  sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning
  sched/cpufreq/schedutil: Fix error path mutex unlock

Merge branch 'perf-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull more perf updates from Thomas Gleixner:
 "A rather large set of perf updates:

  Kernel:

   - Fix various initialization issues

   - Prevent creating [ku]probes for not CAP_SYS_ADMIN users

  Tooling:

   - Show only failing syscalls with 'perf trace --failure' (Arnaldo
     Carvalho de Melo)

            e.g: See what 'openat' syscalls are failing:

        # perf trace --failure -e openat
         762.323 ( 0.007 ms): VideoCapture/4566 openat(dfd: CWD, filename: /dev/video2) = -1 ENOENT No such file or directory
         <SNIP N /dev/videoN open attempts... sigh, where is that improvised camera lid?!? >
         790.228 ( 0.008 ms): VideoCapture/4566 openat(dfd: CWD, filename: /dev/video63) = -1 ENOENT No such file or directory
        ^C#

   - Show information about the event (freq, nr_samples, total
     period/nr_events) in the annotate --tui and --stdio2 'perf
     annotate' output, similar to the first line in the 'perf report
     --tui', but just for the samples for a the annotated symbol
     (Arnaldo Carvalho de Melo)

   - Introduce 'perf version --build-options' to show what features were
     linked, aliased as well as a shorter 'perf -vv' (Jin Yao)

   - Add a "dso_size" sort order (Kim Phillips)

   - Remove redundant ')' in the tracepoint output in 'perf trace'
     (Changbin Du)

   - Synchronize x86's cpufeatures.h, no effect on toolss (Arnaldo
     Carvalho de Melo)

   - Show group details on the title line in the annotate browser and
     'perf annotate --stdio2' output, so that the per-event columns can
     have headers (Arnaldo Carvalho de Melo)

   - Fixup vertical line separating metrics from instructions and
     cleaning unused lines at the bottom, both in the annotate TUI
     browser (Arnaldo Carvalho de Melo)

   - Remove duplicated 'samples' in lost samples warning in
     'perf report' (Arnaldo Carvalho de Melo)

   - Synchronize i915_drm.h, silencing the perf build process,
     automagically adding support for the new DRM_I915_QUERY ioctl
     (Arnaldo Carvalho de Melo)

   - Make auxtrace_queues__add_buffer() allocate struct buffer, from a
     patchkit already applied (Adrian Hunter)

   - Fix the --stdio2/TUI annotate output to include group details, be
     it for a recorded '{a,b,f}' explicit event group or when forcing
     group display using 'perf report --group' for a set of events not
     recorded as a group (Arnaldo Carvalho de Melo)

   - Fix display artifacts in the ui browser (base class for the
     annotate and main report/top TUI browser) related to the extra
     title lines work (Arnaldo Carvalho de Melo)

   - perf auxtrace refactorings, leftovers from a previously partially
     processed patchset (Adrian Hunter)

   - Fix the builtin clang build (Sandipan Das, Arnaldo Carvalho de
     Melo)

   - Synchronize i915_drm.h, silencing a perf build warning and in the
     process automagically adding support for a new ioctl command
     (Arnaldo Carvalho de Melo)

   - Fix a strncpy issue in uprobe tracing"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (36 commits)
  perf/core: Need CAP_SYS_ADMIN to create k/uprobe with perf_event_open()
  tracing/uprobe_event: Fix strncpy corner case
  perf/core: Fix perf_uprobe_init()
  perf/core: Fix perf_kprobe_init()
  perf/core: Fix use-after-free in uprobe_perf_close()
  perf tests clang: Fix function name for clang IR test
  perf clang: Add support for recent clang versions
  perf tools: Fix perf builds with clang support
  perf tools: No need to include namespaces.h in util.h
  perf hists browser: Remove leftover from row returned from refresh
  perf hists browser: Show extra_title_lines in the 'D' debug hotkey
  perf auxtrace: Make auxtrace_queues__add_buffer() do CPU filtering
  tools headers uapi: Synchronize i915_drm.h
  perf report: Remove duplicated 'samples' in lost samples warning
  perf ui browser: Fixup cleaning unused lines at the bottom
  perf annotate browser: Fixup vertical line separating metrics from instructions
  perf annotate: Show group details on the title line
  perf auxtrace: Make auxtrace_queues__add_buffer() allocate struct buffer
  perf/x86/intel: Move regs->flags EXACT bit init
  perf trace: Remove redundant ')'
  ...

Merge branch 'efi-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 EFI bootup fixlet from Thomas Gleixner:
 "A single fix for an early boot warning caused by invoking
  this_cpu_has() before SMP initialization"

* 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mm: Fix bogus warning during EFI bootup, use boot_cpu_has() instead of this_cpu_has() in build_cr3_noflush()

Merge branch 'irq-core-for-linus' of git://git./linux/kernel/git/tip/tip

Pull irq affinity fixes from Thomas Gleixner:

  - Fix error path handling in the affinity spreading code

  - Make affinity spreading smarter to avoid issues on systems which
    claim to have hotpluggable CPUs while in fact they can't hotplug
    anything.

    So instead of trying to spread the vectors (and thereby the
    associated device queues) to all possibe CPUs, spread them on all
    present CPUs first. If there are left over vectors after that first
    step they are spread among the possible, but not present CPUs which
    keeps the code backwards compatible for virtual decives and NVME
    which allocate a queue per possible CPU, but makes the spreading
    smarter for devices which have less queues than possible or present
    CPUs.

* 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  genirq/affinity: Spread irq vectors among present CPUs as far as possible
  genirq/affinity: Allow irq spreading from a given starting point
  genirq/affinity: Move actual irq vector spreading into a helper function
  genirq/affinity: Rename *node_to_possible_cpumask as *node_to_cpumask
  genirq/affinity: Don't return with empty affinity masks on error

Merge tag 'for-linus' of git://github.com/openrisc/linux

Pull OpenRISC fixlet from Stafford Horne:
 "Just one small thing here, it came in a while back but I didnt have
  anything in my 4.16 queue, still its the only thing for 4.17 so
  sending it alone.

  Small cleanup: remove unused __ARCH_HAVE_MMU define"

* tag 'for-linus' of git://github.com/openrisc/linux:
  openrisc: remove unused __ARCH_HAVE_MMU define

Merge tag 'powerpc-4.17-2' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:

 - Fix crashes when loading modules built with a different
   CONFIG_RELOCATABLE value by adding CONFIG_RELOCATABLE to vermagic.

 - Fix busy loops in the OPAL NVRAM driver if we get certain error
   conditions from firmware.

 - Remove tlbie trace points from KVM code that's called in real mode,
   because it causes crashes.

 - Fix checkstops caused by invalid tlbiel on Power9 Radix.

 - Ensure the set of CPU features we "know" are always enabled is
   actually the minimal set when we build with support for firmware
   supplied CPU features.

Thanks to: Aneesh Kumar K.V, Anshuman Khandual, Nicholas Piggin.

* tag 'powerpc-4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/64s: Fix CPU_FTRS_ALWAYS vs DT CPU features
  powerpc/mm/radix: Fix checkstops caused by invalid tlbiel
  KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode
  powerpc/8xx: Fix build with hugetlbfs enabled
  powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops
  powerpc/powernv: define a standard delay for OPAL_BUSY type retry loops
  powerpc/fscr: Enable interrupts earlier before calling get_user()
  powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()
  powerpc/modules: Fix crashes by adding CONFIG_RELOCATABLE to vermagic

Merge branch 'akpm' (patches from Andrew)

Merge yet more updates from Andrew Morton:

 - various hotfixes

 - kexec_file updates and feature work

* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (27 commits)
  kernel/kexec_file.c: move purgatories sha256 to common code
  kernel/kexec_file.c: allow archs to set purgatory load address
  kernel/kexec_file.c: remove mis-use of sh_offset field during purgatory load
  kernel/kexec_file.c: remove unneeded variables in kexec_purgatory_setup_sechdrs
  kernel/kexec_file.c: remove unneeded for-loop in kexec_purgatory_setup_sechdrs
  kernel/kexec_file.c: split up __kexec_load_puragory
  kernel/kexec_file.c: use read-only sections in arch_kexec_apply_relocations*
  kernel/kexec_file.c: search symbols in read-only kexec_purgatory
  kernel/kexec_file.c: make purgatory_info->ehdr const
  kernel/kexec_file.c: remove checks in kexec_purgatory_load
  include/linux/kexec.h: silence compile warnings
  kexec_file, x86: move re-factored code to generic side
  x86: kexec_file: clean up prepare_elf64_headers()
  x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer
  x86: kexec_file: remove X86_64 dependency from prepare_elf64_headers()
  x86: kexec_file: purge system-ram walking from prepare_elf64_headers()
  kexec_file,x86,powerpc: factor out kexec_file_ops functions
  kexec_file: make use of purgatory optional
  proc: revalidate misc dentries
  mm, slab: reschedule cache_reap() on the same CPU
  ...

kernel/kexec_file.c: move purgatories sha256 to common code

The code to verify the new kernels sha digest is applicable for all
architectures.  Move it to common code.

One problem is the string.c implementation on x86.  Currently sha256
includes x86/boot/string.h which defines memcpy and memset to be gcc
builtins.  By moving the sha256 implementation to common code and
changing the include to linux/string.h both functions are no longer
defined.  Thus definitions have to be provided in x86/purgatory/string.c

Link: http://lkml.kernel.org/r/20180321112751.22196-12-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/kexec_file.c: allow archs to set purgatory load address

For s390 new kernels are loaded to fixed addresses in memory before they
are booted.  With the current code this is a problem as it assumes the
kernel will be loaded to an 'arbitrary' address.  In particular,
kexec_locate_mem_hole searches for a large enough memory region and sets
the load address (kexec_bufer->mem) to it.

Luckily there is a simple workaround for this problem.  By returning 1
in arch_kexec_walk_mem, kexec_locate_mem_hole is turned off.  This
allows the architecture to set kbuf->mem by hand.  While the trick works
fine for the kernel it does not for the purgatory as here the
architectures don't have access to its kexec_buffer.

Give architectures access to the purgatories kexec_buffer by changing
kexec_load_purgatory to take a pointer to it.  With this change
architectures have access to the buffer and can edit it as they need.

A nice side effect of this change is that we can get rid of the
purgatory_info->purgatory_load_address field.  As now the information
stored there can directly be accessed from kbuf->mem.

Link: http://lkml.kernel.org/r/20180321112751.22196-11-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/kexec_file.c: remove mis-use of sh_offset field during purgatory load

The current code uses the sh_offset field in purgatory_info->sechdrs to
store a pointer to the current load address of the section.  Depending
whether the section will be loaded or not this is either a pointer into
purgatory_info->purgatory_buf or kexec_purgatory.  This is not only a
violation of the ELF standard but also makes the code very hard to
understand as you cannot tell if the memory you are using is read-only
or not.

Remove this misuse and store the offset of the section in
pugaroty_info->purgatory_buf in sh_offset.

Link: http://lkml.kernel.org/r/20180321112751.22196-10-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/kexec_file.c: remove unneeded variables in kexec_purgatory_setup_sechdrs

The main loop currently uses quite a lot of variables to update the
section headers.  Some of them are unnecessary.  So clean them up a
little.

Link: http://lkml.kernel.org/r/20180321112751.22196-9-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/kexec_file.c: remove unneeded for-loop in kexec_purgatory_setup_sechdrs

To update the entry point there is an extra loop over all section
headers although this can be done in the main loop.  So move it there
and eliminate the extra loop and variable to store the 'entry section
index'.

Also, in the main loop, move the usual case, i.e.  non-bss section, out
of the extra if-block.

Link: http://lkml.kernel.org/r/20180321112751.22196-8-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/kexec_file.c: split up __kexec_load_puragory

When inspecting __kexec_load_purgatory you find that it has two tasks

1) setting up the kexec_buffer for the new kernel and,
2) setting up pi->sechdrs for the final load address.

The two tasks are independent of each other.  To improve readability
split up __kexec_load_purgatory into two functions, one for each task,
and call them directly from kexec_load_purgatory.

Link: http://lkml.kernel.org/r/20180321112751.22196-7-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/kexec_file.c: use read-only sections in arch_kexec_apply_relocations*

When the relocations are applied to the purgatory only the section the
relocations are applied to is writable.  The other sections, i.e.  the
symtab and .rel/.rela, are in read-only kexec_purgatory.  Highlight this
by marking the corresponding variables as 'const'.

While at it also change the signatures of arch_kexec_apply_relocations* to
take section pointers instead of just the index of the relocation section.
This removes the second lookup and sanity check of the sections in arch
code.

Link: http://lkml.kernel.org/r/20180321112751.22196-6-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/kexec_file.c: search symbols in read-only kexec_purgatory

The stripped purgatory does not contain a symtab.  So when looking for
symbols this is done in read-only kexec_purgatory.  Highlight this by
marking the corresponding variables as 'const'.

Link: http://lkml.kernel.org/r/20180321112751.22196-5-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/kexec_file.c: make purgatory_info->ehdr const

The kexec_purgatory buffer is read-only.  Thus all pointers into
kexec_purgatory are read-only, too.  Point this out by explicitly
marking purgatory_info->ehdr as 'const' and update the comments in
purgatory_info.

Link: http://lkml.kernel.org/r/20180321112751.22196-4-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/kexec_file.c: remove checks in kexec_purgatory_load

Before the purgatory is loaded several checks are done whether the ELF
file in kexec_purgatory is valid or not.  These checks are incomplete.
For example they don't check for the total size of the sections defined
in the section header table or if the entry point actually points into
the purgatory.

On the other hand the purgatory, although an ELF file on its own, is
part of the kernel.  Thus not trusting the purgatory means not trusting
the kernel build itself.

So remove all validity checks on the purgatory and just trust the kernel
build.

Link: http://lkml.kernel.org/r/20180321112751.22196-3-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

include/linux/kexec.h: silence compile warnings

Patch series "kexec_file: Clean up purgatory load", v2.

Following the discussion with Dave and AKASHI, here are the common code
patches extracted from my recent patch set (Add kexec_file_load support
to s390) [1].  The patches were extracted to allow upstream integration
together with AKASHI's common code patches before the arch code gets
adjusted to the new base.

The reason for this series is to prepare common code for adding
kexec_file_load to s390 as well as cleaning up the mis-use of the
sh_offset field during purgatory load.  In detail this series contains:

Patch #1&2: Minor cleanups/fixes.

Patch #3-9: Clean up the purgatory load/relocation code.  Especially
remove the mis-use of the purgatory_info->sechdrs->sh_offset field,
currently holding a pointer into either kexec_purgatory (ro) or
purgatory_buf (rw) depending on the section.  With these patches the
section address will be calculated verbosely and sh_offset will contain
the offset of the section in the stripped purgatory binary
(purgatory_buf).

Patch #10: Allows architectures to set the purgatory load address.  This
patch is important for s390 as the kernel and purgatory have to be
loaded to fixed addresses.  In current code this is impossible as the
purgatory load is opaque to the architecture.

Patch #11: Moves x86 purgatories sha implementation to common lib/
directory to allow reuse in other architectures.

This patch (of 11)

When building the kernel with CONFIG_KEXEC_FILE enabled gcc prints a
compile warning multiple times.

  In file included from <path>/linux/init/initramfs.c:526:0:
  <path>/include/linux/kexec.h:120:9: warning: `struct kimage' declared inside parameter list [enabled by default]
           unsigned long cmdline_len);
           ^

This is because the typedefs for kexec_file_load uses struct kimage
before it is declared.  Fix this by simply forward declaring struct
kimage.

Link: http://lkml.kernel.org/r/20180321112751.22196-2-prudo@linux.vnet.ibm.com
Signed-off-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kexec_file, x86: move re-factored code to generic side

In the previous patches, commonly-used routines, exclude_mem_range() and
prepare_elf64_headers(), were carved out.  Now place them in kexec
common code.  A prefix "crash_" is given to each of their names to avoid
possible name collisions.

Link: http://lkml.kernel.org/r/20180306102303.9063-8-takahiro.akashi@linaro.org
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

x86: kexec_file: clean up prepare_elf64_headers()

Removing bufp variable in prepare_elf64_headers() makes the code simpler
and more understandable.

Link: http://lkml.kernel.org/r/20180306102303.9063-7-takahiro.akashi@linaro.org
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer

While CRASH_MAX_RANGES (== 16) seems to be good enough, fixed-number
array is not a good idea in general.

In this patch, size of crash_mem buffer is calculated as before and the
buffer is now dynamically allocated.  This change also allows removing
crash_elf_data structure.

Link: http://lkml.kernel.org/r/20180306102303.9063-6-takahiro.akashi@linaro.org
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

x86: kexec_file: remove X86_64 dependency from prepare_elf64_headers()

The code guarded by CONFIG_X86_64 is necessary on some architectures
which have a dedicated kernel mapping outside of linear memory mapping.
(arm64 is among those.)

In this patch, an additional argument, kernel_map, is added to enable/
disable the code removing #ifdef.

Link: http://lkml.kernel.org/r/20180306102303.9063-5-takahiro.akashi@linaro.org
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

x86: kexec_file: purge system-ram walking from prepare_elf64_headers()

While prepare_elf64_headers() in x86 looks pretty generic for other
architectures' use, it contains some code which tries to list crash
memory regions by walking through system resources, which is not always
architecture agnostic.  To make this function more generic, the related
code should be purged.

In this patch, prepare_elf64_headers() simply scans crash_mem buffer
passed and add all the listed regions to elf header as a PT_LOAD
segment.  So walk_system_ram_res(prepare_elf64_headers_callback) have
been moved forward before prepare_elf64_headers() where the callback,
prepare_elf64_headers_callback(), is now responsible for filling up
crash_mem buffer.

Meanwhile exclude_elf_header_ranges() used to be called every time in
this callback it is rather redundant and now called only once in
prepare_elf_headers() as well.

Link: http://lkml.kernel.org/r/20180306102303.9063-4-takahiro.akashi@linaro.org
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kexec_file,x86,powerpc: factor out kexec_file_ops functions

As arch_kexec_kernel_image_{probe,load}(),
arch_kimage_file_post_load_cleanup() and arch_kexec_kernel_verify_sig()
are almost duplicated among architectures, they can be commonalized with
an architecture-defined kexec_file_ops array.  So let's factor them out.

Link: http://lkml.kernel.org/r/20180306102303.9063-3-takahiro.akashi@linaro.org
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kexec_file: make use of purgatory optional

Patch series "kexec_file, x86, powerpc: refactoring for other
architecutres", v2.

This is a preparatory patchset for adding kexec_file support on arm64.

It was originally included in a arm64 patch set[1], but Philipp is also
working on their kexec_file support on s390[2] and some changes are now
conflicting.

So these common parts were extracted and put into a separate patch set
for better integration.  What's more, my original patch#4 was split into
a few small chunks for easier review after Dave's comment.

As such, the resulting code is basically identical with my original, and
the only *visible* differences are:

 - renaming of _kexec_kernel_image_probe() and  _kimage_file_post_load_cleanup()

 - change one of types of arguments at prepare_elf64_headers()

Those, unfortunately, require a couple of trivial changes on the rest
(#1, #6 to #13) of my arm64 kexec_file patch set[1].

Patch #1 allows making a use of purgatory optional, particularly useful
for arm64.

Patch #2 commonalizes arch_kexec_kernel_{image_probe, image_load,
verify_sig}() and arch_kimage_file_post_load_cleanup() across
architectures.

Patches #3-#7 are also intended to generalize parse_elf64_headers(),
along with exclude_mem_range(), to be made best re-use of.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/561182.html
[2] http://lkml.iu.edu//hypermail/linux/kernel/1802.1/02596.html

This patch (of 7):

On arm64, crash dump kernel's usable memory is protected by *unmapping*
it from kernel virtual space unlike other architectures where the region
is just made read-only.  It is highly unlikely that the region is
accidentally corrupted and this observation rationalizes that digest
check code can also be dropped from purgatory.  The resulting code is so
simple as it doesn't require a bit ugly re-linking/relocation stuff,
i.e.  arch_kexec_apply_relocations_add().

Please see:

   http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545428.html

All that the purgatory does is to shuffle arguments and jump into a new
kernel, while we still need to have some space for a hash value
(purgatory_sha256_digest) which is never checked against.

As such, it doesn't make sense to have trampline code between old kernel
and new kernel on arm64.

This patch introduces a new configuration, ARCH_HAS_KEXEC_PURGATORY, and
allows related code to be compiled in only if necessary.

[takahiro.akashi@linaro.org: fix trivial screwup]
Link: http://lkml.kernel.org/r/20180309093346.GF25863@linaro.org
Link: http://lkml.kernel.org/r/20180306102303.9063-2-takahiro.akashi@linaro.org
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

proc: revalidate misc dentries

If module removes proc directory while another process pins it by
chdir'ing to it, then subsequent recreation of proc entry and all
entries down the tree will not be visible to any process until pinning
process unchdir from directory and unpins everything.

Steps to reproduce:

proc_mkdir("aaa", NULL);
proc_create("aaa/bbb", ...);

chdir("/proc/aaa");

remove_proc_entry("aaa/bbb", NULL);
remove_proc_entry("aaa", NULL);

proc_mkdir("aaa", NULL);
# inaccessible because "aaa" dentry still points
# to the original "aaa".
proc_create("aaa/bbb", ...);

Fix is to implement ->d_revalidate and ->d_delete.

Link: http://lkml.kernel.org/r/20180312201938.GA4871@avx2
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, slab: reschedule cache_reap() on the same CPU

cache_reap() is initially scheduled in start_cpu_timer() via
schedule_delayed_work_on(). But then the next iterations are scheduled
via schedule_delayed_work(), i.e. using WORK_CPU_UNBOUND.

Thus since commit ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND
work on wq_unbound_cpumask CPUs") there is no guarantee the future
iterations will run on the originally intended cpu, although it's still
preferred.  I was able to demonstrate this with
/sys/module/workqueue/parameters/debug_force_rr_cpu.  IIUC, it may also
happen due to migrating timers in nohz context.  As a result, some cpu's
would be calling cache_reap() more frequently and others never.

This patch uses schedule_delayed_work_on() with the current cpu when
scheduling the next iteration.

Link: http://lkml.kernel.org/r/20180411070007.32225-1-vbabka@suse.cz
Fixes: ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs")
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Pekka Enberg <penberg@kernel.org>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kexec: export PG_swapbacked to VMCOREINFO

Since commit 6326fec1122c ("mm: Use owner_priv bit for PageSwapCache,
valid when PageSwapBacked"), PG_swapcache is an alias for
PG_owner_priv_1, which may be also used for other purposes.

To know whether the bit indeed has the PG_swapcache meaning, it is
necessary to check PG_swapbacked, hence this bit must be exported.

Link: http://lkml.kernel.org/r/20180410161345.142e142d@ezekiel.suse.cz
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Young <dyoung@redhat.com>
Cc: Xunlei Pang <xlpang@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: "Marc-Andr Lureau" <marcandre.lureau@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

ipc/shm: fix use-after-free of shm file via remap_file_pages()

syzbot reported a use-after-free of shm_file_data(file)->file->f_op in
shm_get_unmapped_area(), called via sys_remap_file_pages().

Unfortunately it couldn't generate a reproducer, but I found a bug which
I think caused it.  When remap_file_pages() is passed a full System V
shared memory segment, the memory is first unmapped, then a new map is
created using the ->vm_file.  Between these steps, the shm ID can be
removed and reused for a new shm segment.  But, shm_mmap() only checks
whether the ID is currently valid before calling the underlying file's
->mmap(); it doesn't check whether it was reused.  Thus it can use the
wrong underlying file, one that was already freed.

Fix this by making the "outer" shm file (the one that gets put in
->vm_file) hold a reference to the real shm file, and by making
__shm_open() require that the file associated with the shm ID matches
the one associated with the "outer" file.

Taking the reference to the real shm file is needed to fully solve the
problem, since otherwise sfd->file could point to a freed file, which
then could be reallocated for the reused shm ID, causing the wrong shm
segment to be mapped (and without the required permission checks).

Commit 1ac0b6dec656 ("ipc/shm: handle removed segments gracefully in
shm_mmap()") almost fixed this bug, but it didn't go far enough because
it didn't consider the case where the shm ID is reused.

The following program usually reproduces this bug:

#include <stdlib.h>
#include <sys/shm.h>
#include <sys/syscall.h>
#include <unistd.h>

int main()
{
int is_parent = (fork() != 0);
srand(getpid());
for (;;) {
int id = shmget(0xF00F, 4096, IPC_CREAT|0700);
if (is_parent) {
void *addr = shmat(id, NULL, 0);
usleep(rand() % 50);
while (!syscall(__NR_remap_file_pages, addr, 4096, 0, 0, 0));
} else {
usleep(rand() % 50);
shmctl(id, IPC_RMID, NULL);
}
}
}

It causes the following NULL pointer dereference due to a 'struct file'
being used while it's being freed.  (I couldn't actually get a KASAN
use-after-free splat like in the syzbot report.  But I think it's
possible with this bug; it would just take a more extraordinary race...)

BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 9 PID: 258 Comm: syz_ipc Not tainted 4.16.0-05140-gf8cf2f16a7c95 #189
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
RIP: 0010:d_inode include/linux/dcache.h:519 [inline]
RIP: 0010:touch_atime+0x25/0xd0 fs/inode.c:1724
[...]
Call Trace:
 file_accessed include/linux/fs.h:2063 [inline]
 shmem_mmap+0x25/0x40 mm/shmem.c:2149
 call_mmap include/linux/fs.h:1789 [inline]
 shm_mmap+0x34/0x80 ipc/shm.c:465
 call_mmap include/linux/fs.h:1789 [inline]
 mmap_region+0x309/0x5b0 mm/mmap.c:1712
 do_mmap+0x294/0x4a0 mm/mmap.c:1483
 do_mmap_pgoff include/linux/mm.h:2235 [inline]
 SYSC_remap_file_pages mm/mmap.c:2853 [inline]
 SyS_remap_file_pages+0x232/0x310 mm/mmap.c:2769
 do_syscall_64+0x64/0x1a0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7

[ebiggers@google.com: add comment]
Link: http://lkml.kernel.org/r/20180410192850.235835-1-ebiggers3@gmail.com
Link: http://lkml.kernel.org/r/20180409043039.28915-1-ebiggers3@gmail.com
Reported-by: syzbot+d11f321e7f1923157eac80aa990b446596f46439@syzkaller.appspotmail.com
Fixes: c8d78c1823f4 ("mm: replace remap_file_pages() syscall with emulation")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Davidlohr Bueso <dbueso@suse.de>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: "Eric W . Biederman" <ebiederm@xmission.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/filemap.c: provide dummy filemap_page_mkwrite() for NOMMU

Building orangefs on MMU-less machines now results in a link error
because of the newly introduced use of the filemap_page_mkwrite()
function:

  ERROR: "filemap_page_mkwrite" [fs/orangefs/orangefs.ko] undefined!

This adds a dummy version for it, similar to the existing
generic_file_mmap and generic_file_readonly_mmap stubs in the same file,
to avoid the link error without adding #ifdefs in each file system that
uses these.

Link: http://lkml.kernel.org/r/20180409105555.2439976-1-arnd@arndb.de
Fixes: a5135eeab2e5 ("orangefs: implement vm_ops->fault")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Martin Brandenburg <martin@omnibond.com>
Cc: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/gup.c: document return value

__get_user_pages_fast handles errors differently from
get_user_pages_fast: the former always returns the number of pages
pinned, the later might return a negative error code.

Link: http://lkml.kernel.org/r/1522962072-182137-6-git-send-email-mst@redhat.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

get_user_pages_fast(): return -EFAULT on access_ok failure

get_user_pages_fast is supposed to be a faster drop-in equivalent of
get_user_pages.  As such, callers expect it to return a negative return
code when passed an invalid address, and never expect it to return 0
when passed a positive number of pages, since its documentation says:

 * Returns number of pages pinned. This may be fewer than the number
 * requested. If nr_pages is 0 or negative, returns 0. If no pages
 * were pinned, returns -errno.

When get_user_pages_fast fall back on get_user_pages this is exactly
what happens.  Unfortunately the implementation is inconsistent: it
returns 0 if passed a kernel address, confusing callers: for example,
the following is pretty common but does not appear to do the right thing
with a kernel address:

        ret = get_user_pages_fast(addr, 1, writeable, &page);
        if (ret < 0)
                return ret;

Change get_user_pages_fast to return -EFAULT when supplied a kernel
address to make it match expectations.

All callers have been audited for consistency with the documented
semantics.

Link: http://lkml.kernel.org/r/1522962072-182137-4-git-send-email-mst@redhat.com
Fixes: 5b65c4677a57 ("mm, x86/mm: Fix performance regression in get_user_pages_fast()")
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reported-by: syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>