Move such logic from vivid_create_instance(), as otherwise
smatch takes forever.

The vivid_create_instance() is still a too big for my taste.
So, further cleanups are still needed.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Move this code out of the long vivid_create_instance() function.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The vivid_create_instance() function is too harry. Smatch can't
process it, because it takes too long.

The detection part is an important piece of it. As such, there
are even comments before and after such block.

So, it makes sense to just move it to a separate function.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Remove pointless ir_ prefix.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

rc-core kapi uses nanoseconds for infrared durations for receiving, and
microseconds for sending. The uapi already uses microseconds for both,
so this patch does not change the uapi.

Infrared durations do not need nanosecond resolution. IR protocols do not
have durations shorter than about 100 microseconds. Some IR hardware offers
250 microseconds resolution, which is sufficient for most protocols.
Better hardware has 50 microsecond resolution and is enough for every
protocol I am aware off.

Unify on microseconds everywhere. This simplifies the code since less
conversion between microseconds and nanoseconds needs to be done.

This affects:
 - rx_resolution member of struct rc_dev
 - timeout member of struct rc_dev
 - duration member in struct ir_raw_event

Cc: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Patrick Lerda <patrick9876@free.fr>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: "David Härdeman" <david@hardeman.nu>
Cc: Benjamin Valentin <benpicco@googlemail.com>
Cc: Antti Palosaari <crope@iki.fi>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

BaseRemoteCtl is not descriptive.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Both TT-connect S2-3600 and Pinnacle PCTV Sat HDTV are using
Intersil ISL6423 as LNB voltage regulator. This makes
TT-connect S2-3650 CI the only device which uses STM LNBP22 regulator
which is currently used for all devices driven by pctv452e driver.

