summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-09-03media: atomisp: get rid of version-dependent globalsMauro Carvalho Chehab
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>
2020-09-03media: atomisp: cleanup ifdefs from ia_css_debug.cMauro Carvalho Chehab
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>
2020-09-03media: atomisp: get rid of some unused codeMauro Carvalho Chehab
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>
2020-09-03media: atomisp: csi_rx.c: add missing includesMauro Carvalho Chehab
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>
2020-09-03media: atomisp: atomisp_gmin_platform: check before useMauro Carvalho Chehab
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>
2020-09-03media: atomisp: fix casts at atomisp_compat_ioctl32.cMauro Carvalho Chehab
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>
2020-09-03media: saa7134: avoid a shift overflowMauro Carvalho Chehab
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>
2020-09-03media: dvb-ttusb-budget: cleanup printk logicMauro Carvalho Chehab
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>
2020-09-03media: dvb-ttusb-budget: don't use stack for USB transfersMauro Carvalho Chehab
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>
2020-09-03media: saa7134-alsa.c: number of pages should be unsigned longMauro Carvalho Chehab
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>
2020-09-03media: cx88-alsa: number of pages should be unsigned longMauro Carvalho Chehab
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>
2020-09-03media: cx23885-alsa: number of pages should be unsigned longMauro Carvalho Chehab
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>
2020-09-03media: cx25821-alsa: number of pages should be unsigned longMauro Carvalho Chehab
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>
2020-09-03media: videobuf-dma-sg: number of pages should be unsigned longMauro Carvalho Chehab
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>
2020-09-03media: serial_ir: use the right type for a dma addressMauro Carvalho Chehab
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>
2020-09-03media: tda10021: avoid casts when using symbol_rateMauro Carvalho Chehab
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>
2020-09-03media: venus: place extern venus_fw_debug on a header fileMauro Carvalho Chehab
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>
2020-09-03media: wl128x: get rid of a potential spectre issueMauro Carvalho Chehab
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>
2020-09-03media: av7110_v4l: avoid a typecastMauro Carvalho Chehab
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>
2020-09-03media: qt1010: fix usage of unititialized valueMauro Carvalho Chehab
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>
2020-09-03media: tda10086: cleanup symbol_rate setting logicMauro Carvalho Chehab
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>
2020-09-03media: atomisp: fix "dubious: !x | !y" sparse warningAnant Thazhemadam
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>
2020-09-03media: atomisp: Avoid comma separated statementsJoe Perches
Use semicolons and braces. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: fix memleak in ia_css_stream_createDinghao Liu
When aspect_ratio_crop_init() fails, curr_stream needs to be freed just like what we've done in the following error paths. However, current code is returning directly and ends up leaking memory. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: fix spelling mistake "unsupport" -> "unsupported"Colin Ian King
There are spelling mistakes in some dev_err messages. Fix these. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: move null check to earlier pointCengiz Can
`find_gmin_subdev()` that returns a pointer to `struct gmin_subdev` can return NULL. In `gmin_v2p8_ctrl()` there's a call to this function but the possibility of a NULL was not checked before its being dereferenced, i.e.: /* Acquired here --------v */ struct gmin_subdev *gs = find_gmin_subdev(subdev); /* v------Dereferenced here */ if (gs->v2p8_gpio >= 0) { ... } With this change we're null checking `find_gmin_subdev()` result and we return an error if that's the case. We also WARN() for the sake of debugging. Signed-off-by: Cengiz Can <cengiz@kernel.wtf> Reported-by: Coverity Static Analyzer CID 1465536 Suggested-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: mt9m114: replace fixed function namesJuan Antonio Aldea-Armenteros
There are a couple of debug messages using hardcoded function names instead of the preferred __func__ magic constant. Replace them: WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this function's name, in a string 215: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:215: + v4l2_err(client, "misensor_rmw_reg error exit, read failed\n"); WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this function's name, in a string 236: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:236: + v4l2_err(client, "misensor_rmw_reg error exit, write failed\n"); Signed-off-by: Juan Antonio Aldea-Armenteros <juant.aldea@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: fix code style issuesRohit K Bharadwaj
Fix warnings and errors generated after running checkpatch.pl on pci/sh_css_firmware.c. Signed-off-by: Rohit K Bharadwaj <bharadwaj.rohit8@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: Replace deprecated MSI APIsSuraj Upadhyay
Replace deprecated MSI IRQ enabler and disabler with pci_alloc_irq_vectors and pci_free_irq_vectors respectively. And as a result handle the returned error as appropriate. Compile tested. [mchehab: solved a merge conflict that renamed dev->pdev] Signed-off-by: Suraj Upadhyay <usuraj35@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: fix identation at I2C Kconfig menuMauro Carvalho Chehab
There are several bad whitespacing usage there. Remove them. While here, place all Kconfig options for sensors at the same place. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: fix a brace coding sytle issueAnkit Baluni
Removed braces in 'if else' condition as it only consists of one line each and according to coding style rules , in this case the braces are not required. Signed-off-by: Ankit Baluni <b18007@students.iitmandi.ac.in> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: Fix braces placement coding style errorsAditya Jain
Fix braces placement errors as reported by checkpatch.pl Signed-off-by: Aditya Jain <aditya.jainadityajain.jain@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: fixed a brace coding sytle issueAnkit Baluni
Removed braces for a 'if' condition as it contain only single line & there is no need for braces for such case according to coding style rules. Signed-off-by: Ankit Baluni <b18007@students.iitmandi.ac.in> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: coding style: correct multiline commentsRahul Gottipati
This fixes some coding style issues of multiline comments to correct a few checkpatch.pl warnings. Signed-off-by: Rahul Gottipati <rahul.blr97@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: coding style: remove beginning whitespacesRahul Gottipati
This removes whitespaces at the beginning of a few lines to fix some checkpatch.pl warnings. Signed-off-by: Rahul Gottipati <rahul.blr97@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03soundwire: fix double free of dangling pointerTom Rix
clang static analysis flags this problem stream.c:844:9: warning: Use of memory after it is freed kfree(bus->defer_msg.msg->buf); ^~~~~~~~~~~~~~~~~~~~~~~ This happens in an error handler cleaning up memory allocated for elements in a list. list_for_each_entry(m_rt, &stream->master_list, stream_node) { bus = m_rt->bus; kfree(bus->defer_msg.msg->buf); kfree(bus->defer_msg.msg); } And is triggered when the call to sdw_bank_switch() fails. There are a two problems. First, when sdw_bank_switch() fails, though it frees memory it does not clear bus's reference 'defer_msg.msg' to that memory. The second problem is the freeing msg->buf. In some cases msg will be NULL so this will dereference a null pointer. Need to check before freeing. Fixes: 99b8a5d608a6 ("soundwire: Add bank switch routine") Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200902202650.14189-1-trix@redhat.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-09-03interconnect: Show bandwidth for disabled paths as zero in debugfsMatthias Kaehlcke
For disabled paths the 'interconnect_summary' in debugfs currently shows the orginally requested bandwidths. This is confusing, since the bandwidth requests aren't active. Instead show the bandwidths for disabled paths/requests as zero. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20200729104933.1.If8e80e4c0c7ddf99056f6e726e59505ed4e127f3@changeid Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2020-09-03dmaengine: ti: k3-udma: Update rchan_oes_offset for am654 SYSFW ABI 3.0Peter Ujfalusi
SYSFW ABI 3.0 has changed the rchan_oes_offset value for am654 to support SR2. Since the kernel now needs SYSFW API 3.0 to work because the merged irqchip update, we need to also update the am654 rchan_oes_offset. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200831091019.25273-1-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-09-03drm/nouveau/kms/nv50-gp1xx: add WAR for EVO push buffer HW bugBen Skeggs
Thanks to NVIDIA for confirming this workaround, and clarifying which HW is affected. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Tested-by: Alexander Kapshuk <alexander.kapshuk@gmail.com>
2020-09-03drm/nouveau/kms/nv50-gp1xx: disable notifies again after core updateBen Skeggs
This was lost during the header conversion. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-09-03drm/nouveau/kms/nv50-: add some whitespace before debug messageBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-09-03drm/nouveau/kms/gv100-: Include correct push header in crcc37d.cLyude Paul
Looks like when we converted everything over to Nvidia's class headers, we mistakenly included the nvif/push507b.h instead of nvif/pushc37b.h, which resulted in breaking CRC reporting for volta+: nouveau 0000:1f:00.0: disp: chid 0 stat 10003361 reason 3 [RESERVED_METHOD] mthd 0d84 data 00000000 code 00000000 nouveau 0000:1f:00.0: disp: chid 0 stat 10003360 reason 3 [RESERVED_METHOD] mthd 0d80 data 00000000 code 00000000 nouveau 0000:1f:00.0: DRM: CRC notifier ctx for head 3 not finished after 50ms So, fix that. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: c4b27bc8682c ("drm/nouveau/kms/nv50-: convert core crc_set_src() to new push macros") Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-09-03drm/radeon: Prefer lower feedback dividersKai-Heng Feng
Commit 2e26ccb119bd ("drm/radeon: prefer lower reference dividers") fixed screen flicker for HP Compaq nx9420 but breaks other laptops like Asus X50SL. Turns out we also need to favor lower feedback dividers. Users confirmed this change fixes the regression and doesn't regress the original fix. Fixes: 2e26ccb119bd ("drm/radeon: prefer lower reference dividers") BugLink: https://bugs.launchpad.net/bugs/1791312 BugLink: https://bugs.launchpad.net/bugs/1861554 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-03drm/amdgpu: Fix bug in reporting voltage for CIKSandeep Raghuraman
On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-03drm/amdgpu: Specify get_argument function for ci_smu_funcsSandeep Raghuraman
Starting in Linux 5.8, the graphics and memory clock frequency were not being reported for CIK cards. This is a regression, since they were reported correctly in Linux 5.7. After investigation, I discovered that the smum_send_msg_to_smc() function, attempts to call the corresponding get_argument() function of ci_smu_funcs. However, the get_argument() function is not defined in ci_smu_funcs. This patch fixes the bug by specifying the correct get_argument() function. Fixes: a0ec225633d9f6 ("drm/amd/powerplay: unified interfaces for message issuing and response checking") Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-09-03drm/amd/pm: enable MP0 DPM for sienna_cichlidJiansong Chen
Enable MP0 clock DPM for sienna_cichlid. Signed-off-by: Jiansong Chen <Jiansong.Chen@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-03drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp settingEvan Quan
Normally softwareshutdowntemp should be greater than Thotspotlimit. However, on some VEGA10 ASIC, the softwareshutdowntemp is 91C while Thotspotlimit is 105C. This seems not right and may trigger some false alarms. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-09-03drm/amd/pm: fix is_dpm_running() run error on 32bit systemKevin Wang
v1: the C type "unsigned long" size is 32bit on 32bit system, it will cause code logic error, so replace it with "uint64_t". v2: remove duplicate cast operation. Signed-off-by: Kevin <kevin1.wang@amd.com> Suggest-by: Jiansong Chen <Jiansong.Chen@amd.com> Reviewed-by: Jiansong Chen <Jiansong.Chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-02scsi: mpt3sas: Don't call disable_irq from IRQ poll handlerTomas Henzl
disable_irq() might sleep, replace it with disable_irq_nosync(). For synchronisation 'irq_poll_scheduled' is sufficient Fixes: 320e77acb3 scsi: mpt3sas: Irq poll to avoid CPU hard lockups Link: https://lore.kernel.org/r/20200901145026.12174-1-thenzl@redhat.com Signed-off-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-09-02scsi: megaraid_sas: Don't call disable_irq from process IRQ pollTomas Henzl
disable_irq() might sleep. Replace it with disable_irq_nosync() which is sufficient as irq_poll_scheduled protects against concurrently running complete_cmd_fusion() from megasas_irqpoll() and megasas_isr_fusion(). Link: https://lore.kernel.org/r/20200827165332.8432-1-thenzl@redhat.com Fixes: a6ffd5bf681 scsi: megaraid_sas: Call disable_irq from process IRQ poll Signed-off-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
generated by cgit (git 2.34.1) at 2025-09-24 10:54:33 +0000