summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-06-11media: atomisp: get rid of sh_css_pipe.cMauro Carvalho Chehab
There's nothing there, just comments. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: media: atomisp: fix stack overflow in init_pipe_defaults()Arnd Bergmann
When building with clang, multiple copies of the structures to be initialized are passed around on the stack and copied locally, using an insane amount of stack space: drivers/staging/media/atomisp/pci/sh_css.c:2371:1: error: stack frame size of 26864 bytes in function 'create_pipe' [-Werror,-Wframe-larger-than=] Use constantly-allocated variables plus an explicit memcpy() to avoid that. Co-authored-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Fixes: 6dc9a2568f84 ("media: atomisp: convert default struct values to use compound-literals with designated initializers") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: re-enable warnings againMauro Carvalho Chehab
For most warnings, the current code is OK. There are still some issues with implicit-fallthough warnings. Solve those and re-enable all warnings for this driver. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: remove format duplication at mbus->fourcc tableMauro Carvalho Chehab
This table used to be used also to translate between ia_css abstraction and V4L2 fourcc codes. This was removed on a past patch, but the table now contains two fields with identical values. Get rid of one of them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: media: atomisp: add PMIC_OPREGION dependencyArnd Bergmann
Without that driver, there is a link failure in ERROR: modpost: "intel_soc_pmic_exec_mipi_pmic_seq_element" [drivers/staging/media/atomisp/pci/atomisp_gmin_platform.ko] undefined! Add an explicit Kconfig dependency. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: media: atomisp: disable all custom formatsArnd Bergmann
clang points out the usage of an incorrect enum type in the list of supported image formats: drivers/staging/media/atomisp/pci/atomisp_subdev.c:49:65: error: implicit conversion from enumeration type 'enum ia_css_frame_format' to different enumeration type 'enum atomisp_input_format' [-Werror,-Wenum-conversion] { V4L2_MBUS_FMT_CUSTOM_NV21, 12, 12, CSS_FRAME_FORMAT_NV21, 0, CSS_FRAME_FORMAT_NV21 }, drivers/staging/media/atomisp/pci/atomisp_subdev.c:49:39: error: implicit conversion from enumeration type 'enum ia_css_frame_format' to different enumeration type 'enum atomisp_input_format' [-Werror,-Wenum-conversion] { V4L2_MBUS_FMT_CUSTOM_NV21, 12, 12, CSS_FRAME_FORMAT_NV21, 0, CSS_FRAME_FORMAT_NV21 }, { V4L2_MBUS_FMT_CUSTOM_NV12, 12, 12, CSS_FRAME_FORMAT_NV12, 0, CSS_FRAME_FORMAT_NV12 }, { MEDIA_BUS_FMT_JPEG_1X8, 8, 8, CSS_FRAME_FORMAT_BINARY_8, 0, ATOMISP_INPUT_FORMAT_BINARY_8 }, Checking the git history, I found a commit that disabled one such case because it did not work. It seems likely that the incorrect enum was part of the original problem and that the others do not work either, or have never been tested. Disable all the ones that cause a warning. Fixes: cb02ae3d71ea ("media: staging: atomisp: Disable custom format for now") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: media: atomisp: fix enum type mixupsArnd Bergmann
Some function calls pass an incorrect enum type: drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:858:16: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion] gp_device_rst(INPUT_SYSTEM0_ID); ~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~ drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:860:19: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion] input_switch_rst(INPUT_SYSTEM0_ID); ~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~ drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:876:27: error: implicit conversion from enumeration type 'input_system_cfg_flag_t' to different enumeration type 'input_system_connection_t' [-Werror,-Wenum-conversion] config.multicast[i] = INPUT_SYSTEM_CFG_FLAG_RESET; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:1326:32: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion] input_selector_cfg_for_sensor(INPUT_SYSTEM0_ID); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~ drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:1329:19: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion] input_switch_cfg(INPUT_SYSTEM0_ID, &config.input_switch_cfg); ~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~ INPUT_SYSTEM0_ID is zero, so use the corresponding zero-value of the expected types instead. Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: media: atomisp: declare 'struct device' before using itArnd Bergmann
In some configurations, including this header leads to a warning: drivers/staging/media/atomisp//pci/sh_css_firmware.h:41:38: error: declaration of 'struct device' will not be visible outside of this function [-Werror,-Wvisibility] Make sure the struct tag is known before declaring a function that uses it as an argument. Fixes: 9d4fa1a16b28 ("media: atomisp: cleanup directory hierarchy") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: add SPDX headersMauro Carvalho Chehab
This driver is licensed under GPL 2.0, as stated inside their headers. Add the proper tag there. We should probably latter cleanup the reduntant licensing text, but this could be done later, after we get rid of other abstraction layers. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: atomisp: Check return value from compat_alloc_user_spaceSakari Ailus
If something gets wrong, return, instead of trying to convert from a NULL pointer. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: atomisp: Fix compat IOCTL handlingSakari Ailus
Atomisp compat IOCTL handling suffers from the same security issue than the V4L2 did. Fix this for atomisp. See more information in patch a1dfb4c48cc1 ("media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: atomisp: Fix atomisp_overlay32 compat handlingSakari Ailus
The struct atomisp_overlay contains overlay_start_x and overlay_start_y fields. Instead of copying the value of the overlay_start_x field between the two structs, the value of the overlay_start_y field of the compat struct was copied to the overlay_start_x field of the 64-bit kernel struct in get operation and back in put. The overlay_start_x field value was not copied from or to the user space struct. Fix this so that the value of overlay_start_x is copied to overlay_start_x and the value of overlay_start_y is copied to overlay_start_y. Also do copy blend_overlay_perc_u field only once. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: staging: atomisp: There's no struct atomisp_dvs2_coefficientsSakari Ailus
It's called struct atomisp_dis_coefficients. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: add some debug messages when binaries are usedMauro Carvalho Chehab
The ISP firmware logic is complex, as several binaries are contained into a single file. Print debug messages: - with a stack dump if binary not found; - when a firmware is selected. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: add a debug message at hmm freeMauro Carvalho Chehab
In order to check if aren't there any memory leaks, let's add a debug print for hmm_free(). Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: allow passing firmware name at modprobe timeMauro Carvalho Chehab
It can be useful to be able to test different firmware files at modprobe time, in order to be able to test different variants without much efforts. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: print firmware data during loadMauro Carvalho Chehab
While there's a way to list the firmware binaries in runtime, it is worth to also print it during firmware load. One advantage is that this code also introduces additional checks with regards to invalid firmware types, which can be useful to identify problems. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: provide more details about the firmware binariesMauro Carvalho Chehab
In order to make easier to identify what a firmware file contains, add more info at the firmware dump log facility. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11KVM: selftests: fix sync_with_host() in smm_testVitaly Kuznetsov
It was reported that older GCCs compile smm_test in a way that breaks it completely: kvm_exit: reason EXIT_CPUID rip 0x4014db info 0 0 func 7ffffffd idx 830 rax 0 rbx 0 rcx 0 rdx 0, cpuid entry not found ... kvm_exit: reason EXIT_MSR rip 0x40abd9 info 0 0 kvm_msr: msr_read 487 = 0x0 (#GP) ... Note, '7ffffffd' was supposed to be '80000001' as we're checking for SVM. Dropping '-O2' from compiler flags help. Turns out, asm block in sync_with_host() is wrong. We us 'in 0xe, %%al' instruction to sync with the host and in 'AL' register we actually pass the parameter (stage) but after sync 'AL' gets written to but GCC thinks the value is still there and uses it to compute 'EAX' for 'cpuid'. smm_test can't fully use standard ucall() framework as we need to write a very simple SMI handler there. Fix the immediate issue by making RAX input/output operand. While on it, make sync_with_host() static inline. Reported-by: Marcelo Bandeira Condotta <mcondotta@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200610164116.770811-1-vkuznets@redhat.com> Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-11KVM: async_pf: Inject 'page ready' event only if 'page not present' was ↵Vitaly Kuznetsov
previously injected 'Page not present' event may or may not get injected depending on guest's state. If the event wasn't injected, there is no need to inject the corresponding 'page ready' event as the guest may get confused. E.g. Linux thinks that the corresponding 'page not present' event wasn't delivered *yet* and allocates a 'dummy entry' for it. This entry is never freed. Note, 'wakeup all' events have no corresponding 'page not present' event and always get injected. s390 seems to always be able to inject 'page not present', the change is effectively a nop. Suggested-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200610175532.779793-2-vkuznets@redhat.com> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=208081 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-11KVM: async_pf: Cleanup kvm_setup_async_pf()Vitaly Kuznetsov
schedule_work() returns 'false' only when the work is already on the queue and this can't happen as kvm_setup_async_pf() always allocates a new one. Also, to avoid potential race, it makes sense to to schedule_work() at the very end after we've added it to the queue. While on it, do some minor cleanup. gfn_to_pfn_async() mentioned in a comment does not currently exist and, moreover, we can check kvm_is_error_hva() at the very beginning, before we try to allocate work so 'retry_sync' label can go away completely. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200610175532.779793-1-vkuznets@redhat.com> Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-11kvm: i8254: remove redundant assignment to pointer sColin Ian King
The pointer s is being assigned a value that is never read, the assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Message-Id: <20200609233121.1118683-1-colin.king@canonical.com> Fixes: 7837699fa6d7 ("KVM: In kernel PIT model") Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-11KVM: x86: respect singlestep when emulating instructionFelipe Franciosi
When userspace configures KVM_GUESTDBG_SINGLESTEP, KVM will manage the presence of X86_EFLAGS_TF via kvm_set/get_rflags on vcpus. The actual rflag bit is therefore hidden from callers. That includes init_emulate_ctxt() which uses the value returned from kvm_get_flags() to set ctxt->tf. As a result, x86_emulate_instruction() will skip a single step, leaving singlestep_rip stale and not returning to userspace. This resolves the issue by observing the vcpu guest_debug configuration alongside ctxt->tf in x86_emulate_instruction(), performing the single step if set. Cc: stable@vger.kernel.org Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Message-Id: <20200519081048.8204-1-felipe@nutanix.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-11KVM: selftests: Don't probe KVM_CAP_HYPERV_ENLIGHTENED_VMCS when nested VMX ↵Vitaly Kuznetsov
is unsupported KVM_CAP_HYPERV_ENLIGHTENED_VMCS will be reported as supported even when nested VMX is not, fix evmcs_test/hyperv_cpuid tests to check for both. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200610135847.754289-3-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-11KVM: selftests: do not substitute SVM/VMX check with KVM_CAP_NESTED_STATE checkVitaly Kuznetsov
state_test/smm_test use KVM_CAP_NESTED_STATE check as an indicator for nested VMX/SVM presence and this is incorrect. Check for the required features dirrectly. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200610135847.754289-2-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-11Merge branch 'kvm-basic-exit-reason' into HEADPaolo Bonzini
Using a topic branch so that stable branches can simply cherry-pick the patch. Reviewed-by: Oliver Upton <oupton@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-11media: atomisp: get rid of system_types.hMauro Carvalho Chehab
This is just a wrapper for system_local.h. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of a bunch of other wrappersMauro Carvalho Chehab
There are too many wrapper functions at atomisp_compat_css20.c. Get rid of another set of such wrappers. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: don't cause a warn if probe failedMauro Carvalho Chehab
When probe fails, it is possible that hmm_init() to not be called. On such case, hmm_cleanup() will cause a WARN_ON(). Avoid it by adding an explicit check at hmm_cleanup() to ensure that the hmm code was properly initialized. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of an error abstraction layerMauro Carvalho Chehab
There is an abstraction layer there meant to convert to the Linux standard error codes. As the driver now use such errors everywhere. we can get rid of this. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of non-Linux error codesMauro Carvalho Chehab
The atomisp driver has its own error codes under the ia_css_err.h file. On several places, those got already replaced by standard error codes, but there are still a lot more to be fixed. Let's get rid of all of those, mapping them into the already-existing set of Linux error codes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: do another round of coding style cleanupMauro Carvalho Chehab
Run checkpatch --fix-inline again, in order to get rid of some additional issues that got introduced (or that checkpatch can now detect). This should help preventing receiving random cleanups, while keeping the code on a better shape. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: remove some trivial wrappers from compat css20Mauro Carvalho Chehab
There are tons of code inside atomisp_compat_css20.c, but several of them are just trivial wrappers to other functions. Getting rid of all of them will take some time, but let's start getting rid of some of the trivial ones. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: avoid an extra memset() when alloc memoryMauro Carvalho Chehab
Use the variant which zeroes the memory when allocating, instead of having an explicit memset. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: Remove binary_supports_input_formatNathan Chancellor
Clang warns: drivers/staging/media/atomisp/pci/runtime/binary/src/binary.c:1707:64: warning: implicit conversion from enumeration type 'const enum ia_css_frame_format' to different enumeration type 'enum atomisp_input_format' [-Wenum-conversion] binary_supports_input_format(xcandidate, req_in_info->format)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~^~~~~~ As it turns out, binary_supports_input_format only asserts that xcandidate is not NULL and just returns true so this call is never actually made. There are other functions that are called that assert info is not NULL so this function actually serves no purpose. Remove it. It can be brought back if needed later. Link: https://github.com/ClangBuiltLinux/linux/issues/1036 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: Avoid overflow in compute_blendingNathan Chancellor
Clang warns: drivers/staging/media/atomisp/pci/isp/kernels/xnr/xnr_3.0/ia_css_xnr3.host.c:129:35: warning: implicit conversion from 'unsigned long' to 'int32_t' (aka 'int') changes value from 18446744073709543424 to -8192 [-Wconstant-conversion] return MAX(MIN(isp_strength, 0), -XNR_BLENDING_SCALE_FACTOR); ~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ XNR_BLENDING_SCALE_FACTOR is BIT(13), or 8192, which will easily fit into a signed 32-bit integer. However, it is an unsigned long, which means that negating it is the same as subtracting that value from ULONG_MAX + 1, which causes it to be larger than a signed 32-bit integer so it gets implicitly converted. We can avoid this by using the variable isp_scale, which holds the value of XNR_BLENDING_SCALE_FACTOR already, where the implicit conversion from unsigned long to s32 already happened. If that were to ever overflow, clang would warn: https://godbolt.org/z/EeSxLG Link: https://github.com/ClangBuiltLinux/linux/issues/1036 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: Remove unnecessary NULL check in atomisp_paramNathan Chancellor
Clang warns: drivers/staging/media/atomisp/pci/atomisp_cmd.c:4278:17: warning: address of 'config->info' will always evaluate to 'true' [-Wpointer-bool-conversion] if (!&config->info) { ~ ~~~~~~~~^~~~ config cannot be NULL because it comes from an ioctl, which ensures that the user is not giving us an invalid pointer through copy_from_user. If config is not NULL, info cannot be NULL. Remove this check. Link: https://github.com/ClangBuiltLinux/linux/issues/1036 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: Remove unnecessary NULL checks in ia_css_pipe_load_extensionNathan Chancellor
Clang warns: ../drivers/staging/media/atomisp/pci/sh_css.c:8537:14: warning: address of 'pipe->output_stage' will always evaluate to 'true' [-Wpointer-bool-conversion] if (&pipe->output_stage) ~~ ~~~~~~^~~~~~~~~~~~ ../drivers/staging/media/atomisp/pci/sh_css.c:8545:14: warning: address of 'pipe->vf_stage' will always evaluate to 'true' [-Wpointer-bool-conversion] if (&pipe->vf_stage) ~~ ~~~~~~^~~~~~~~ output_stage and vf_stage are pointers in the middle of a struct, their addresses cannot be NULL if pipe is not NULL and pipe is already checked for NULL in this function. Simplify this if block. Link: https://github.com/ClangBuiltLinux/linux/issues/1036 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: Remove second increment of count in atomisp_subdev_probeNathan Chancellor
Clang warns: ../drivers/staging/media/atomisp/pci/atomisp_v4l2.c:1097:3: warning: variable 'count' is incremented both in the loop header and in the loop body [-Wfor-loop-analysis] count++; ^ This was probably unintentional, remove it. Link: https://github.com/ClangBuiltLinux/linux/issues/1036 Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: Clean up if block in sh_css_sp_init_stageNathan Chancellor
Clang warns: ../drivers/staging/media/atomisp/pci/sh_css_sp.c:1039:23: warning: address of 'binary->in_frame_info' will always evaluate to 'true' [-Wpointer-bool-conversion] } else if (&binary->in_frame_info) { ~~ ~~~~~~~~^~~~~~~~~~~~~ in_frame_info is not a pointer so if binary is not NULL, in_frame_info's address cannot be NULL. Change this to an else since it will always be evaluated as one. While we are here, clean up this if block. The contents of both if blocks are the same but a check against "stage == 0" is added when ISP2401 is defined. USE_INPUT_SYSTEM_VERSION_2401 is only defined when isp2401_system_global.h is included, which only happens when ISP2401. In other words, USE_INPUT_SYSTEM_VERSION_2401 always requires ISP2401 to be defined so the '#ifndef ISP2401' makes no sense. Remove that part of the block to simplify everything. Link: https://github.com/ClangBuiltLinux/linux/issues/1036 Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: avoid OOPS due to non-existing ref_framesMauro Carvalho Chehab
stage->args->delay_frames array could point to NULL frames. What's weird is that we didn't notice this behavior with the Intel Aero Yocto code. Handle it, while adding a notice at the code, as this could be due to some broken pipeline setup. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: remove kvmalloc/kvcalloc abstractionsMauro Carvalho Chehab
The sh_css layer adds an abstraction for kvmalloc/kvcalloc. Get rid of them. Most of the work here was done by this small coccinelle script: <cocci> @@ expression size; @@ - sh_css_malloc(size) + kvmalloc(size, GFP_KERNEL) @@ expression n; expression size; @@ - sh_css_calloc(n, size) + kvcalloc(n, size, GFP_KERNEL) </cocci> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: add more comments about frame allocationMauro Carvalho Chehab
The frame allocation logic happens differently for userptr or normal mmap. On a quick look, this sounded to be unbalanced, but the logic should actually work for both cases. Add an extra comment to reflect it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: add debug functions for received eventsMauro Carvalho Chehab
For debugging purposes, it helps to know what event was actually received. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: improve warning for IRQ enable functionMauro Carvalho Chehab
If something gets wrong when enabling or disabling an IRQ, we should know better about what happened. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: add debug for hmm allocMauro Carvalho Chehab
The hmm code is still complex and has bugs. Add a debug print when memory gets allocated, in order to help identifying what's happening out there. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: use pin_user_pages() for memory allocationMauro Carvalho Chehab
Instead of using a hacked version of an old copy of get_user_pages(), use pin_user_pages(). Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: fix driver capsMauro Carvalho Chehab
This device driver is not MC-centric. So, remove the wrong caps from it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: use Yocto Aero default hmm pool sizesMauro Carvalho Chehab
Yocto Aero driver has a different default for hmm pools. Use the definitions there. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: add debug message to help debugging hmm codeMauro Carvalho Chehab
The hmm code is partially based on a fork from 3.10 code, and has bugs. Add debug there to help tracking what happens there. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
generated by cgit (git 2.34.1) at 2025-07-16 13:02:53 +0000