summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-01-13drm/amd/pm: clean up get_allowed_feature_mask functionHuang Rui
The get_allowed_feature_mask is superfluous on vangogh. Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/pm: enhance the real response for smu message (v2)Huang Rui
The user prefers to know the real response value from C2PMSG 90 register which is written by firmware not -EIO. v2: return C2PMSG 90 value Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/pm: remove vcn/jpeg powergating feature checking for vangoghHuang Rui
VCN/JPEG PG won't be a feature mask bit which exposed by vangogh smu firmware. So remove it. Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amdkfd: Fix out-of-bounds read in kdf_create_vcrat_image_cpu()Jeremy Cline
KASAN reported a slab-out-of-bounds read of size 1 in kdf_create_vcrat_image_cpu(). This occurs when, for example, when on an x86_64 with a single NUMA node because kfd_fill_iolink_info_for_cpu() is a no-op, but afterwards the sub_type_hdr->length, which is out-of-bounds, is read and multiplied by entries. Fortunately, entries is 0 in this case so the overall crat_table->length is still correct. Check if there were any entries before de-referencing sub_type_hdr which may be pointing to out-of-bounds memory. Fixes: b7b6c38529c9 ("drm/amdkfd: Calculate CPU VCRAT size dynamically (v2)") Suggested-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Jeremy Cline <jcline@redhat.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amdgpu: Decrease compute timeout to 10 s for sriov multiple VFEmily.Deng
For multiple VF, after engine hang,as host driver will first encounter FLR, so has no meanning to set compute to 60s. v2: Refine the patch and comment Signed-off-by: Emily.Deng <Emily.Deng@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13Revert "drm/amd/display: Fixed Intermittent blue screen on OLED panel"Rodrigo Siqueira
commit a861736dae64 ("drm/amd/display: Fixed Intermittent blue screen on OLED panel") causes power regression for many users. It seems that this change causes the MCLK to get forced high; this creates a regression for many users since their devices were not able to drop to a low state after this change. For this reason, this reverts commit a861736dae644a0d7abbca0c638ae6aad28feeb8. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1407 Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Naveed Ashfaq <Naveed.Ashfaq@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Roman Li <roman.li@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: change SMU repsonse timeout to 2sCharlene Liu
[why] driver has sent PMFW VBIOSSMC_MSG_SetDisplayIdleOptimizations while SMU still processing a previous VBIOSSMC_MSG_SetHardMinDcfclkByFreq message. [how] same as RN, change the time out to2s. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: disable dcn10 pipe split by defaultLi, Roman
[Why] The initial purpose of dcn10 pipe split is to support some high bandwidth mode which requires dispclk greater than max dispclk. By initial bring up power measurement data, it showed power consumption is less with pipe split for dcn block. This could be reason for enable pipe split by default. By battery life measurement of some Chromebooks, result shows battery life is longer with pipe split disabled. [How] Disable pipe split by default. Pipe split could be still enabled when required dispclk is greater than max dispclk. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Roman Li <Roman.Li@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: 3.2.118Aric Cyr
Signed-off-by: Aric Cyr <aric.cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: Add a missing DCN3.01 API mappingNikola Cornij
[why] Required for DSC MST Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Nikola Cornij <nikola.cornij@amd.com> Reviewed-by: Zhan Liu <Zhan.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: enable HUBP blank behaviourBhawanpreet Lakha
- Reverts "drm/amd/display: Revert HUBP blank behaviour for now" - Hubp blank will fail if the pipe is locked (this is the case on linux), so add a check to make sure pipe isn't locked, if it is then defer the blank to post_unlock. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: New sequence for HUBP blankWesley Chalmers
[WHY] DCN30 has a bug where blanking HUBP blocks pstate allow unless HUBP_DISABLE is toggled afterwards. [HOW] Create a HW sequence for blanking HUBP. 1. Wait for enter VBLANK 2. Set HUBP_BLANK 3. Make sure HUBP_IN_BLANK = 1 4. Toggle HUBP_DISABLE on and off to perform soft reset All existing calls to hubp->funcs->set_blank should be replaced with this new sequence. In wait_for_mpcc_disconnect, only blank the pipe being disconnected, and leave all other pipes unmodified. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: Fix assert being hit with GAMCOR memory shut downJacky Liao
[Why] A call to BREAK_TO_DEBUGGER is triggered when powering down memory [How] Remove the check for GAMCOR_MEM_PWR_STATE when powering off the memory Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Jacky Liao <ziyu.liao@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: fix seamless boot stream adding algorithmRaymond Yang
[Why] Seamless boot stream has hw resource assigned, already. 'add' is actually rebuild the assignment. [How] Swap seamless boot stream to pipe 0 (if needed) to ensure pipe_ctx matches Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Raymond Yang <rayyang@amd.com> Reviewed-by: Martin Leung <Martin.Leung@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: implement T12 complianceJun Lei
[why] When OS reboots, and panel is turned off, T12 may not be maintained. T12 is defined as the interval between VDDC off (occurs at shutdown) and the next VDDC on (occurs when eDP is POST-ed) [how] DC already tracks panel power off time. Add a DC interface which DM can call during shutdown. Ideally this should be as late as possible during the shutdown sequence so the extra delay is minimal. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Jun Lei <jun.lei@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: Remove unused P010 debug flagMike Hsieh
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Mike Hsieh <chun-wei.hsieh@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: doesn't reprogram AMD OUIYu-ting Shen
[Why] 1. the corrected timing to write DPCD 300h AMD signature is before link training. 2. and VBIOS will writes correctted AMD signature by after AGESA 1.0.0, so driver doesn't need to write DPCD 300h again to switch config. 3. there are some OLED panel will clean backlight level to 0 once receive DPCD 300h, so we will see flicker issue at that time. [How] read DPCD 300h signature before write it to avoid reprogram again, if AMD signature was writed corrected by VBIOS, driver will not reprogram it again. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Yu-ting Shen <Yu-ting.Shen@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: removed unnecessary check when dpp clock increasingChiawen Huang
[Why] When switching single pipe to split pipe, the bandwidth check is just for first pipe. The 2nd pipe with abnormal(or zero) dpp clock when pipe ready and unlock leads the garbage on display. [How] Removed external increasing dpp clock check, the internal function already loops all of pipes to check whether update dpp clock. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Chiawen Huang <chiawen.huang@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: New path for enabling DPGWesley Chalmers
[WHY] We want to make enabling test pattern a part of the stream update code path. This change is the first step towards that goal. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: Unblank hubp based on plane visibilityWesley Chalmers
[WHY] DCN10 uses plane visibility to determine when to unblank HUBP; there is no reason DCN20+ should not do the same. [HOW] In addition to changing the check in HWSEQ, we must change is_pipe_tree_visible so that it checks ODM pipe topologies as well as MPC. Since we're now checking both ODM and MPC topologies, the helper function names have been changed to reference "parent" and "child" instead of "top" and "bottom". Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: HUBP_IN_BLANK for DCN30Wesley Chalmers
[WHY] Shift/mask for HUBP_IN_BLANK is currently missing. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: Separate fec debug flag and monitor patchLewis Huang
[Why] Driver apply the monitor patch into global debug flag. When apply monitor patch, fec feature will always disable. [How] Separate fec debug flag and monitor patch Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Lewis Huang <Lewis.Huang@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: Initialize stack variableWesley Chalmers
[WHY] The stack variable "val" is potentially unpopulate it, so initialize it with the value 0xf (indicating an invalid mux) Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by: Martin Leung <Martin.Leung@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: NULL pointer hangQingqing Zhuo
[Why] In dc_link_dp_set_test_pattern, we assume all pipes have a stream, which can cause null pointer dereference. [How] Add a null pointer check before accessing stream. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: 3.2.117Aric Cyr
Signed-off-by: Aric Cyr <aric.cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13net: stmmac: Fixed mtu channged by cache alignedDavid Wu
Since the original mtu is not used when the mtu is updated, the mtu is aligned with cache, this will get an incorrect. For example, if you want to configure the mtu to be 1500, but mtu 1536 is configured in fact. Fixed: eaf4fac478077 ("net: stmmac: Do not accept invalid MTU values") Signed-off-by: David Wu <david.wu@rock-chips.com> Link: https://lore.kernel.org/r/20210113034109.27865-1-david.wu@rock-chips.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-13selftests/bpf: Add verifier test for PTR_TO_MEM spillGilad Reti
Add a test to check that the verifier is able to recognize spilling of PTR_TO_MEM registers, by reserving a ringbuf buffer, forcing the spill of a pointer holding the buffer address to the stack, filling it back in from the stack and writing to the memory area pointed by it. The patch was partially contributed by CyberArk Software, Inc. Signed-off-by: Gilad Reti <gilad.reti@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Acked-by: KP Singh <kpsingh@kernel.org> Link: https://lore.kernel.org/bpf/20210113053810.13518-2-gilad.reti@gmail.com
2021-01-13bpf: Support PTR_TO_MEM{,_OR_NULL} register spillingGilad Reti
Add support for pointer to mem register spilling, to allow the verifier to track pointers to valid memory addresses. Such pointers are returned for example by a successful call of the bpf_ringbuf_reserve helper. The patch was partially contributed by CyberArk Software, Inc. Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") Suggested-by: Yonghong Song <yhs@fb.com> Signed-off-by: Gilad Reti <gilad.reti@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: KP Singh <kpsingh@kernel.org> Link: https://lore.kernel.org/bpf/20210113053810.13518-1-gilad.reti@gmail.com
2021-01-13cxgb4/chtls: Fix tid stuck due to wrong update of qidAyush Sawal
TID stuck is seen when there is a race in CPL_PASS_ACCEPT_RPL/CPL_ABORT_REQ and abort is arriving before the accept reply, which sets the queue number. In this case HW ends up sending CPL_ABORT_RPL_RSS to an incorrect ingress queue. V1->V2: - Removed the unused variable len in chtls_set_quiesce_ctrl(). V2->V3: - As kfree_skb() has a check for null skb, so removed this check before calling kfree_skb() in func chtls_send_reset(). Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com> Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Link: https://lore.kernel.org/r/20210112053600.24590-1-ayush.sawal@chelsio.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-13i40e: fix potential NULL pointer dereferencingCristian Dumitrescu
Currently, the function i40e_construct_skb_zc only frees the input xdp buffer when the output skb is successfully built. On error, the function i40e_clean_rx_irq_zc does not commit anything for the current packet descriptor and simply exits the packet descriptor processing loop, with the plan to restart the processing of this descriptor on the next invocation. Therefore, on error the ring next-to-clean pointer should not advance, the xdp i.e. *bi buffer should not be freed and the current buffer info should not be invalidated by setting *bi to NULL. Therefore, the *bi should only be set to NULL when the function i40e_construct_skb_zc is successful, otherwise a NULL *bi will be dereferenced when the work for the current descriptor is eventually restarted. Fixes: 3b4f0b66c2b3 ("i40e, xsk: Migrate to new MEM_TYPE_XSK_BUFF_POOL") Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Acked-by: Björn Töpel <bjorn.topel@intel.com> Link: https://lore.kernel.org/r/20210111181138.49757-1-cristian.dumitrescu@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-13bpf: Reject too big ctx_size_in for raw_tp test runSong Liu
syzbot reported a WARNING for allocating too big memory: WARNING: CPU: 1 PID: 8484 at mm/page_alloc.c:4976 __alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5011 Modules linked in: CPU: 1 PID: 8484 Comm: syz-executor862 Not tainted 5.11.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:4976 Code: 00 00 0c 00 0f 85 a7 00 00 00 8b 3c 24 4c 89 f2 44 89 e6 c6 44 24 70 00 48 89 6c 24 58 e8 d0 d7 ff ff 49 89 c5 e9 ea fc ff ff <0f> 0b e9 b5 fd ff ff 89 74 24 14 4c 89 4c 24 08 4c 89 74 24 18 e8 RSP: 0018:ffffc900012efb10 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff9200025df66 RCX: 0000000000000000 RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000140dc0 RBP: 0000000000140dc0 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff81b1f7e1 R11: 0000000000000000 R12: 0000000000000014 R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000000 FS: 000000000190c880(0000) GS:ffff8880b9e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f08b7f316c0 CR3: 0000000012073000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267 alloc_pages include/linux/gfp.h:547 [inline] kmalloc_order+0x2e/0xb0 mm/slab_common.c:837 kmalloc_order_trace+0x14/0x120 mm/slab_common.c:853 kmalloc include/linux/slab.h:557 [inline] kzalloc include/linux/slab.h:682 [inline] bpf_prog_test_run_raw_tp+0x4b5/0x670 net/bpf/test_run.c:282 bpf_prog_test_run kernel/bpf/syscall.c:3120 [inline] __do_sys_bpf+0x1ea9/0x4f10 kernel/bpf/syscall.c:4398 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x440499 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffe1f3bfb18 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440499 RDX: 0000000000000048 RSI: 0000000020000600 RDI: 000000000000000a RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401ca0 R13: 0000000000401d30 R14: 0000000000000000 R15: 0000000000000000 This is because we didn't filter out too big ctx_size_in. Fix it by rejecting ctx_size_in that are bigger than MAX_BPF_FUNC_ARGS (12) u64 numbers. Fixes: 1b4d60ec162f ("bpf: Enable BPF_PROG_TEST_RUN for raw_tracepoint") Reported-by: syzbot+4f98876664c7337a4ae6@syzkaller.appspotmail.com Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20210112234254.1906829-1-songliubraving@fb.com
2021-01-13Merge tag 'linux-can-fixes-for-5.11-20210113' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2021-01-13 The first patch is by Oliver Hartkopp for the CAn ISO-TP protocol and fixes a kernel information leak to userspace. The last patch is by Qinglang Miao for the mcp251xfd driver and fixes a NULL pointer check to work on the correct variable. * tag 'linux-can-fixes-for-5.11-20210113' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: mcp251xfd: mcp251xfd_handle_rxif_one(): fix wrong NULL pointer check can: isotp: isotp_getname(): fix kernel information leak ==================== Link: https://lore.kernel.org/r/20210113212158.925513-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14soc: litex: Fix compile warning when device tree is not configuredStafford Horne
The test robot reported: drivers/soc/litex/litex_soc_ctrl.c:143:34: warning: unused variable 'litex_soc_ctrl_of_match' [-Wunused-const-variable] static const struct of_device_id litex_soc_ctrl_of_match[] = { ^ 1 warning generated. As per the random config device tree is not configured causing the litex_soc_ctrl_of_match match list to not be used. This would usually mean that we cannot even use this driver as it depends on device tree, but as we also have COMPILE_TEST configured we allow it. Fix the warning by surrounding the unused variable with an ifdef CONFIG_OF. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Stafford Horne <shorne@gmail.com>
2021-01-13net: stmmac: use __napi_schedule() for PREEMPT_RTSeb Laveze
Use of __napi_schedule_irqoff() is not safe with PREEMPT_RT in which hard interrupts are not disabled while running the threaded interrupt. Using __napi_schedule() works for both PREEMPT_RT and mainline Linux, just at the cost of an additional check if interrupts are disabled for mainline (since they are already disabled). Similar to the fix done for enetc commit 215602a8d212 ("enetc: use napi_schedule to be compatible with PREEMPT_RT") Signed-off-by: Seb Laveze <sebastien.laveze@nxp.com> Link: https://lore.kernel.org/r/20210112140121.1487619-1-sebastien.laveze@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-13objtool: Don't add empty symbols to the rbtreeJosh Poimboeuf
Building with the Clang assembler shows the following warning: arch/x86/kernel/ftrace_64.o: warning: objtool: missing symbol for insn at offset 0x16 The Clang assembler strips section symbols. That ends up giving objtool's find_func_containing() much more test coverage than normal. Turns out, find_func_containing() doesn't work so well for overlapping symbols: 2: 000000000000000e 0 NOTYPE LOCAL DEFAULT 2 fgraph_trace 3: 000000000000000f 0 NOTYPE LOCAL DEFAULT 2 trace 4: 0000000000000000 165 FUNC GLOBAL DEFAULT 2 __fentry__ 5: 000000000000000e 0 NOTYPE GLOBAL DEFAULT 2 ftrace_stub The zero-length NOTYPE symbols are inside __fentry__(), confusing the rbtree search for any __fentry__() offset coming after a NOTYPE. Try to avoid this problem by not adding zero-length symbols to the rbtree. They're rare and aren't needed in the rbtree anyway. One caveat, this actually might not end up being the right fix. Non-empty overlapping symbols, if they exist, could have the same problem. But that would need bigger changes, let's see if we can get away with the easy fix for now. Reported-by: Arnd Bergmann <arnd@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
2021-01-13drm/i915/gt: Replace open-coded intel_engine_stop_cs()Chris Wilson
In the legacy ringbuffer submission, we still had an open-coded version of intel_engine_stop_cs() with one additional verification step. Transfer that verification to intel_engine_stop_cs() itself, and call it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210113204709.15020-1-chris@chris-wilson.co.uk
2021-01-13drm/i915/selftests: Bump the scheduling error threshold for fast heartbeatsChris Wilson
Since we are system_highpri_wq, we expected the heartbeat to be scheduled promptly. However, we see delays of over 10ms upsetting our assertions. Accept this as inevitable and bump the minimum error threshold to 20ms (from 6 jiffies). <6> [616.784749] rcs0: Heartbeat delay: 3570us [2802, 9188] <6> [616.807790] bcs0: Heartbeat delay: 2111us [745, 4372] <6> [616.853776] vcs0: Heartbeat delay: 6485us [2424, 11637] <3> [616.859296] vcs0: Heartbeat delay was 6485us, expected less than 6000us <3> [616.860901] i915/intel_heartbeat_live_selftests: live_heartbeat_fast failed with error -22 v2: More context from CI. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210113163115.5740-2-chris@chris-wilson.co.uk
2021-01-13drm/i915/selftests: Force a failed engine resetChris Wilson
Inject a fault into the engine reset and check that the outstanding requests are completed despite the failed reset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210113205049.22565-1-chris@chris-wilson.co.uk
2021-01-13ALSA: usb-audio: Always apply the hw constraints for implicit fb syncTakashi Iwai
Since the commit 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb sync"), we apply the hw constraints for the implicit feedback sync to make the secondary open aligned with the already opened stream setup. This change assumed that the secondary open is performed after the first stream has been already set up, and adds the hw constraints to sync with the first stream's parameters only when the EP setup for the first stream was confirmed at the open time. However, most of applications handling the full-duplex operations do open both playback and capture streams at first, then set up both streams. This results in skipping the additional hw constraints since the counter-part stream hasn't been set up yet at the open of the second stream, and it eventually leads to "incompatible EP" error in the end. This patch corrects the behavior by always applying the hw constraints for the implicit fb sync. The hw constraint rules are defined so that they check the sync EP dynamically at each invocation, instead. This covers the concurrent stream setups better and lets the hw refine calls resolving to the right configuration. Also this patch corrects a minor error that has existed in the debug print that isn't built as default. Fixes: 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb sync") Link: https://lore.kernel.org/r/20210111081611.12790-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-01-13can: mcp251xfd: mcp251xfd_handle_rxif_one(): fix wrong NULL pointer checkQinglang Miao
If alloc_canfd_skb() returns NULL, 'cfg' is an uninitialized variable, so we should check 'skb' rather than 'cfd' after calling alloc_canfd_skb(priv->ndev, &cfd). Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210113073100.79552-1-miaoqinglang@huawei.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-13can: isotp: isotp_getname(): fix kernel information leakOliver Hartkopp
Initialize the sockaddr_can structure to prevent a data leak to user space. Suggested-by: Cong Wang <xiyou.wangcong@gmail.com> Reported-by: syzbot+057884e2f453e8afebc8@syzkaller.appspotmail.com Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/r/20210112091643.11789-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-13Merge tag 'sound-5.11-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Here are some piled fixes, hopefully the last big one for 5.11. All changes are device-specific small fixes, and majority of commits are for ASoC while USB-audio got a bit large changes for addressing the regression for devices with quirks" * tag 'sound-5.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (31 commits) ALSA: hda/hdmi - enable runtime pm for CI AMD display audio ALSA: firewire-tascam: Fix integer overflow in midi_port_work() ALSA: fireface: Fix integer overflow in transmit_midi_msg() ALSA: hda/tegra: fix tegra-hda on tegra30 soc clk: tegra30: Add hda clock default rates to clock driver ALSA: doc: Fix reference to mixart.rst ALSA: usb-audio: Fix implicit feedback sync setup for Pioneer devices ALSA: usb-audio: Annotate the endpoint index in audioformat ALSA: usb-audio: Avoid unnecessary interface re-setup ALSA: usb-audio: Choose audioformat of a counter-part substream ALSA: usb-audio: Fix the missing endpoints creations for quirks ALSA: hda/realtek: fix right sounds and mute/micmute LEDs for HP machines ASoC: AMD Renoir - add DMI entry for Lenovo ThinkPad X395 ASoC: amd: Replacing MSI with Legacy IRQ model ASoC: AMD Renoir - add DMI entry for Lenovo ThinkPad E14 Gen 2 ASoC: meson: axg-tdm-interface: fix loopback ASoC: meson: axg-tdmin: fix axg skew offset ASoC: max98373: don't access volatile registers in bias level off ASoC: rt711: mutex between calibration and power state changes ASoC: Intel: haswell: Add missing pm_ops ...
2021-01-13cifs: style: replace one-element array with flexible-arrayYANG LI
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use "flexible array members"[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/ deprecated.html#zero-length-and-one-element-arrays Signed-off-by: YANG LI <abaci-bugfix@linux.alibaba.com> Reported-by: Abaci <abaci@linux.alibaba.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-01-13cifs: connect: style: Simplify bool comparisonYANG LI
Fix the following coccicheck warning: ./fs/cifs/connect.c:3740:6-21: WARNING: Comparison of 0/1 to bool variable Signed-off-by: YANG LI <abaci-bugfix@linux.alibaba.com> Reported-by: Abaci Robot<abaci@linux.alibaba.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-01-13fs: cifs: remove unneeded variable in smb3_fs_context_dupMenglong Dong
'rc' in smb3_fs_context_dup is not used and can be removed. Signed-off-by: Menglong Dong <dong.menglong@zte.com.cn> Reviewed-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-01-13cifs: fix interrupted close commandsPaulo Alcantara
Retry close command if it gets interrupted to not leak open handles on the server. Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Reported-by: Duncan Findlay <duncf@duncf.ca> Suggested-by: Pavel Shilovsky <pshilov@microsoft.com> Fixes: 6988a619f5b7 ("cifs: allow syscalls to be restarted in __smb_send_rqst()") Cc: stable@vger.kernel.org Reviewd-by: Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-01-13cifs: check pointer before freeingTom Rix
clang static analysis reports this problem dfs_cache.c:591:2: warning: Argument to kfree() is a constant address (18446744073709551614), which is not memory allocated by malloc() kfree(vi); ^~~~~~~~~ In dfs_cache_del_vol() the volume info pointer 'vi' being freed is the return of a call to find_vol(). The large constant address is find_vol() returning an error. Add an error check to dfs_cache_del_vol() similar to the one done in dfs_cache_update_vol(). Fixes: 54be1f6c1c37 ("cifs: Add DFS cache routines") Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> CC: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Steve French <stfrench@microsoft.com>
2021-01-13rxrpc: Call state should be read with READ_ONCE() under some circumstancesBaptiste Lepers
The call state may be changed at any time by the data-ready routine in response to received packets, so if the call state is to be read and acted upon several times in a function, READ_ONCE() must be used unless the call state lock is held. As it happens, we used READ_ONCE() to read the state a few lines above the unmarked read in rxrpc_input_data(), so use that value rather than re-reading it. Fixes: a158bdd3247b ("rxrpc: Fix call timeouts") Signed-off-by: Baptiste Lepers <baptiste.lepers@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/r/161046715522.2450566.488819910256264150.stgit@warthog.procyon.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-13rxrpc: Fix handling of an unsupported token type in rxrpc_read()David Howells
Clang static analysis reports the following: net/rxrpc/key.c:657:11: warning: Assigned value is garbage or undefined toksize = toksizes[tok++]; ^ ~~~~~~~~~~~~~~~ rxrpc_read() contains two consecutive loops. The first loop calculates the token sizes and stores the results in toksizes[] and the second one uses the array. When there is an error in identifying the token in the first loop, the token is skipped, no change is made to the toksizes[] array. When the same error happens in the second loop, the token is not skipped. This will cause the toksizes[] array to be out of step and will overrun past the calculated sizes. Fix this by making both loops log a message and return an error in this case. This should only happen if a new token type is incompletely implemented, so it should normally be impossible to trigger this. Fixes: 9a059cd5ca7d ("rxrpc: Downgrade the BUG() for unsupported token type in rxrpc_read()") Reported-by: Tom Rix <trix@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/161046503122.2445787.16714129930607546635.stgit@warthog.procyon.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-13Merge v5.11-rc3Mark Brown
generated by cgit (git 2.34.1) at 2025-09-19 05:12:25 +0000