aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-06-11media: atomisp: improve ACPI/DMI detection logsMauro Carvalho Chehab1-6/+12
As there are several ways where the driver could possible retrieve sensor data, make the prints clearer about what was detected and from where. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: Revert "media: atomisp: add Asus Transform T101HA ACPI vars"Mauro Carvalho Chehab1-16/+0
Now that the EFI _DSM table is parsed by the driver, we don't need a DMI match anymore for Asus Transform T101HA. This reverts commit 0a76fd8e8d202dcaabc714850205d5d75c9b8271. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: Revert "media: atomisp: Add some ACPI detection info"Mauro Carvalho Chehab7-77/+0
This reverts commit 0d64e9420583cbc3c4a3f949ebe38fd8f7769281. As gmin_subdev_add() now takes the ACPI handle directly, we can deprecate the code that were doing this inside each I2C driver. PS.: This also reverts commit c03496b3bd92 ("media: atomisp: add a notice about possible leak resources") Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: improve sensor detection code to use _DSM tableMauro Carvalho Chehab2-47/+101
Instead of keep hardcoding device-specific tables, read them directly from the ACPI BIOS, if available. This method is know to work with Asus T101HA device. the same table is also visible on EzPad devices. So, it seems that at least some BIOSes use this method to pass data about ISP2401-connected sensors. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: get rid of an iomem abstraction layerMauro Carvalho Chehab18-192/+44
The hive_isp_css_custom_host_hrt.h code, together with atomisp_helper.h, provides an abstraction layer for some functions inside atomisp_compat_css20.c and atomisp_cmd.c. There's no good reason for that. In a matter of fact, after removing the abstraction, the code looked a lot cleaner and easier to understand. So, get rid of them. While here, get rid also of the udelay(1) abstraction code. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: get rid of a string_support.h abstraction layerMauro Carvalho Chehab8-215/+38
Some parts of the driver have their own implementation of memcpy() & friends. Replace all of them by strscpy(). Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: use strscpy() instead of less secure variantsMauro Carvalho Chehab8-16/+15
Replace usages of strcpy(), strlcpy() and strncpy() in favor of strscpy(). Suggested-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: set DFS to MAX if sensor doesn't report fpsMauro Carvalho Chehab1-2/+6
If the sensor doesn't implement support for g_frame_interval, it won't return the expected fps rate. Instead of keeping DFS on its minimal value (which will likely not work), set it to the max. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: use different dfs failed messagesMauro Carvalho Chehab2-5/+5
There are several parts of the driver that could produce a "dfs failed!" message. Change the texts, in order to help identifying from where they're coming. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: change the detection of ISP2401 at runtimeMauro Carvalho Chehab17-114/+108
Instead of having a static var to detect it, let's use the already-existing arch-specific bytes, as this is how other parts of the code also checks when it needs to do something different, depending on an specific chipset version. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: use macros from intel-family.hMauro Carvalho Chehab1-4/+6
Instead of hardcoding the intel family values there, use the already defined ones from asm/intel-family.h. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: don't set hpll_freq twice with different valuesMauro Carvalho Chehab1-4/+6
The logic which sets the hpll_freq for BYT sets hpll_freq to 1600MHz, but ignores it, and sets it again after reading from-device-specific EFI vars (this time, using a default of 2000MHz). Remove the first set, as this will be overriden anyway. While here, do minor adjustments on comments and on a printk message. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: get rid of a detection hack for a BYT Andorid-based tabletMauro Carvalho Chehab1-65/+18
There's a hack at the driver that selects a different table for a BYT tablet, which sets the maximum frequency to 320 MHz, instead of 400 MHz. After looking at the Intel Aero Yocto's version from: https://download.01.org/aero/deb/pool/main/l/linux-4.4.76-aero-1.3/ It was noticed that this depends on an Android-specific modprobe parameter, which uses a macro (INTEL_MID_BOARD) from this file: arch/x86/include/asm/spid.h >From the comments there, it looks like this macro parses a variable passed at boot time: cmdline : androidboot.spid=vend:cust:manu:plat:prod:hard The devices in question are identified there as: INTEL_BYT_TABLET_BLK_PRO = 0x0000 INTEL_BYT_TABLET_BLK_ENG = 0x8000 Well, this is something that we don't have upstream. So, without further details about that, we can't really parse it. If we ever end supporting those devices with the upstream driver, this patch can be reverted and the device can be detected via DMI (or maybe via PCI ID?). Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: use just one mamoiada_params.hMauro Carvalho Chehab3-216/+1
As both isp2400 and isp2401 files are identical, remove one of them and remove the test for ISP variant. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: remove some unused defines from *mamoiada_params.hMauro Carvalho Chehab2-38/+2
There are some parameters that are different between isp2400 and isp2401. None of those are actually used. So, get rid of them. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: simplify IRQ ifdef logicMauro Carvalho Chehab9-120/+2
There are lots of mess with IRQ ifdef settings. As the *_global.h will already detect the type of IRQ system at compile time, we can get rid of them, replacing by just one ifdef for ISP2401. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: get rid of ifdef nonsenseMauro Carvalho Chehab1-8/+8
There are some ifdefs there that end doing the same thing. Get rid of them. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: get rid of a duplicated fileMauro Carvalho Chehab3-78/+1
The contents of hive_isp_css_2401_irq_types_hrt.h and hive_isp_css_common/irq_global.h are identical, except for one unused enum: On isp2401, this IRQ line has this name: hrt_isp_css_irq_is2401 = HIVE_GP_DEV_IRQ_ISP_PMEM_ERROR_BIT_ID, While the same bit is named as: hrt_isp_css_irq_isp_pmem_error = HIVE_GP_DEV_IRQ_ISP_PMEM_ERROR_BIT_ID, At the isp2400 version. Remove one of them, in order to reduce the code differences between those two versions. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: do some cleanup at irq_local.hMauro Carvalho Chehab5-44/+30
- Get rid of typedefs; - Get rid of a duplicated enum type with different names for ISP2400 and ISP2401; - adjust indentation on the touched code. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: improve IRQ handling debug messagesMauro Carvalho Chehab1-5/+6
When an IRQ is not handled, it is nice to know what's the reason. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: comment an unused codeMauro Carvalho Chehab1-0/+8
There's a different table for some BYT variants that depend on something inside a FIXME ifdef. Place this also inside it, just to shut up a clang-11 warning. Reported-by: kbuild test robot <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: get rid of a left-over wrapper functionMauro Carvalho Chehab1-8/+0
The abstraction layer for kvfree() was removed, but there is still a left-over code there. Reported-by: kbuild test robot <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: get rid of an unused IRQ duplicated eventMauro Carvalho Chehab1-4/+1
There are two names for the same IRQ, but just one is used. Remove the unused one. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: get rid of sh_css_pipe.cMauro Carvalho Chehab2-18/+0
There's nothing there, just comments. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: staging: media: atomisp: fix stack overflow in init_pipe_defaults()Arnd Bergmann9-42/+46
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 <[email protected]> Fixes: 6dc9a2568f84 ("media: atomisp: convert default struct values to use compound-literals with designated initializers") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: re-enable warnings againMauro Carvalho Chehab7-30/+30
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 <[email protected]>
2020-06-11media: atomisp: remove format duplication at mbus->fourcc tableMauro Carvalho Chehab3-26/+25
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 <[email protected]>
2020-06-11media: staging: media: atomisp: add PMIC_OPREGION dependencyArnd Bergmann1-0/+1
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 <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: staging: media: atomisp: disable all custom formatsArnd Bergmann1-0/+2
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 <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: staging: media: atomisp: fix enum type mixupsArnd Bergmann1-5/+5
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 <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: staging: media: atomisp: declare 'struct device' before using itArnd Bergmann1-0/+1
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 <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: add SPDX headersMauro Carvalho Chehab657-0/+657
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 <[email protected]>
2020-06-11media: staging: atomisp: Check return value from compat_alloc_user_spaceSakari Ailus1-0/+2
If something gets wrong, return, instead of trying to convert from a NULL pointer. Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: staging: atomisp: Fix compat IOCTL handlingSakari Ailus1-463/+471
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 <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: staging: atomisp: Fix atomisp_overlay32 compat handlingSakari Ailus1-2/+4
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 <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: staging: atomisp: There's no struct atomisp_dvs2_coefficientsSakari Ailus3-4/+4
It's called struct atomisp_dis_coefficients. Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2020-06-11media: atomisp: add some debug messages when binaries are usedMauro Carvalho Chehab1-4/+27
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 <[email protected]>
2020-06-11media: atomisp: add a debug message at hmm freeMauro Carvalho Chehab1-0/+2
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 <[email protected]>
2020-06-11media: atomisp: allow passing firmware name at modprobe timeMauro Carvalho Chehab1-13/+21
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 <[email protected]>
2020-06-11media: atomisp: print firmware data during loadMauro Carvalho Chehab1-1/+48
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 <[email protected]>
2020-06-11media: atomisp: provide more details about the firmware binariesMauro Carvalho Chehab3-5/+40
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 <[email protected]>
2020-06-11KVM: selftests: fix sync_with_host() in smm_testVitaly Kuznetsov1-2/+2
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 <[email protected]> Signed-off-by: Vitaly Kuznetsov <[email protected]> Message-Id: <[email protected]> Reviewed-by: Jim Mattson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-06-11KVM: async_pf: Inject 'page ready' event only if 'page not present' was ↵Vitaly Kuznetsov6-6/+12
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 <[email protected]> Signed-off-by: Vitaly Kuznetsov <[email protected]> Message-Id: <[email protected]> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=208081 Signed-off-by: Paolo Bonzini <[email protected]>
2020-06-11KVM: async_pf: Cleanup kvm_setup_async_pf()Vitaly Kuznetsov1-13/+6
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 <[email protected]> Message-Id: <[email protected]> Reviewed-by: Sean Christopherson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-06-11kvm: i8254: remove redundant assignment to pointer sColin Ian King1-1/+0
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 <[email protected]> Message-Id: <[email protected]> Fixes: 7837699fa6d7 ("KVM: In kernel PIT model") Signed-off-by: Paolo Bonzini <[email protected]>
2020-06-11KVM: x86: respect singlestep when emulating instructionFelipe Franciosi1-1/+1
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: [email protected] Signed-off-by: Felipe Franciosi <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-06-11KVM: selftests: Don't probe KVM_CAP_HYPERV_ENLIGHTENED_VMCS when nested VMX ↵Vitaly Kuznetsov2-3/+5
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 <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-06-11KVM: selftests: do not substitute SVM/VMX check with KVM_CAP_NESTED_STATE checkVitaly Kuznetsov6-17/+30
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 <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-06-11Merge branch 'kvm-basic-exit-reason' into HEADPaolo Bonzini1-2/+2
Using a topic branch so that stable branches can simply cherry-pick the patch. Reviewed-by: Oliver Upton <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-06-11media: atomisp: get rid of system_types.hMauro Carvalho Chehab28-51/+27
This is just a wrapper for system_local.h. Signed-off-by: Mauro Carvalho Chehab <[email protected]>