- 31 May, 2019 40 commits
-
-
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:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
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:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-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:
Martin K. Petersen <martin.petersen@oracle.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:
-
George Hilliard authored
[ Upstream commit d4223e06 ] The buffer descriptor setup loop is correct only if it is setting up at least one bd struct. Besides, there is an error if dma_map_sg() returns 0, which is possible and must be handled. Additionally, remove the BUG_ON() checking sglen, which is unnecessary because we configure DMA with that constraint during init. Signed-off-by:
George Hilliard <thirtythreeforty@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Saeed Mahameed authored
[ Upstream commit ee576ec1 ] Amazingly a mlx5e_tc function is being called from the eswitch layer, which is by itself very terrible! The function was declared locally in eswitch_offloads.c so it could be used there, which caused the following compilation warning, fix that. drivers/.../mlx5/core/en_tc.c:3242:6: [-Werror=missing-prototypes] error: no previous prototype for ‘mlx5e_tc_clean_fdb_peer_flows’ Fixes: 04de7dda ("net/mlx5e: Infrastructure for duplicated offloading of TC flows") Reviewed-by:
Roi Dayan <roid@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Pu Wen authored
[ Upstream commit e0ceeae7 ] The Hygon family 18h multi-die processor platform supports 1, 2 or 4-Dies per socket. The topology looks like this: System View (with 1-Die 2-Socket): |------------| ------ ----- SOCKET0 | D0 | | D1 | SOCKET1 ------ ----- System View (with 2-Die 2-socket): -------------------- | -------------|------ | | | | ------------ ------------ SOCKET0 | D1 -- D0 | | D3 -- D2 | SOCKET1 ------------ ------------ System View (with 4-Die 2-Socket) : -------------------- | -------------|------ | | | | ------------ ------------ | D1 -- D0 | | D7 -- D6 | | | \/ | | | | \/ | | SOCKET0 | | /\ | | | | /\ | | SOCKET1 | D2 -- D3 | | D4 -- D5 | ------------ ------------ | | | | ------|------------| | -------------------- Currently phys_proc_id = initial_apicid >> bits calculates the physical processor ID from the initial_apicid by shifting *bits*. However, this does not work for 1-Die and 2-Die 2-socket systems. According to document [1] section 2.1.11.1, the bits is the value of CPUID_Fn80000008_ECX[12:15]. The possible values are 4, 5 or 6 which mean: 4 - 1 die 5 - 2 dies 6 - 3/4 dies. Hygon programs the initial ApicId the same way as AMD. The ApicId is read from CPUID_Fn00000001_EBX (see section 2.1.11.1 of referrence [1]) and the definition is as below (see section 2.1.10.2.1.3 of [1]): ------------------------------------------------- Bit | 6 | 5 4 | 3 | 2 1 0 | |-----------|---------|--------|----------------| IDs | Socket ID | Node ID | CCX ID | Core/Thread ID | ------------------------------------------------- So for 3/4-Die configurations, the bits variable is 6, which is the same as the ApicID definition field. For 1-Die and 2-Die configurations, bits is 4 or 5, which will cause the right shifted result to not be exactly the value of socket ID. However, the socket ID should be obtained from ApicId[6]. To fix the problem and match the ApicID field definition, set the shift bits to 6 for all Hygon family 18h multi-die CPUs. Because AMD doesn't have 2-Socket systems with 1-Die/2-Die processors (see reference [2]), this doesn't need to be changed on the AMD side but only for Hygon. References: [1] https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf [2] https://www.amd.com/en/products/specifications/processors [bp: heavily massage commit message. ] Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Thomas Lendacky <Thomas.Lendacky@amd.com> Cc: Yazen Ghannam <yazen.ghannam@amd.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1553355740-19999-1-git-send-email-puwen@hygon.cnSigned-off-by:
-
Sameer Pujar authored
[ Upstream commit f6ed6491 ] adma driver is using pm_clk_*() interface for managing clock resources. With this it is observed that clocks remain ON always. This happens on Tegra devices which use BPMP co-processor to manage clock resources, where clocks are enabled during prepare phase. This is necessary because clocks to BPMP are always blocking. When pm_clk_*() interface is used on such Tegra devices, clock prepare count is not balanced till remove call happens for the driver and hence clocks are seen ON always. Thus this patch replaces pm_clk_*() with devm_clk_*() framework. Suggested-by:
Mohan Kumar D <mkumard@nvidia.com> Reviewed-by:
Jonathan Hunter <jonathanh@nvidia.com> Signed-off-by:
Sameer Pujar <spujar@nvidia.com> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Linus Lüssing authored
[ Upstream commit 099e6cc1 ] Currently incoming ARP Replies, for example via a DHT-PUT message, do not update the timeout for an already existing DAT entry. These ARP Replies are dropped instead. This however defeats the purpose of the DHCPACK snooping, for instance. Right now, a DAT entry in the DHT will be purged every five minutes, likely leading to a mesh-wide ARP Request broadcast after this timeout. Which then recreates the entry. The idea of the DHCPACK snooping is to be able to update an entry before a timeout happens, to avoid ARP Request flooding. This patch fixes this issue by updating a DAT entry on incoming ARP Replies even if a matching DAT entry already exists. While still filtering the ARP Reply towards the soft-interface, to avoid duplicate messages on the client device side. Signed-off-by:
Linus Lüssing <linus.luessing@c0d3.blue> Acked-by:
Antonio Quartulli <a@unstable.cc> Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 98bbbb76 ] clang correctly points out a code path that would lead to an uninitialized variable use: security/selinux/netlabel.c:310:6: error: variable 'addr' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (ip_hdr(skb)->version == 4) { ^~~~~~~~~~~~~~~~~~~~~~~~~ security/selinux/netlabel.c:322:40: note: uninitialized use occurs here rc = netlbl_conn_setattr(ep->base.sk, addr, &secattr); ^~~~ security/selinux/netlabel.c:310:2: note: remove the 'if' if its condition is always true if (ip_hdr(skb)->version == 4) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ security/selinux/netlabel.c:291:23: note: initialize the variable 'addr' to silence this warning struct sockaddr *addr; ^ = NULL This is probably harmless since we should not see ipv6 packets of CONFIG_IPV6 is disabled, but it's better to rearrange the code so this cannot happen. Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Dave Ertman authored
[ Upstream commit 2ebd4428 ] In the current implementation of ice_reset_subtask, if multiple reset types are set in the pf->state, the most intrusive one is meant to be performed only, but the bits requesting the other types are not being cleared. This would lead to another reset being performed the next time the service task is scheduled. Change the flow of ice_reset_subtask so that all reset request bits in pf->state are cleared, and we still perform the most intrusive of the resets requested. Signed-off-by:
Dave Ertman <david.m.ertman@intel.com> Signed-off-by:
-
