aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-07-23drm/amdgpu: add psp command to get num xgmi links between direct peersJonathan Kim3-1/+37
The TA can now be invoked to provide the number of xgmi links connecting a direct source and destination peer. Non-direct peers will report zero links. Signed-off-by: Jonathan Kim <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amdgpu: Fix documentaion for amdgpu_bo_add_to_shadow_listAnson Jacob1-1/+1
make htmldocs complaints about parameter for amdgpu_bo_add_to_shadow_list ./drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:739: warning: Excess function parameter 'bo' description in 'amdgpu_bo_add_to_shadow_list' ./drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:739: warning: Function parameter or member 'vmbo' not described in 'amdgpu_bo_add_to_shadow_list' ./drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:739: warning: Excess function parameter 'bo' description in 'amdgpu_bo_add_to_shadow_list' Signed-off-by: Anson Jacob <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/pm: Support board calibration on aldebaranLijo Lazar3-12/+40
Add support for board power calibration on Aldebaran. Board calibration is done after DC offset calibration. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Kevin Wang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: change zstate allow msg conditionEric Yang3-25/+45
[Why] PMFW message which previously thought to only control Z9 controls both Z9 and Z10. Also HW design team requested that Z9 must only be supported on eDP due to content protection interop. [How] Change zstate support condition to match updated policy Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Eric Yang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: 3.2.145Aric Cyr1-1/+1
DC version 3.2.145 brings improvements in multiple areas. In summary, we highlight: - Code improvements for passive - Cursor manipulation enhancements - Expand debug in some areas - Fix problems in DML - Other minor code refactors Reviewed-by: Anson Jacob <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Aric Cyr <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: [FW Promotion] Release 0.0.75Anthony Koo1-23/+13
- Add reserved bits for future feature development - Fix issue with mismatch with type const - Replaced problematic code with old memcpy and casted problematic pointers to unsigned char pointers Reviewed-by: Aric Cyr <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Anthony Koo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Refine condition for cursor visibilityKrunoslav Kovac2-3/+23
[why] There's a special case where upper plane is not the main plane. If it owns the cursor, it will be invisible in the majority of the screen. [How] The condition for disabling cursor is changed: - check if upper viewport completely covers current. This was the previous change that doesn't handle all scenarios with pipe splitting. - if not, show the cursor only if it's not scaled or no upper pipe. Reviewed-by: Aric Cyr <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Krunoslav Kovac <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Populate dtbclk entries for dcn3.02/3.03Bindu Ramamurthy2-2/+10
[Why] Populate dtbclk values from bwparams for dcn302, dcn303. [How] dtbclk values are fetched from bandwidthparams for all DPM levels and for DPM levels where smu returns 0, previous level values are reported. Reviewed-by: Roman Li <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Bindu Ramamurthy <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: add workaround for riommu invalidation request hangEric Yang3-0/+29
[Why] When an riommu invalidation request come at the same time as a pipe is disabled there can be a case where DCN cannot ACK the request if only one VMID is setup in the inuse list. [How] Setup a second unused VMID will work around the issue. Reviewed-by: Jun Lei <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Eric Yang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Line Buffer changesNevenko Stupar4-19/+10
DCN 3x increased Line buffer size for DCHUB latency hiding, from 4 lines of 4K resolution lines to 5 lines of 4K resolution lines. All Line Buffer can be used as extended memory for P State change latency hiding. The maximum number of lines is increased to 32 lines. Finally, LB_MEMORY_CONFIG_1 (LB memory piece 1) and LB_MEMORY _CONFIG_2 (LB memory piece 2) are not affected, no change in size, only 3 pieces is affected, i.e., when all 3 pieces are used in both LB_MEMORY_CONFIG_0 and LB_MEMORY_CONFIG_3 (for 4:2:0) modes. Reviewed-by: Jun Lei <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Nevenko Stupar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Remove MALL function from DCN3.1Mikita Lipski1-1/+0
[why] DCN31 doesn't have MALL in DMUB so to avoid sending unknown commands to DMUB just remove the function pointer. [how] Remove apply_idle_power_optimizations from function pointers structure for DCN31 Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Mikita Lipski <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: DCN2X Prefer ODM over bottom pipe to find second pipesunglee1-4/+4
[WHY] When finding a second pipe for pipe split, currently will look for bottom pipe in context first to decide the second pipe. This causes issues in 2 plane to 1 plane transitions like fullscreen video where bottom pipe no longer exists in the new configuration. [HOW] If previous context had an ODM pipe, use that to find the secondary pipe first before looking at bottom pipe. Reviewed-by: Dmytro Laktyushkin <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: sunglee <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Only set default brightness for OLEDCamille Cho1-3/+1
[Why] We used to unconditionally set backlight path as AUX for panels capable of backlight adjustment via DPCD in set default brightness. [How] This should be limited to OLED panel only since we control backlight via PWM path for SDR mode in LCD HDR panel. Reviewed-by: Krunoslav Kovac <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Camille Cho <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Update bounding box for DCN3.1Nicholas Kazlauskas1-0/+1
[Why & How] We're missing a default value for dram_channel_width_bytes in the DCN3.1 SOC bounding box and we don't currently have the interface in place to query the actual value from VBIOS. Put in a hardcoded default until we have the interface in place. Reviewed-by: Eric Yang <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Query VCO frequency from register for DCN3.1Nicholas Kazlauskas2-55/+42
[Why] Hardcoding the VCO frequency isn't correct since we don't own or control the value. In the case where the hardcode is also missing we can't lightup display. [How] Query from the CLK register instead. Update the DFS frequency to be able to compute the VCO frequency. Reviewed-by: Eric Yang <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Populate socclk entries for dcn3.02/3.03Bindu Ramamurthy3-4/+14
[Why] Initialize socclk entries in bandwidth params for dcn302, dcn303. [How] Fetch the sockclk values from smu for the DPM levels and for the DPM levels where smu returns 0, previous level values are reported. Reviewed-by: Roman Li <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Bindu Ramamurthy <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Fix max vstartup calculation for modes with bordersNicholas Kazlauskas1-2/+4
[Why] Vertical and horizontal borders in timings are treated as increasing the active area - vblank and hblank actually shrink. Our input into DML does not include these borders so it incorrectly assumes it has more time than available for vstartup and tmdl calculations for some modes with borders. An example of such a timing would be 640x480@72Hz: h_total: 832 h_border_left: 8 h_addressable: 640 h_border_right: 8 h_front_porch: 16 h_sync_width: 40 v_total: 520 v_border_top: 8 v_addressable: 480 v_border_bottom: 8 v_front_porch: 1 v_sync_width: 3 pix_clk_100hz: 315000 [How] Include borders as part of destination vactive/hactive. This change DCN20+ so it has wide impact, but the destination vactive and hactive are only really used for vstartup calculation anyway. Most modes do not have vertical or horizontal borders. Reviewed-by: Dmytro Laktyushkin <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Enable eDP ILR on DCN2.1Michael Strauss1-1/+2
[WHY] Enable feature for 21.40 Reviewed-by: Sung Lee <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Michael Strauss <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: 3.2.144Aric Cyr1-1/+1
Reviewed-by: Shahin Khayyer <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Aric Cyr <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Fix comparison error in dcn21 DMLVictor Lu1-1/+1
[why] A comparison error made it possible to not iterate through all the specified prefetch modes. [how] Correct "<" to "<=" Reviewed-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Yongqiang Sun <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Victor Lu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Fixed hardware power down bypass during headless bootJake Wang3-30/+27
[Why] During headless boot, DIG may be on which causes HW/SW discrepancies. To avoid this we power down hardware on boot if DIG is turned on. With introduction of multiple eDP, hardware power down is being bypassed under certain conditions. [How] Fixed hardware power down bypass, and ensured hardware will power down if DIG is on and seamless boot is not enabled. Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Jake Wang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Add copyright notice to new filesWesley Chalmers2-0/+50
Reviewed-by: Shahin Khayyer <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Wesley Chalmers <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: Reduce delay when sink device not able to ACK 00340h writeZhan Liu3-3/+18
[Why] Theoretically, per DP 1.4a spec, sink device needs to AUX_ACK 00340h write. However, due to hardware limitation, some sink devices have no 00340h dpcd address at all. This results in sink side fails to reply ACK, and consequently cause source side keep retrying DPCD write on DPCD 00340h. This results in significant delay when DPCD 00340h write is triggered (e.g. at S3 resume). [How] Check whether sink device could ACK on DPCD 00340h write on boot. If sink device fails to ACK, then remember that, so we won't write to DPCD 00340h later on. There will be a drm.debug KMS level message to inform user once a 00340h DPCD write is skipped on purpose. Reviewed-by: Nikola Cornij <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Zhan Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23drm/amd/display: add debug print for DCC validation failureAurabindo Pillai1-3/+3
[Why&How] Print a debug message when dcc validation fails in the display driver. Most DCC enablement related errors are from userspace. Adding a debug print in case of a failure from display driver will aid quicker triage. Reviewed-by: Harry Wentland <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Aurabindo Pillai <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-23tracepoints: Update static_call before tp_funcs when adding a tracepointSteven Rostedt (VMware)1-1/+1
Because of the significant overhead that retpolines pose on indirect calls, the tracepoint code was updated to use the new "static_calls" that can modify the running code to directly call a function instead of using an indirect caller, and this function can be changed at runtime. In the tracepoint code that calls all the registered callbacks that are attached to a tracepoint, the following is done: it_func_ptr = rcu_dereference_raw((&__tracepoint_##name)->funcs); if (it_func_ptr) { __data = (it_func_ptr)->data; static_call(tp_func_##name)(__data, args); } If there's just a single callback, the static_call is updated to just call that callback directly. Once another handler is added, then the static caller is updated to call the iterator, that simply loops over all the funcs in the array and calls each of the callbacks like the old method using indirect calling. The issue was discovered with a race between updating the funcs array and updating the static_call. The funcs array was updated first and then the static_call was updated. This is not an issue as long as the first element in the old array is the same as the first element in the new array. But that assumption is incorrect, because callbacks also have a priority field, and if there's a callback added that has a higher priority than the callback on the old array, then it will become the first callback in the new array. This means that it is possible to call the old callback with the new callback data element, which can cause a kernel panic. static_call = callback1() funcs[] = {callback1,data1}; callback2 has higher priority than callback1 CPU 1 CPU 2 ----- ----- new_funcs = {callback2,data2}, {callback1,data1} rcu_assign_pointer(tp->funcs, new_funcs); /* * Now tp->funcs has the new array * but the static_call still calls callback1 */ it_func_ptr = tp->funcs [ new_funcs ] data = it_func_ptr->data [ data2 ] static_call(callback1, data); /* Now callback1 is called with * callback2's data */ [ KERNEL PANIC ] update_static_call(iterator); To prevent this from happening, always switch the static_call to the iterator before assigning the tp->funcs to the new array. The iterator will always properly match the callback with its data. To trigger this bug: In one terminal: while :; do hackbench 50; done In another terminal echo 1 > /sys/kernel/tracing/events/sched/sched_waking/enable while :; do echo 1 > /sys/kernel/tracing/set_event_pid; sleep 0.5 echo 0 > /sys/kernel/tracing/set_event_pid; sleep 0.5 done And it doesn't take long to crash. This is because the set_event_pid adds a callback to the sched_waking tracepoint with a high priority, which will be called before the sched_waking trace event callback is called. Note, the removal to a single callback updates the array first, before changing the static_call to single callback, which is the proper order as the first element in the array is the same as what the static_call is being changed to. Link: https://lore.kernel.org/io-uring/[email protected]/ Cc: [email protected] Fixes: d25e37d89dd2f ("tracepoint: Optimize using static_call()") Reported-by: Stefan Metzmacher <[email protected]> tested-by: Stefan Metzmacher <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-07-23ftrace: Remove redundant initialization of variable retColin Ian King1-1/+1
The variable ret is being initialized with a value that is never read, it is being updated later on. The assignment is redundant and can be removed. Link: https://lkml.kernel.org/r/[email protected] Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-07-23ftrace: Avoid synchronize_rcu_tasks_rude() call when not necessaryNicolas Saenz Julienne1-1/+2
synchronize_rcu_tasks_rude() triggers IPIs and forces rescheduling on all CPUs. It is a costly operation and, when targeting nohz_full CPUs, very disrupting (hence the name). So avoid calling it when 'old_hash' doesn't need to be freed. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-07-23tracing: Clean up alloc_synth_event()Steven Rostedt (VMware)1-5/+3
alloc_synth_event() currently has the following code to initialize the event fields and dynamic_fields: for (i = 0, j = 0; i < n_fields; i++) { event->fields[i] = fields[i]; if (fields[i]->is_dynamic) { event->dynamic_fields[j] = fields[i]; event->dynamic_fields[j]->field_pos = i; event->dynamic_fields[j++] = fields[i]; event->n_dynamic_fields++; } } 1) It would make more sense to have all fields keep track of their field_pos. 2) event->dynmaic_fields[j] is assigned twice for no reason. 3) We can move updating event->n_dynamic_fields outside the loop, and just assign it to j. This combination makes the code much cleaner. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-07-23tracing/histogram: Rename "cpu" to "common_cpu"Steven Rostedt (VMware)3-7/+21
Currently the histogram logic allows the user to write "cpu" in as an event field, and it will record the CPU that the event happened on. The problem with this is that there's a lot of events that have "cpu" as a real field, and using "cpu" as the CPU it ran on, makes it impossible to run histograms on the "cpu" field of events. For example, if I want to have a histogram on the count of the workqueue_queue_work event on its cpu field, running: ># echo 'hist:keys=cpu' > events/workqueue/workqueue_queue_work/trigger Gives a misleading and wrong result. Change the command to "common_cpu" as no event should have "common_*" fields as that's a reserved name for fields used by all events. And this makes sense here as common_cpu would be a field used by all events. Now we can even do: ># echo 'hist:keys=common_cpu,cpu if cpu < 100' > events/workqueue/workqueue_queue_work/trigger ># cat events/workqueue/workqueue_queue_work/hist # event histogram # # trigger info: hist:keys=common_cpu,cpu:vals=hitcount:sort=hitcount:size=2048 if cpu < 100 [active] # { common_cpu: 0, cpu: 2 } hitcount: 1 { common_cpu: 0, cpu: 4 } hitcount: 1 { common_cpu: 7, cpu: 7 } hitcount: 1 { common_cpu: 0, cpu: 7 } hitcount: 1 { common_cpu: 0, cpu: 1 } hitcount: 1 { common_cpu: 0, cpu: 6 } hitcount: 2 { common_cpu: 0, cpu: 5 } hitcount: 2 { common_cpu: 1, cpu: 1 } hitcount: 4 { common_cpu: 6, cpu: 6 } hitcount: 4 { common_cpu: 5, cpu: 5 } hitcount: 14 { common_cpu: 4, cpu: 4 } hitcount: 26 { common_cpu: 0, cpu: 0 } hitcount: 39 { common_cpu: 2, cpu: 2 } hitcount: 184 Now for backward compatibility, I added a trick. If "cpu" is used, and the field is not found, it will fall back to "common_cpu" and work as it did before. This way, it will still work for old programs that use "cpu" to get the actual CPU, but if the event has a "cpu" as a field, it will get that event's "cpu" field, which is probably what it wants anyway. I updated the tracefs/README to include documentation about both the common_timestamp and the common_cpu. This way, if that text is present in the README, then an application can know that common_cpu is supported over just plain "cpu". Link: https://lkml.kernel.org/r/[email protected] Cc: Namhyung Kim <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Fixes: 8b7622bf94a44 ("tracing: Add cpu field for hist triggers") Reviewed-by: Tom Zanussi <[email protected]> Reviewed-by: Masami Hiramatsu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-07-23tracing: Synthetic event field_pos is an index not a booleanSteven Rostedt (VMware)1-1/+1
Performing the following: ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\ > events/sched/sched_switch/trigger ># echo 1 > events/synthetic/enable Crashed the kernel: BUG: kernel NULL pointer dereference, address: 000000000000001b #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ #104 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strlen+0x0/0x20 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 9 f8 c3 31 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018 FS: 0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0 Call Trace: trace_event_raw_event_synth+0x90/0x1d0 action_trace+0x5b/0x70 event_hist_trigger+0x4bd/0x4e0 ? cpumask_next_and+0x20/0x30 ? update_sd_lb_stats.constprop.0+0xf6/0x840 ? __lock_acquire.constprop.0+0x125/0x550 ? find_held_lock+0x32/0x90 ? sched_clock_cpu+0xe/0xd0 ? lock_release+0x155/0x440 ? update_load_avg+0x8c/0x6f0 ? enqueue_entity+0x18a/0x920 ? __rb_reserve_next+0xe5/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 event_triggers_call+0x52/0xe0 trace_event_buffer_commit+0x1ae/0x240 trace_event_raw_event_sched_switch+0x114/0x170 __traceiter_sched_switch+0x39/0x50 __schedule+0x431/0xb00 schedule_idle+0x28/0x40 do_idle+0x198/0x2e0 cpu_startup_entry+0x19/0x20 secondary_startup_64_no_verify+0xc2/0xcb The reason is that the dynamic events array keeps track of the field position of the fields array, via the field_pos variable in the synth_field structure. Unfortunately, that field is a boolean for some reason, which means any field_pos greater than 1 will be a bug (in this case it was 2). Link: https://lkml.kernel.org/r/[email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Fixes: bd82631d7ccdc ("tracing: Add support for dynamic strings to synthetic events") Reviewed-by: Tom Zanussi <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-07-23Documentation: gpu: Mention the requirements for new propertiesMaxime Ripard1-0/+29
New KMS properties come with a bunch of requirements to avoid each driver from running their own, inconsistent, set of properties, eventually leading to issues like property conflicts, inconsistencies between drivers and semantics, etc. Let's document what we expect. Acked-by: Dave Airlie <[email protected]> Reviewed-by: Pekka Paalanen <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-23drm/panfrost: devfreq: Don't display error for EPROBE_DEFERChris Morgan1-1/+2
Set a condition for the message of "Couldn't set OPP regulators" to not display if the error code is EPROBE_DEFER. Note that I used an if statement to capture the condition instead of the dev_err_probe function because I didn't want to change the DRM_DEV_ERROR usage. Signed-off-by: Chris Morgan <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Steven Price <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-23KVM: PPC: Book3S HV Nested: Sanitise H_ENTER_NESTED TM stateNicholas Piggin1-0/+20
The H_ENTER_NESTED hypercall is handled by the L0, and it is a request by the L1 to switch the context of the vCPU over to that of its L2 guest, and return with an interrupt indication. The L1 is responsible for switching some registers to guest context, and the L0 switches others (including all the hypervisor privileged state). If the L2 MSR has TM active, then the L1 is responsible for recheckpointing the L2 TM state. Then the L1 exits to L0 via the H_ENTER_NESTED hcall, and the L0 saves the TM state as part of the exit, and then it recheckpoints the TM state as part of the nested entry and finally HRFIDs into the L2 with TM active MSR. Not efficient, but about the simplest approach for something that's horrendously complicated. Problems arise if the L1 exits to the L0 with a TM state which does not match the L2 TM state being requested. For example if the L1 is transactional but the L2 MSR is non-transactional, or vice versa. The L0's HRFID can take a TM Bad Thing interrupt and crash. Fix this by disallowing H_ENTER_NESTED in TM[T] state entirely, and then ensuring that if the L1 is suspended then the L2 must have TM active, and if the L1 is not suspended then the L2 must not have TM active. Fixes: 360cae313702 ("KVM: PPC: Book3S HV: Nested guest entry via hypercall") Cc: [email protected] # v4.20+ Reported-by: Alexey Kardashevskiy <[email protected]> Acked-by: Michael Neuling <[email protected]> Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2021-07-23KVM: PPC: Book3S: Fix H_RTAS rets buffer overflowNicholas Piggin1-3/+22
The kvmppc_rtas_hcall() sets the host rtas_args.rets pointer based on the rtas_args.nargs that was provided by the guest. That guest nargs value is not range checked, so the guest can cause the host rets pointer to be pointed outside the args array. The individual rtas function handlers check the nargs and nrets values to ensure they are correct, but if they are not, the handlers store a -3 (0xfffffffd) failure indication in rets[0] which corrupts host memory. Fix this by testing up front whether the guest supplied nargs and nret would exceed the array size, and fail the hcall directly without storing a failure indication to rets[0]. Also expand on a comment about why we kill the guest and try not to return errors directly if we have a valid rets[0] pointer. Fixes: 8e591cb72047 ("KVM: PPC: Book3S: Add infrastructure to implement kernel-side RTAS calls") Cc: [email protected] # v3.10+ Reported-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2021-07-22riscv: Make sure the kernel mapping does not overlap with IS_ERR_VALUEAlexandre Ghiti1-2/+16
The check that is done in setup_bootmem currently only works for 32-bit kernel since the kernel mapping has been moved outside of the linear mapping for 64-bit kernel. So make sure that for 64-bit kernel, the kernel mapping does not overlap with the last 4K of the addressable memory. Signed-off-by: Alexandre Ghiti <[email protected]> Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear mapping") Signed-off-by: Palmer Dabbelt <[email protected]>
2021-07-22riscv: Make sure the linear mapping does not use the kernel mappingAlexandre Ghiti1-0/+2
For 64-bit kernel, the end of the address space is occupied by the kernel mapping and currently, the functions to populate the kernel page tables (i.e. create_p*d_mapping) do not override existing mapping so we must make sure the linear mapping does not map memory in the kernel mapping by clipping the memory above the memory limit. Signed-off-by: Alexandre Ghiti <[email protected]> Fixes: c9811e379b21 ("riscv: Add mem kernel parameter support") Signed-off-by: Palmer Dabbelt <[email protected]>
2021-07-22Merge tag 'drm-fixes-2021-07-23' of git://anongit.freedesktop.org/drm/drmLinus Torvalds44-788/+457
Pull drm fixes from Dave Airlie: "Regular fixes - a bunch of amdgpu fixes are the main thing mostly for the new gpus. There is also some i915 reverts for older changes that were having some unwanted side effects. One nouveau fix for a report regressions, and otherwise just some misc fixes. core: - fix for non-drm ioctls on drm fd panel: - avoid double free ttm: - refcounting fix - NULL checks amdgpu: - Yellow Carp updates - Add some Yellow Carp DIDs - Beige Goby updates - CIK 10bit 4K regression fix - GFX10 golden settings updates - eDP panel regression fix - Misc display fixes - Aldebaran fix - fix COW checks nouveau: - init BO GEM fields i915: - revert async command parsing - revert fence error propogation - GVT fix for shadow ppgtt vc4: - fix interrupt handling" * tag 'drm-fixes-2021-07-23' of git://anongit.freedesktop.org/drm/drm: (34 commits) drm/panel: raspberrypi-touchscreen: Prevent double-free drm/amdgpu - Corrected the video codecs array name for yellow carp drm/amd/display: Fix ASSR regression on embedded panels drm/amdgpu: add yellow carp pci id (v2) drm/amdgpu: update yellow carp external rev_id handling drm/amd/pm: Support board calibration on aldebaran drm/amd/display: change zstate allow msg condition drm/amd/display: Populate dtbclk entries for dcn3.02/3.03 drm/amd/display: Line Buffer changes drm/amd/display: Remove MALL function from DCN3.1 drm/amd/display: Only set default brightness for OLED drm/amd/display: Update bounding box for DCN3.1 drm/amd/display: Query VCO frequency from register for DCN3.1 drm/amd/display: Populate socclk entries for dcn3.02/3.03 drm/amd/display: Fix max vstartup calculation for modes with borders drm/amd/display: implement workaround for riommu related hang drm/amd/display: Fix comparison error in dcn21 DML drm/i915: Correct the docs for intel_engine_cmd_parser drm/ttm: add missing NULL checks drm/ttm: Force re-init if ttm_global_init() fails ...
2021-07-22riscv: Fix memory_limit for 64-bit kernelAlexandre Ghiti1-2/+9
As described in Documentation/riscv/vm-layout.rst, the end of the virtual address space for 64-bit kernel is occupied by the modules/BPF/ kernel mappings so this actually reduces the amount of memory we are able to map and then use in the linear mapping. So make sure this limit is correctly set. Signed-off-by: Alexandre Ghiti <[email protected]> Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear mapping") Signed-off-by: Palmer Dabbelt <[email protected]>
2021-07-22cifs: fix fallocate when trying to allocate a hole.Ronnie Sahlberg1-5/+18
Remove the conditional checking for out_data_len and skipping the fallocate if it is 0. This is wrong will actually change any legitimate the fallocate where the entire region is unallocated into a no-op. Additionally, before allocating the range, if FALLOC_FL_KEEP_SIZE is set then we need to clamp the length of the fallocate region as to not extend the size of the file. Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation") Signed-off-by: Ronnie Sahlberg <[email protected]> Signed-off-by: Steve French <[email protected]>
2021-07-22Merge tag 'fallthrough-fixes-clang-5.14-rc3' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux Pull fallthrough fix from Gustavo Silva: "Fix a fall-through warning when building with -Wimplicit-fallthrough on PowerPC" * tag 'fallthrough-fixes-clang-5.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux: powerpc/pasemi: Fix fall-through warning for Clang
2021-07-23Merge tag 'drm-misc-next-2021-07-22' of ↵Dave Airlie62-641/+1571
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.15-rc1: UAPI Changes: - Remove sysfs stats for dma-buf attachments, as it causes a performance regression. Previous merge is not in a rc kernel yet, so no userspace regression possible. Cross-subsystem Changes: - Sanitize user input in kyro's viewport ioctl. - Use refcount_t in fb_info->count - Assorted fixes to dma-buf. - Extend x86 efifb handling to all archs. - Fix neofb divide by 0. - Document corpro,gm7123 bridge dt bindings. Core Changes: - Slightly rework drm master handling. - Cleanup vgaarb handling. - Assorted fixes. Driver Changes: - Add support for ws2401 panel. - Assorted fixes to stm, ast, bochs. - Demidlayer ingenic irq. Signed-off-by: Dave Airlie <[email protected]> From: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-23Merge tag 'drm-misc-fixes-2021-07-22' of ↵Dave Airlie9-17/+60
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Short summary of fixes pull: * Return -ENOTTY for non-DRM ioctls * amdgpu: Fix COW checks * nouveau: init BO GME fields * panel: Avoid double free * ttm: Fix refcounting in ttm_global_init(); NULL checks * vc4: Fix interrupt handling Signed-off-by: Dave Airlie <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-23Merge tag 'drm-intel-fixes-2021-07-22' of ↵Dave Airlie6-288/+109
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Couple reverts from Jason getting rid of asynchronous command parsing and fence error propagation and a GVT fix of shadow ppgtt invalidation with proper D3 state tracking from Colin. Signed-off-by: Dave Airlie <[email protected]> From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-22io_uring: fix early fdput() of fileJens Axboe1-2/+4
A previous commit shuffled some code around, and inadvertently used struct file after fdput() had been called on it. As we can't touch the file post fdput() dropping our reference, move the fdput() to after that has been done. Cc: Pavel Begunkov <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/io-uring/[email protected]/ Fixes: f2a48dd09b8e ("io_uring: refactor io_sq_offload_create()") Reported-by: Al Viro <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-07-22Merge tag 'array-bounds-fixes-5.14-rc3' of ↵Linus Torvalds2-7/+9
git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux Pull array bounds warning fix from Gustavo Silva: "Fix a couple of out-of-bounds warnings in the media subsystem. This is part of the ongoing efforts to globally enable -Warray-bounds" * tag 'array-bounds-fixes-5.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux: media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()
2021-07-22Merge tag 'nvme-5.14-2021-07-22' of git://git.infradead.org/nvme into block-5.14Jens Axboe5-18/+31
Pull NVMe fixes from Christoph: "nvme fixes for Linux 5.14: - tracing fix (Keith Busch) - fix multipath head refcounting (Hannes Reinecke) - Write Zeroes vs PI fix (me) - drop a bogus WARN_ON (Zhihao Cheng)" * tag 'nvme-5.14-2021-07-22' of git://git.infradead.org/nvme: nvme: set the PRACT bit when using Write Zeroes with T10 PI nvme: fix nvme_setup_command metadata trace event nvme: fix refcounting imbalance when all paths are down nvme-pci: don't WARN_ON in nvme_reset_work if ctrl.state is not RESETTING
2021-07-22CIFS: Clarify SMB1 code for POSIX delete fileSteve French1-2/+5
Coverity also complains about the way we calculate the offset (starting from the address of a 4 byte array within the header structure rather than from the beginning of the struct plus 4 bytes) for SMB1 CIFSPOSIXDelFile. This changeset doesn't change the address but makes it slightly clearer. Addresses-Coverity: 711519 ("Out of bounds write") Signed-off-by: Steve French <[email protected]>
2021-07-22Merge tag 'usb-serial-5.14-rc3' of ↵Greg Kroah-Hartman2-2/+6
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for 5.14-rc3 Here are some new device ids and a device-id comment fix. All have been in linux-next with no reported issues. * tag 'usb-serial-5.14-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: cp210x: add ID for CEL EM3588 USB ZigBee stick USB: serial: cp210x: fix comments for GE CS1000 USB: serial: option: add support for u-blox LARA-R6 family
2021-07-22CIFS: Clarify SMB1 code for POSIX CreateSteve French1-1/+2
Coverity also complains about the way we calculate the offset (starting from the address of a 4 byte array within the header structure rather than from the beginning of the struct plus 4 bytes) for SMB1 CIFSPOSIXCreate. This changeset doesn't change the address but makes it slightly clearer. Addresses-Coverity: 711518 ("Out of bounds write") Signed-off-by: Steve French <[email protected]>
2021-07-22Merge tag 'arm64-fixes' of ↵Linus Torvalds5-59/+40
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "A pair of arm64 fixes for -rc3. The straightforward one is a fix to our firmware calling stub, which accidentally started corrupting the link register on machines with SVE. Since these machines don't really exist yet, it wasn't spotted in -next. The other fix is a revert-and-a-bit of a patch originally intended to allow PTE-level huge mappings for the VMAP area on 32-bit PPC 8xx. A side-effect of this change was that our pXd_set_huge() implementations could be replaced with generic dummy functions depending on the levels of page-table being used, which in turn broke the boot if we fail to create the linear mapping as a result of using these functions to operate on the pgd. Huge thanks to Michael Ellerman for modifying the revert so as not to regress PPC 8xx in terms of functionality. Anyway, that's the background and it's also available in the commit message along with Link tags pointing at all of the fun. Summary: - Fix hang when issuing SMC on SVE-capable system due to clobbered LR - Fix boot failure due to missing block mappings with folded page-table" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: Revert "mm/pgtable: add stubs for {pmd/pub}_{set/clear}_huge" arm64: smccc: Save lr before calling __arm_smccc_sve_check()
Powered by cgit, Gruvboxed by Blaster4385.