This patch fixes this by creating an exception for TT-connect S2-3650 CI
to continue to use STM LNBP22 while all others now using correct ISL6423
driver which makes DiSEqC/EN50494 comands which involve voltage changes
now working on the other devices (which didn't work before).
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Fix the following versioncheck warning:

drivers/media/dvb-frontends/mxl5xx.c:30:1: unused including
<linux/version.h>
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Don't need to declare those functions with extern:
	drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:51:35:  warning: function 'isys_irqc_state_dump' with external linkage has definition
	drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:68:35:  warning: function 'isys_irqc_reg_store' with external linkage has definition
	drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:85:39:  warning: function 'isys_irqc_reg_load' with external linkage has definition
	drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq.c:31:35:  warning: function 'isys_irqc_status_enable' with external linkage has definition
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As smatch reports, there are several bad indents:

    drivers/staging/media/atomisp/pci/hmm/hmm.c:271 hmm_alloc() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/runtime/bufq/src/bufq.c:390 ia_css_bufq_enqueue_psys_event() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/runtime/debug/src/ia_css_debug.c:2132 ia_css_debug_dump_isys_state() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/runtime/binary/src/binary.c:246 sh_css_binary_get_sc_requirements() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/runtime/binary/src/binary.c:565 ia_css_binary_get_shading_info_type_1() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/sh_css.c:5109 sh_css_pipes_stop() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/sh_css.c:8791 ia_css_pipe_create() warn: inconsistent indenting

Some of them are due to ifdefs. Get rid of them by either getting
a common code that would work for both ISP2400 and ISP2401 or
by creating separate functions, one for each ISP version.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Now that there's no duplication between ISP2400 and ISP2401
input system functions, we can include both at the system
global.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Reorder functions in order to declare before usage.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are some duplicated names between the ISP2401 and ISP2400
for the input system, with different meanings.

In order to avoid ubiquity, let's prepend those with the
name of the ISP.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There is a typedef for INPUT errors. This is different between
ISP2401 and ISP2400. Place both at the same struct, at the
global header file.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As there aren't duplicated names anymore, and the end goal
is to do runtime checks between ISP2400 and ISP2401,
remove the part of the Makefile which changes the include
places based on the compile-time version.

This shouldn't cause any effect, but it will make easier
for further patches meant to remove conditional compiler
decisions between ISP versions to be replaced by
runtime ones.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Just move the stuff there to the places where this header is
included.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There aren't much on this abstraction. Just move the defines
to isys_dma_private.h and isys_dma_public.h, cleaning up
the includes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Replace all occurrences along the atomisp tree for the conditional
compilation macros found at system_global.h, replacing them by
tests wheather ISP2401 is defined or not.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are lots of code dependency there. Get rid of most of
them.

We can't remove everything, as there are some structs that
are conditionally built if ISP2401. So, keep ifdefs only
on such cases.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Now that the defines which are common for both ISP2400 and ISP2401
are at system_global.h, we can get rid of the code not used by
those versions.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Due to that, smatch warns with:

	drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:18:11:  warning: symbol 'N_SHORT_PACKET_LUT_ENTRIES' was not declared. Should it be static?
	drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:24:11:  warning: symbol 'N_LONG_PACKET_LUT_ENTRIES' was not declared. Should it be static?
	drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:30:11:  warning: symbol 'N_CSI_RX_FE_CTRL_DLANES' was not declared. Should it be static?
	drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:37:11:  warning: symbol 'N_CSI_RX_BE_SID_WIDTH' was not declared. Should it be static?
	drivers/staging/media/atomisp/pci/css_2401_system/host/ibuf_ctrl.c:19:11:  warning: symbol 'N_IBUF_CTRL_PROCS' was not declared. Should it be static?
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

solve this smatch warning:
	drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c:842 gmin_v1p8_ctrl() warn: variable dereferenced before check 'gs' (see line 832)

By moving the check to happen before its usage.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are several warnings reported by sparse with regards to wrong
typecasts:

    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:73:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:73:13:     expected void *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:73:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:247:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:247:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:247:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:248:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:248:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:248:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:249:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:249:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:249:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:250:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:250:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:250:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:282:30:  warning: incorrect type in argument 2 (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:282:30:     expected void const *from
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:282:30:     got struct atomisp_3a_statistics [noderef] __user *kp
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:308:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:308:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:308:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:327:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:327:13:     expected void [noderef] __user *effective_width
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:327:13:     got unsigned int [usertype] *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:348:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:348:13:     expected void [noderef] __user *effective_width
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:348:13:     got unsigned int [usertype] *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:372:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:372:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:372:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:433:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:433:13:     expected struct v4l2_framebuffer *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:433:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:462:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:462:13:     expected void [noderef] __user *frame
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:462:13:     got struct v4l2_framebuffer *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:496:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:496:13:     expected unsigned short *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:496:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:511:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:511:13:     expected void [noderef] __user *calb_grp_values
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:511:13:     got unsigned short *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:630:21:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:630:21:     expected unsigned short [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:630:21:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27:  warning: cast removes address space '__user' of expression
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27:  warning: incorrect type in initializer (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27:     expected struct <noident> [noderef] __user *karg
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27:     got void *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:721:39:  warning: cast removes address space '__user' of expression
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:21:  warning: incorrect type in argument 1 (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:21:     expected void const volatile [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:21:     got unsigned int [usertype] *src
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:43:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:43:     expected void *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:43:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:741:21:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:741:21:     expected struct atomisp_shading_table *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:741:21:     got struct atomisp_shading_table [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:747:21:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:747:21:     expected struct atomisp_morph_table *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:747:21:     got struct atomisp_morph_table [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:753:21:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:753:21:     expected struct atomisp_dis_coefficients *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:753:21:     got struct atomisp_dis_coefficients [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:760:14:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:760:14:     expected struct atomisp_dvs_6axis_config *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:760:14:     got struct atomisp_dvs_6axis_config [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:817:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:817:13:     expected struct atomisp_sensor_ae_bracketing_lut_entry *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:817:13:     got void [noderef] __user *

Use the same strategies used at v4l2-compat32.c, in order to
solve them and avoid warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As reported by smatch:
	drivers/media/pci/saa7134//saa7134-tvaudio.c:686 saa_dsp_writel() warn: should 'reg << 2' be a 64 bit type?

On a 64-bits Kernel, the shift might be bigger than 32 bits.

In real, this should never happen, but let's shut up the warning.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Instead of calling printk(), use pr_foo() macros.

While here, do some cleanup at the printed messages, as some
has __func__, while others have the module name (sometimes
spelled as "ttusb_dvb").
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As reported by smatch:

    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:311 ttusb_boot_dsp() error: doing dma on the stack (b)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:321 ttusb_boot_dsp() error: doing dma on the stack (b)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:330 ttusb_boot_dsp() error: doing dma on the stack (b)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:351 ttusb_set_channel() error: doing dma on the stack (b)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:361 ttusb_del_channel() error: doing dma on the stack (b)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:412 ttusb_init_controller() error: doing dma on the stack (b0)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:416 ttusb_init_controller() error: doing dma on the stack (b1)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:422 ttusb_init_controller() error: doing dma on the stack (b2)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:425 ttusb_init_controller() error: doing dma on the stack (b3)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:430 ttusb_init_controller() error: doing dma on the stack (get_version)

This driver still uses the USB stack for DMA transfers,
which is broken for a long time. I almost dropped this driver,
as there's a high chance that nobody is using it with upstream
Kernels, as we didn't receive any bug reports.

As fixing this won't be hard, I ended opting to fix.

While here, I dropped an ugly hack that implemented read via
a separate function that was just doing a memcpy().

It should be noticed that, during the init phase, there's
a "b4" register that were never initialized, as its buffer
were used just to store the results of "b3" initialization.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As reported by smatch:

	drivers/media/pci/saa7134/saa7134-alsa.c:267 saa7134_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?

the number of patches should be unsigned long.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As reported by smatch:

	drivers/media/pci/cx88/cx88-alsa.c:286 cx88_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?

the number of patches should be unsigned long.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As reported by smatch:

	drivers/media//pci/cx23885/cx23885-alsa.c:83 cx23885_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?

the number of patches should be unsigned long.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As reported by smatch:

	drivers/media/pci/cx25821/cx25821-alsa.c:146 cx25821_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?

the number of patches should be unsigned long.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As reported by smatch:

	drivers/media/v4l2-core/videobuf-dma-sg.c:245 videobuf_dma_init_kernel() warn: should 'nr_pages << 12' be a 64 bit type?

The printk should not be using %d for the number of pages.

After looking better, the real problem here is that the
number of pages should be long int.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As warned by smatch:
	drivers/media/rc/serial_ir.c:550 serial_ir_probe() warn: should '8 << ioshift' be a 64 bit type?

the "8" constant should be unsigned long.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The usage of castings and float point when checking for
the setup based at the symbol_rate cause those warnings
with smatch:

	drivers/media/dvb-frontends/tda10021.c:153 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
	drivers/media/dvb-frontends/tda10021.c:155 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
	drivers/media/dvb-frontends/tda10021.c:157 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
	drivers/media/dvb-frontends/tda10021.c:159 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.

While the code should work with gcc, as it will evaluate the
values into a constant before compiling, other compilers
could do otherwise. So, get rid of float pointing math on it,
avoiding the need of doing typecasts.

While here, cleanup some coding style issues at the related
code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Sparse warns about this symbol:

	drivers/media/platform/qcom/venus/hfi_venus.c:133:5:  warning: symbol 'venus_fw_debug' was not declared. Should it be static?

Because hfi_venus.c doesn't include a header file with the
extern. So, move it to core.h, with is included by both
hfi_venus.c and dbgfs.c.

This way, if something changes with it, warnings or errors
will be produced.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As reported by smatch:
	drivers/media/radio/wl128x/fmdrv_common.c:736 fm_irq_handle_rdsdata_getcmd_resp() warn: potential spectre issue 'rds_fmt.data.groupdatabuff.buff>

Address it by using array_index_nospec().

While here, reorder the linux/ includes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

While smatch reports an issue there:

	drivers/media/pci/ttpci/av7110_v4l.c:163 ves1820_set_tv_freq() warn: unsigned 'freq' is never less than zero.
	drivers/media/pci/ttpci/av7110_v4l.c:165 ves1820_set_tv_freq() warn: unsigned 'freq' is never less than zero.

The logic is actually fine. Yet, removing the typecast
shuts up smatch and makes the code more readable.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As pointed by smatch:

	drivers/media/tuners/qt1010.c:239 qt1010_init_meas1() error: uninitialized symbol 'val2'.
	drivers/media/tuners/qt1010.c:273 qt1010_init_meas2() error: uninitialized symbol 'val'.

The logic is ok, but it is hard for static analyzers
to parse it, as it depends on a value read in the middle
of a loop.

Also, it takes a while for humans to verify.

Re-write the first function to use a more direct way.

At the second one, I opted to just initialize the read var,
in order to shut up the report.

While here, address a few coding style issues at the
function code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The original logic had an integer to unsigned integer
conversion, plus a float-point math. While gcc should be
able to do the match at compile time, other compilers might
not do the same. Also, those produce the following warnings
with static code analyzers:

	drivers/media/dvb-frontends/tda10086.c:300 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
	drivers/media/dvb-frontends/tda10086.c:303 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
	drivers/media/dvb-frontends/tda10086.c:306 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
	drivers/media/dvb-frontends/tda10086.c:309 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
	drivers/media/dvb-frontends/tda10086.c:312 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
	drivers/media/dvb-frontends/tda10086.c:315 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
	drivers/media/dvb-frontends/tda10086.c:318 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
	drivers/media/dvb-frontends/tda10086.c:321 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
	drivers/media/dvb-frontends/tda10086.c:324 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
	drivers/media/dvb-frontends/tda10086.c:327 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.

Change the logic to declare the reference constant as unsigned
and to not use float point math.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Upon running Sparse, "warning: dubious: !x | !y" is brought to notice
for this file.  Logical and bitwise OR are basically the same in this
context, so it doesn't cause a runtime bug.  But let's change it to
logical OR to make it a little bit cleaner and silence the Sparse
warning.
Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Use semicolons and braces.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>