- 31 May, 2019 40 commits
-
-
James Smart authored
[ Upstream commit c66a9197 ] If the driver undergoes repeated host resets it starts losing exchange structures and eventually returns SCSI_MLQUEUE_HOST_BUSY and does not recover. The offline path is not reclaiming the outstanding ios on the fcp pring txcmplq before calling lpfc_destroy_multixripool, which causes the txmcplq to be reinit and the resources lost. Flush the fcp rings before destroying the multixripools. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
James Smart authored
[ Upstream commit 32a80c09 ] The driver is reporting support for NVME even when not configured for NVME operation. Fix (and make more readable) when NVME protocol support is indicated. Signed-off-by:
-
James Smart authored
[ Upstream commit d67f935b ] The FDMI manufacturer value being reported on Linux is inconsistent with other OS's. Set the value to "Emulex Corporation" for consistency. Signed-off-by:
-
Jernej Skrabec authored
[ Upstream commit 70a4f5cd ] H6 VPU doesn't work if DMA offset is set. Add a quirk for it. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit ea6c7e34 ] It is not possible to use devm_kzalloc since that memory is freed immediately when the device instance is unbound. Various objects like the video device may still be in use since someone has the device node open, and when that is closed it expects the memory to be around. So use kzalloc and release it at the appropriate time. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit f74267b5 ] The media_device is part of a static global vimc_device struct. The media framework expects this to be zeroed before it is used, however, since this is a global this is not the case if vimc is unbound and then bound again. So call memset to ensure any left-over values are cleared. Signed-off-by:
-
Steve Longerbeam authored
[ Upstream commit ce3c2433 ] Restore a default case to prepare_vdi_in_buffers() to fix the following smatch errors: drivers/staging/media/imx/imx-media-vdic.c:236 prepare_vdi_in_buffers() error: uninitialized symbol 'prev_phys'. drivers/staging/media/imx/imx-media-vdic.c:237 prepare_vdi_in_buffers() error: uninitialized symbol 'curr_phys'. drivers/staging/media/imx/imx-media-vdic.c:238 prepare_vdi_in_buffers() error: uninitialized symbol 'next_phys'. Fixes: 6e537b58 ("media: imx: vdic: rely on VDIC for correct field order") Reported-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
-
Alexandre Courbot authored
[ Upstream commit 3235d394 ] Commit 0650a914 ("media: mtk-vcodec: Correct return type for mem2mem buffer helpers") fixed the return types for mem2mem buffer helper functions, but omitted two occurrences that are accessed in the mtk_v4l2_debug() macro. These only trigger compiler errors when DEBUG is defined. Fixes: 0650a914 ("media: mtk-vcodec: Correct return type for mem2mem buffer helpers") Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit ed713a4a ] clang-8 warns about one function here when KASAN is enabled, even without the 'asan-stack' option: drivers/media/usb/go7007/go7007-fw.c:1551:5: warning: stack frame size of 2656 bytes in function I have reported this issue in the llvm bugzilla, but to make it work with the clang-8 release, a small annotation is still needed. Link: https://bugs.llvm.org/show_bug.cgi?id=38809Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit e855165f ] Clang-9 makes some different inlining decisions compared to gcc, which leads to a warning about a possible stack overflow problem when building with CONFIG_KASAN, including when setting asan-stack=0, which avoids most other frame overflow warnings: drivers/media/platform/vicodec/codec-fwht.c:673:12: error: stack frame size of 2224 bytes in function 'encode_plane' Manually adding noinline_for_stack annotations in those functions called by encode_plane() or decode_plane() that require a significant amount of kernel stack makes this impossible to happen with any compiler. Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit e6f8bd59 ] When streaming is stopped all URBs are killed, but in fill_frame and in bulk_irq this results in an attempt to resubmit the killed URB. That is not what you want and causes spurious kernel messages. So check if streaming has stopped before resubmitting. Also check against gspca_dev->streaming rather than vb2_start_streaming_called() since vb2_start_streaming_called() will return true when in stop_streaming, but gspca_dev->streaming is set to false when stop_streaming is called. Fixes: 6992effe ("gspca: Kill all URBs before releasing any of them") Signed-off-by:
-
Helen Fornazier authored
[ Upstream commit 2978a505 ] The state TASK_UNINTERRUPTIBLE should be set just before schedule_timeout() call, so it knows the sleep mode it should enter. There is no point in setting TASK_UNINTERRUPTIBLE at the initialization of the thread as schedule_timeout() will set the state back to TASK_RUNNING. This fixes a warning in __might_sleep() call, as it's expecting the task to be in TASK_RUNNING state just before changing the state to a sleeping state. Reported-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 63a06181 ] devm_reset_control_get could fail, so the fix checks its return value and passes the error code upstream in case it fails. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Acked-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[ Upstream commit b9952f93 ] [Why] The kms_plane@plane-position-covered-pipe-*-planes subtests can produce a sequence of atomic commits such that neither active_changed nor mode_changed but connectors_changed. When this happens we remove the old stream from the context and add a new stream but the new stream doesn't have mode_changed=true set. This incorrect programming sequence causes CRC mismatches to occur in the test. The stream->mode_changed value should be set whenever a new stream is created. [How] A new stream is created whenever drm_atomic_crtc_needs_modeset is true. We previously covered the active_changed and mode_changed conditions for the CRTC but connectors_changed is also checked within drm_atomic_crtc_needs_modeset. So just use drm_atomic_crtc_needs_modeset directly to determine the mode_changed flag. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Sun peng Li <Sunpeng.Li@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Martin Leung authored
[ Upstream commit 162f8078 ] [Why] used to be unable to run 4:2:0 if using a dongle because 4k60 bandwidth exceeded dongle caps [How] half pixel clock during comparison to dongle cap. *Could get stuck on black screen on monitor that don't support 420 but will be selecting 420 as preferred mode* Signed-off-by:
Martin Leung <martin.leung@amd.com> Reviewed-by:
Wenjing Liu <Wenjing.Liu@amd.com> Acked-by:
Aidan Wood <Aidan.Wood@amd.com> Acked-by:
-
David Francis authored
[ Upstream commit f9181399 ] [Why] The dc_gamma_type CUSTOM_GAMMA is used to represent degamma mappings passed in by drm. This type of gamma must be interpolated into a transfer function by apply_1d_lut. The line in mod_color_calculate_degamma_params that handled this case was erroneously removed. [How] For CUSTOM_GAMMA degamma, calculate the lut as before. Signed-off-by:
David Francis <David.Francis@amd.com> Reviewed-by:
Krunoslav Kovac <Krunoslav.Kovac@amd.com> Acked-by:
-
Murton Liu authored
[ Upstream commit 59979bf8 ] Check if we get any values equal to 0, and set to 1 if so. Signed-off-by:
Murton Liu <murton.liu@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
Sivapiriyan Kumarasamy <Sivapiriyan.Kumarasamy@amd.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 49dc762c ] The driver should really call dm365_isif_setup_pinmux() through a callback, but uses a hack to include a davinci specific machine header file when compile testing instead. This works almost everywhere, but not on the ARM omap1 platform, which has another header named mach/mux.h. This causes a build failure: drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:2: error: implicit declaration of function 'davinci_cfg_reg' [-Werror,-Wimplicit-function-declaration] davinci_cfg_reg(DM365_VIN_CAM_WEN); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:2: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes] drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:18: error: use of undeclared identifier 'DM365_VIN_CAM_WEN' davinci_cfg_reg(DM365_VIN_CAM_WEN); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2029:18: error: use of undeclared identifier 'DM365_VIN_CAM_VD' davinci_cfg_reg(DM365_VIN_CAM_VD); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2030:18: error: use of undeclared identifier 'DM365_VIN_CAM_HD' davinci_cfg_reg(DM365_VIN_CAM_HD); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2031:18: error: use of undeclared identifier 'DM365_VIN_YIN4_7_EN' davinci_cfg_reg(DM365_VIN_YIN4_7_EN); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2032:18: error: use of undeclared identifier 'DM365_VIN_YIN0_3_EN' davinci_cfg_reg(DM365_VIN_YIN0_3_EN); ^ 7 errors generated. Exclude omap1 from compile-testing, under the assumption that all others still work. Fixes: 4907c73d ("media: staging: davinci_vpfe: allow building with COMPILE_TEST") Signed-off-by:
-
Wenjing Liu authored
[ Upstream commit e6bddf6c ] [why] Stream update will adjust both info packets and stream params, need to make sure all things are applied togather. [how] add pipe lock during stream update Signed-off-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
James Hutchinson authored
[ Upstream commit 981fbe3d ] Ref: https://bugzilla.kernel.org/show_bug.cgi?id=199323 Users are experiencing problems with the DVBSky S960/S960C USB devices since the following commit: 9d659ae1: ("locking/mutex: Add lock handoff to avoid starvation") The device malfunctions after running for an indeterminable period of time, and the problem can only be cleared by rebooting the machine. It is possible to encourage the problem to surface by blocking the signal to the LNB. Further debugging revealed the cause of the problem. In the following capture: - thread #1325 is running m88ds3103_set_frontend - thread #42 is running ts2020_stat_work a> [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 07 80 [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 08 [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 68 3f [42] usb 1-1: dvb_usb_v2_generic_io: <<< 08 ff [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 3d [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff b> [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 07 00 [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07 [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 21 [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 66 [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11 [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07 [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 60 02 10 0b [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07 Two i2c messages are sent to perform a reset in m88ds3103_set_frontend: a. 0x07, 0x80 b. 0x07, 0x00 However, as shown in the capture, the regmap mutex is being handed over to another thread (ts2020_stat_work) in between these two messages. >From here, the device responds to every i2c message with an 07 message, and will only return to normal operation following a power cycle. Use regmap_multi_reg_write to group the two reset messages, ensuring both are processed before the regmap mutex is unlocked. Signed-off-by:
James Hutchinson <jahutchinson99@googlemail.com> Reviewed-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Stefan Brüns authored
[ Upstream commit fdfa59cd ] Commit 14f4eaed ("media: dvbsky: fix driver unregister logic") fixed a use-after-free by removing the reference to the frontend after deleting the backing i2c device. This has the unfortunate side effect the frontend device is never freed in the dvb core leaving a dangling device, leading to errors when the dvb core tries to register the frontend after e.g. a replug as reported here: https://www.spinics.net/lists/linux-media/msg138181.html media: dvbsky: issues with DVBSky T680CI === [ 561.119145] sp2 8-0040: CIMaX SP2 successfully attached [ 561.119161] usb 2-3: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)... [ 561.119174] sysfs: cannot create duplicate filename '/class/dvb/ dvb0.frontend0' === The use after free happened as dvb_usbv2_disconnect calls in this order: - dvb_usb_device::props->exit(...) - dvb_usbv2_adapter_frontend_exit(...) + if (fe) dvb_unregister_frontend(fe) + dvb_usb_device::props->frontend_detach(...) Moving the release of the i2c device from exit() to frontend_detach() avoids the dangling pointer access and allows the core to unregister the frontend. This was originally reported for a DVBSky T680CI, but it also affects the MyGica T230C. As all supported devices structure the registration/ unregistration identically, apply the change for all device types. Signed-off-by:
Stefan Brüns <stefan.bruens@rwth-aachen.de> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 0ab34a08 ] si2165_readreg8() may fail. Looking into si2165_readreg8(), we will find that "val_tmp" will be an uninitialized value when regmap_read() fails. "val_tmp" is then assigned to "val". So if si2165_readreg8() fails, "val" will be a random value. Further use will lead to undefined behaviors. The fix checks if si2165_readreg8() fails, and if so, returns its error code upstream. Signed-off-by:
Matthias Schwarzott <zzam@gentoo.org> Tested-by:
-
Kai-Heng Feng authored
[ Upstream commit 5b6e1321 ] igb sets different WoL settings in system suspend callback and runtime suspend callback. The suspend direct complete optimization leaves igb in runtime suspended state with wrong WoL setting during system suspend. To fix this, we need to disable suspend direct complete optimization to let igb always use suspend callback to set correct WoL during system suspend. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Noralf Trønnes authored
[ Upstream commit a89bfc5d ] Buffers passed to spi_sync() must be dma-safe even for tiny buffers since some SPI controllers use DMA for all transfers. Example splat with CONFIG_DMA_API_DEBUG enabled: [ 23.750467] DMA-API: dw_dmac_pci 0000:00:15.0: device driver maps memory from stack [probable addr=000000001e49185d] [ 23.750529] WARNING: CPU: 1 PID: 1296 at kernel/dma/debug.c:1161 check_for_stack+0xb7/0x190 [ 23.750533] Modules linked in: mmc_block(+) spi_pxa2xx_platform(+) pwm_lpss_pci pwm_lpss spi_pxa2xx_pci sdhci_pci cqhci intel_mrfld_pwrbtn extcon_intel_mrfld sdhci intel_mrfld_adc led_class mmc_core ili9341 mipi_dbi tinydrm backlight ti_ads7950 industrialio_triggered_buffer kfifo_buf intel_soc_pmic_mrfld hci_uart btbcm [ 23.750599] CPU: 1 PID: 1296 Comm: modprobe Not tainted 5.0.0-rc7+ #236 [ 23.750605] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [ 23.750620] RIP: 0010:check_for_stack+0xb7/0x190 [ 23.750630] Code: 8b 6d 50 4d 85 ed 75 04 4c 8b 6d 10 48 89 ef e8 2f 8b 44 00 48 89 c6 4a 8d 0c 23 4c 89 ea 48 c7 c7 88 d0 82 b4 e8 40 7c f9 ff <0f> 0b 8b 05 79 00 4b 01 85 c0 74 07 5b 5d 41 5c 41 5d c3 8b 05 54 [ 23.750637] RSP: 0000:ffff97bbc0292fa0 EFLAGS: 00010286 [ 23.750646] RAX: 0000000000000000 RBX: ffff97bbc0290000 RCX: 0000000000000006 [ 23.750652] RDX: 0000000000000007 RSI: 0000000000000002 RDI: ffff94b33e115450 [ 23.750658] RBP: ffff94b33c8578b0 R08: 0000000000000002 R09: 00000000000201c0 [ 23.750664] R10: 00000006ecb0ccc6 R11: 0000000000034f38 R12: 000000000000316c [ 23.750670] R13: ffff94b33c84b250 R14: ffff94b33dedd5a0 R15: 0000000000000001 [ 23.750679] FS: 0000000000000000(0000) GS:ffff94b33e100000(0063) knlGS:00000000f7faf690 [ 23.750686] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 23.750691] CR2: 00000000f7f54faf CR3: 000000000722c000 CR4: 00000000001006e0 [ 23.750696] Call Trace: [ 23.750713] debug_dma_map_sg+0x100/0x340 [ 23.750727] ? dma_direct_map_sg+0x3b/0xb0 [ 23.750739] spi_map_buf+0x25a/0x300 [ 23.750751] __spi_pump_messages+0x2a4/0x680 [ 23.750762] __spi_sync+0x1dd/0x1f0 [ 23.750773] spi_sync+0x26/0x40 [ 23.750790] mipi_dbi_typec3_command_read+0x14d/0x240 [mipi_dbi] [ 23.750802] ? spi_finalize_current_transfer+0x10/0x10 [ 23.750821] mipi_dbi_typec3_command+0x1bc/0x1d0 [mipi_dbi] Reported-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Tested-by:
-
Kai-Heng Feng authored
[ Upstream commit 459d69c4 ] There are some new e1000e devices can only be woken up from D3 one time, by plugging Ethernet cable. Subsequent cable plugging does set PME bit correctly, but it still doesn't get woken up. Since e1000e connects to the root complex directly, we rely on ACPI to wake it up. In this case, the GPE from _PRW only works once and stops working after that. Though it appears to be a platform bug, e1000e maintainers confirmed that I219 does not support D3. So disable runtime PM on CNP+ chips. We may need to disable earlier generations if this bug also hit older platforms. Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=280819Signed-off-by:
-
Akeem G Abodunrin authored
[ Upstream commit 42b2cc83 ] This patch fixes issues with VF queues being disabled, and VF netdev network carrier being lost after reset. Basically, we need to check if VF is enabled, and queue configured in reset_all_vfs flow, and disable/enable those queues appropriately whenever the function is called after Global/CORER/PFR reset/rebuild/replay. Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 76eb24fc ] When start_streaming was called both last_src_buf and last_dst_buf pointers were set to NULL, but this depends on whether the capture or output queue starts streaming. When decoding with resolution changes in between the capture queue has to restart streaming whenever a resolution change occurs. And that would reset last_src_buf as well, which causes a problem if the decoder was stopped by the application. Since last_src_buf is now NULL, the LAST flag is never set for the last capture buffer. Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 948dff7c ] The imgu_rpm_dummy_cb() looks like an API misuse that is explained in the comment above it. Aside from that, it also causes a warning when power management support is disabled: drivers/staging/media/ipu3/ipu3.c:794:12: error: 'imgu_rpm_dummy_cb' defined but not used [-Werror=unused-function] The warning is at least easy to fix by marking the function as __maybe_unused. Fixes: 7fc7af64 ("media: staging/intel-ipu3: Add imgu top level pci device driver") Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Akinobu Mita authored
[ Upstream commit 32ab688b ] Since commit 3d6a8fe2 ("media: ov7670: hook s_power onto v4l2 core"), the device is actually powered off while the video stream is stopped. The frame format and framerate are restored right after power-up, but restoring the default register settings is forgotten. Fixes: 3d6a8fe2 ("media: ov7670: hook s_power onto v4l2 core") Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Reviewed-by:
Lubomir Rintel <lkundrak@v3.sk> Tested-by:
-
Sakari Ailus authored
[ Upstream commit fff35d45 ] C-PHY has no clock lanes. Therefore the first data lane is 0 by default. Fixes: edc6d56c ("media: v4l: fwnode: Support parsing of CSI-2 C-PHY endpoints") Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 106204b5 ] In case kzalloc fails, the fix releases resources and returns -ENOMEM to avoid the NULL pointer dereference. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[ Upstream commit eec3d5ef ] [Why] The plane_reset callback is subclassed but hasn't been updated since the drm helper got updated to include resetting alpha related state (state->alpha and state->pixel_blend_mode). The overlay planes exposed by amdgpu_dm were therefore being rendered as invisible by default ever since supported was exposed for alpha blending properties on overlays. This caused regressions in igt@kms_plane_multiple@atomic-tiling-none and igt@kms_plane@plane-position-covered-pipe tests. [How] Reset the plane state values to their correct values as defined in the drm helper. This fixes the IGT test regression. Signed-off-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
-
David Francis authored
[ Upstream commit b05e2c5e ] [Why] Somewhere in the atomic check reshuffle ABM got lost. ABM is a crtc property (copied from a connector property). It can change without a modeset, just like underscan. [How] In the skip_modeset branch of atomic check crtc updates, copy over the abm property. Signed-off-by:
-
Samson Tam authored
[ Upstream commit 66acd441 ] [Why] In certain cases we do link training when we don't have a backend. [How] In dc_link_set_preferred_link_settings(), store preferred link settings first and then verify that the link is DP and the link stream's backend is enabled. If either is false, then we will not do any link retraining. Signed-off-by:
Samson Tam <Samson.Tam@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Dmytro Laktyushkin authored
[ Upstream commit bc219399 ] Releasing planes should not release the 2nd odm pipe right away, this change leaves us with 2 pipes with null planes and same stream when planes are released during odm. Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
Arnd Bergmann authored
[ Upstream commit 7287275b ] The regulator header has empty inline functions for most interfaces, but not regulator_get_linear_step(), which has just grown a user that does not depend on regulators otherwise: drivers/clk/tegra/clk-tegra124-dfll-fcpu.c: In function 'get_alignment_from_regulator': drivers/clk/tegra/clk-tegra124-dfll-fcpu.c:555:19: error: implicit declaration of function 'regulator_get_linear_step'; did you mean 'regulator_get_drvdata'? [-Werror=implicit-function-declaration] align->step_uv = regulator_get_linear_step(reg); ^~~~~~~~~~~~~~~~~~~~~~~~~ regulator_get_drvdata cc1: all warnings being treated as errors scripts/Makefile.build:278: recipe for target 'drivers/clk/tegra/clk-tegra124-dfll-fcpu.o' failed Add the missing stub along the others. Fixes: b3cf8d06 ("clk: tegra: dfll: CVB calculation alignment with the regulator") Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit ca1438dc ] The newly added tracepoints in the spi-mxs driver cause a link error when the driver is a loadable module: ERROR: "__tracepoint_spi_transfer_stop" [drivers/spi/spi-mxs.ko] undefined! ERROR: "__tracepoint_spi_transfer_start" [drivers/spi/spi-mxs.ko] undefined! I'm not quite sure where to put the export statements, but directly after the inclusion of the header seems as good as any other place. Fixes: f3fdea3a ("spi: mxs: add tracing to custom .transfer_one_message callback") Signed-off-by:
-
Aditya Pakki authored
[ Upstream commit 2cc12751 ] Memory allocated via kmemdup might fail and return a NULL pointer. This patch adds a check on the return value of kmemdup and passes the error upstream. Signed-off-by:
Aditya Pakki <pakki001@umn.edu> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
-
Aditya Pakki authored
[ Upstream commit 9aabb685 ] In enumerate_services, ida_simple_get on failure can return an error and leaks memory. The patch ensures that the dev_set_name is set on non failure cases, and releases memory during failure. Signed-off-by:
-
Rouven Czerwinski authored
[ Upstream commit 62f95ae8 ] Newer combinations of the glibc, kernel and openssh can result in long initial startup times on OMAP devices: [ 6.671425] systemd-rc-once[102]: Creating ED25519 key; this may take some time ... [ 142.652491] systemd-rc-once[102]: Creating ED25519 key; done. due to the blocking getrandom(2) system call: [ 142.610335] random: crng init done Set the quality level for the omap hwrng driver allowing the kernel to use the hwrng as an entropy source at boot. Signed-off-by:
Rouven Czerwinski <r.czerwinski@pengutronix.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
