summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-01igc: prepare for RSS key get/set supportKohei Enju
Store the RSS key inside struct igc_adapter and introduce the igc_write_rss_key() helper function. This allows the driver to program the RSSRK registers using a persistent RSS key, instead of using a stack-local buffer in igc_setup_mrqc(). This is a preparation patch for adding RSS key get/set support in subsequent changes, and no functional change is intended in this patch. Signed-off-by: Kohei Enju <kohei@enjuk.jp> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Avigail Dahan <avigailx.dahan@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-07-01remoteproc: qcom_q6v5_pas: Add SoCCP node on KaanapaliJingyi Wang
The SoC Control Processor (SoCCP) is small RISC-V MCU that controls USB Type-C, battery charging and various other functions on Qualcomm SoCs. It provides a solution for control-plane processing, reducing per-subsystem microcontroller reinvention. Add support for SoCCP PAS loader on Kaanapali platform. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Hawi SoC Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-6-1ec7bb5c9fec@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-01remoteproc: qcom: pas: Add late attach support for subsystemsJingyi Wang
Subsystems can be brought out of reset by entities such as bootloaders. As the irq enablement could be later than subsystem bring up, the state of subsystem should be checked by reading SMP2P bits. A new qcom_pas_attach() function is introduced. if crash state is detected for the subsystem, rproc_report_crash() is called. If the ready state is detected meanwhile stop state is not detected, it will be marked as "attached", otherwise it could be the early boot feature is not supported by other entities or it has already been stopped. In above cases, the state will be marked as RPROC_OFFLINE so that the PAS driver can load the firmware and start the remoteproc. Co-developed-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com> Signed-off-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com> Tested-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-5-1ec7bb5c9fec@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-01dt-bindings: remoteproc: qcom: Document pas for SoCCP on Hawi and Maili SoCMukesh Ojha
Document SoCCP remote processor used on Qualcomm Hawi and Maili SoC which is fully compatible with Kaanapali. Co-developed-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-4-1ec7bb5c9fec@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-01dt-bindings: remoteproc: qcom: Document pas for SoCCP on Kaanapali and ↵Jingyi Wang
Glymur platforms Document the component used to boot SoCCP on Kaanapali SoC and add compatible for Glymur SoCCP which could fallback to Kaanapali. Extend the "qcom,smem-states", "qcom,smem-state-names" in the pas-common and add maxItems constraints for SMEM properties in the documents that reference to pas-common. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-3-1ec7bb5c9fec@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-01dt-bindings: remoteproc: qcom: move interrupts and interrupt-names list out ↵Jingyi Wang
of pas-common Move interrupts and interrupt-names list out of pas-common since they will be redefined differently for Kaanapali SoCCP. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-2-1ec7bb5c9fec@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-01dt-bindings: remoteproc: qcom: cleanup qcom,adsp.yamlJingyi Wang
Items in qcom,adsp.yaml has common clock and interrupt properties, move these out of the allOf section to avoid list the compatible repeatly. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-1-1ec7bb5c9fec@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-01leds: trigger: netdev: Extend speeds up to 100GMike Marciniszyn (Meta)
Add 25G, 40G, 50G, and 100G as available speeds to the netdev LED trigger. Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260520200337.204431-2-mike.marciniszyn@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-01leds: pwm-multicolor: Introduce default-intensity propertyJonas Rebmann
Like all LED drivers, pwm-multicolor supports turning on an LED on boot by setting linux,default-trigger, e.g. to "default-on". pwm-multicolor however scales the brightness of the color-component sub-LEDs with their individual intensity value. Since these intensities are zero-initialized, on boot a trigger is invisible until colors are set from userspace. Fix linux,default-trigger for pwm-multicolor by allowing for nonzero default-intensities but default to 0 for backwards-compatibility. Signed-off-by: Jonas Rebmann <jre@pengutronix.de> Link: https://patch.msgid.link/20260605-multicolor-default-v2-2-ed07271df6b0@pengutronix.de Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-01x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC ↵Reinette Chatre
enabled The architecture updates the cpu_mask in a domain's header to track which online CPUs are associated with the domain. When this mask becomes empty the architecture initiates offline of the domain that includes calling on resctrl fs to offline the domain. If it is a monitoring domain in which LLC occupancy is tracked resctrl fs forces the limbo handler to clear all busy RMID state associated with the domain. The limbo handler always reads the current event value associated with a busy RMID irrespective of it being checked as part of regular "is it still busy" check or whether it will be forced released anyway. When reading an RMID on a system with SNC enabled the "logical RMID" is converted to the "physical RMID" and this conversion requires the NUMA node ID of the resctrl monitoring domain that is in turn determined by querying the NUMA node ID of any CPU belonging to the monitoring domain. When the monitoring domain is going offline its cpu_mask is empty causing the NUMA node ID query via cpu_to_node() to be done with "nr_cpu_ids" as argument resulting in an out-of-bounds access. Refactor the limbo handler to skip reading the RMID when the RMID will just be forced to no longer be dirty in the domain anyway. Add a safety check to the architecture's RMID reader to protect against this scenario. Fixes: e13db55b5a0d ("x86/resctrl: Introduce snc_nodes_per_l3_cache") Closes: https://sashiko.dev/#/patchset/cover.1780456704.git.reinette.chatre%40intel.com?part=9 Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: <stable@kernel.org> Link: https://patch.msgid.link/16137433df42f85013b2f7a53626795cbd6637b9.1781029125.git.reinette.chatre@intel.com
2026-07-01bpf,lsm: Drop bpf_prog_free from sleepable_lsm_hooksSechang Lim
__bpf_prog_put_rcu() is the call_rcu() callback for non-sleepable programs. security_bpf_prog_free() called from there fires bpf_prog_free in softirq; if a sleepable LSM prog is attached to that hook, might_fault() BUGs: BUG: sleeping function called from invalid context in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5038 preempt_count: 101, expected: 0 Call Trace: <IRQ> __bpf_prog_enter_sleepable+0x1cd/0x320 kernel/bpf/trampoline.c:1255 bpf_trampoline_6442549705+0x53/0xd7 security_bpf_prog_free+0xde/0x130 security/security.c:5465 __bpf_prog_put_rcu+0xab/0xd0 kernel/bpf/syscall.c:2365 rcu_do_batch kernel/rcu/tree.c:2617 [inline] handle_softirqs+0x236/0x800 kernel/softirq.c:622 </IRQ> The call_rcu/call_rcu_tasks_trace split reflects the freed program's sleepability, not that of any attached observer. security_bpf_prog_free() also frees prog->aux->security, which has to stay after the grace period, so drop bpf_prog_free from sleepable_lsm_hooks rather than move the call. Non-sleepable observers still run there. Fixes: 1b67772e4e3f ("bpf,lsm: Refactor bpf_prog_alloc/bpf_prog_free LSM hooks") Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260701080757.1394144-1-rhkrqnwk98@gmail.com
2026-07-01selftests/bpf: Fix test_maps sockmap failureJiayuan Chen
test_maps fails in the sockmap test because sockmap_verdict_prog.c drops the packet when the first 8 bytes are not directly accessible: if (data + 8 > data_end) return SK_DROP; The blamed commit removed bpf_skb_pull_data() from the stream parser program so that the parser no longer modifies the skb. That was needed, but it also removed an implicit side effect: bpf_skb_pull_data() linearized enough of the skb for later direct packet access. In this test, the send side goes through the sockmap SK_MSG path. The skb can have skb->len == 20 while its linear area is empty, so the verdict program sees data == data_end and drops the packet even though the payload length is sufficient. Keep the parser read-only, and pull the first 8 bytes in the verdict program before reading or writing them. Reload data/data_end after bpf_skb_pull_data() as required. Fixes: 22a0cc10dacb ("selftests/bpf: don't modify the skb in the strparser parser prog") Reported-by: Ihor Solodrai <ihor.solodrai@linux.dev> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260701071501.39628-1-jiayuan.chen@linux.dev Closes: https://lore.kernel.org/bpf/e3a91acd-2b4d-4e93-a3bb-a0e9ee5ede0f@linux.dev/
2026-07-01bpf: Use BPF_CALL_IMM macro consistently in bpf_do_misc_fixupsTiezhu Yang
In bpf_do_misc_fixups(), the conversion from a function address to a BPF immediate value is handled using the BPF_CALL_IMM macro inside the 'patch_map_ops_generic' label block. However, immediately following it in the 'patch_call_imm' label block, the immediate value is calculated manually by subtracting __bpf_call_base from fn->func. Inspired by KaFai Wan's review comments on fixing helper call offsets, use the BPF_CALL_IMM macro in 'patch_call_imm' as well to clean this up. This removes the redundant manual pointer arithmetic and ensures coding style consistency across adjacent label blocks within the same function. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260701035107.8069-1-yangtiezhu@loongson.cn
2026-07-01dt-bindings: sram: qcom,imem: Narrow allowed reboot modesKrzysztof Kozlowski
Only few Qualcomm IMEM devices actually provide interface for setting reboot modes, but top-level schema allows "reboot-mode" child for everyone. Narrow this to specific compatibles. syscon-reboot-mode schema allows arbitrary "mode-.* properties but only a subset actually makes sense and is valid. Provide negative look-ahead pattern to disallow any modes not supported by the device, which tightens the binding even more. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260701105832.197036-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-01selftests/bpf: Mask socket type flags in mptcpify progGuillaume Maudoux
The mptcpify BPF prog upgrades eligible TCP sockets to MPTCP, but only when the socket type is exactly SOCK_STREAM. Its update_socket_protocol() hook runs on the raw type from userspace, before the socket core masks it with SOCK_TYPE_MASK, so the type may still carry SOCK_CLOEXEC or SOCK_NONBLOCK in its upper bits and the equality check fails. As a result, a socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0) -- what common libraries do by default -- is silently left as plain TCP. This was hit in practice with curl. Since mptcpify.c is referenced as example code for enabling MPTCP transparently, the same mistake is likely to be copied into real deployments where it fails the same way and is hard to diagnose. Mask the type before comparing, mirroring the socket core. Extend the test to also create the server with SOCK_CLOEXEC set; the same masking is applied to start_server_addr() so a flagged type still listens. Fixes: ddba122428a7 ("selftests/bpf: Add mptcpify test") Signed-off-by: Guillaume Maudoux <layus.on@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://lore.kernel.org/bpf/20260630095723.564392-1-layus.on@gmail.com
2026-07-01drm/xe/rtp: Add struct types for RTP tablesGustavo Sousa
We currently have a mixture of styles for our RTP tables with respect of how we define the number of entries: * xe_rtp_process_to_sr() expects to receive the number of entries as arguments; * xe_rtp_process() expects the array to have a sentinel at the end of the array; * in xe_rtp_test.c, even though xe_rtp_process_to_sr() does not require a sentinel value, we need to rely on that technique to be able to count xe_rtp_entry_sr entries because simply using ARRAY_SIZE() is not possible. The style used by xe_rtp_process_to_sr() makes it hard to share the tables with other compilation units (e.g. kunit tests), since the number of entries is calculated with ARRAY_SIZE(), which is done at compile time. Since we use the size of the tables to create some bitmasks, using a sentinel style doesn't seem great either. A way to reconcile things into a single style is to have a struct type that would hold the entries array and the number of entries. Since we have xe_rtp_entry and xe_rtp_entry_sr, we would have one type for each. The advantage of the proposed approach is that now we have a nice way to share the tables directly to kunit tests with information about their size. v6: - Removed sentinels that are not needed v5: - Removed added code from conflict resolution issues v4: - Removed conflicts with main branch v3: - No changes v2: - Add compatibility with new xe_rtp_table_sr format for "bad-mcr-reg-forced-to-regular" and "bad-regular-reg-forced-to-mcr" Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260601200947.2032784-7-violet.monti@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 5ff004fdc7377905f2fe5264b8829d35e14608b8) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-01Merge branch 'bpf-tracing_multi-link-info-support'Andrii Nakryiko
Jiri Olsa says: ==================== bpf: tracing_multi link info support hi, adding link info support for tracing_multi link. Adding the kernel support with related selftests and bpftool support to display the tracing_multi link info, the output looks like: # bpftool link ... 61: tracing_multi prog 167 attach_type trace_fentry_multi btf_obj_id 1 count 3 btf_id addr cookie func [module] 92598 ffffffff825017c4 10 bpf_fentry_test1 92600 ffffffff82503814 30 bpf_fentry_test2 92601 ffffffff82503824 20 bpf_fentry_test3 pids test_progs(1540) thanks, jirka v1: https://lore.kernel.org/bpf/20260621204524.61067-1-jolsa@kernel.org/ v2: https://lore.kernel.org/bpf/20260623142417.275892-1-jolsa@kernel.org/ v3: https://lore.kernel.org/bpf/20260629143844.862369-1-jolsa@kernel.org/ v4 changes: - fix wrong allocation check [Alexei] v3 changes: - added acks [Andrii, Leon] - display cookies as decimal numbers [Andrii] - renamed obj_id to btf_obj_id [Andrii] - several fixes in bpftool change [Andrii] v2 changes: - fix kernel symbol search logic [sashiko] - typo fixes [bots] --- ==================== Link: https://patch.msgid.link/20260629212208.895962-1-jolsa@kernel.org Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2026-07-01bpftool: Add tracing_multi link info outputJiri Olsa
Adding bpftool support to show tracing_multi link details, the new output looks like: # bpftool link ... 61: tracing_multi prog 167 attach_type trace_fentry_multi btf_obj_id 1 count 3 btf_id addr cookie func [module] 92598 ffffffff825017c4 10 bpf_fentry_test1 92600 ffffffff82503814 30 bpf_fentry_test2 92601 ffffffff82503824 20 bpf_fentry_test3 pids test_progs(1540) Assisted-by: Codex:GPT-5 Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260629212208.895962-4-jolsa@kernel.org
2026-07-01selftests/bpf: Add tracing_multi link info testsJiri Olsa
Adding tracing_multi link info tests that follow the kprobe_multi and uprobe_multi tests logic. Assisted-by: Codex:GPT-5 Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260629212208.895962-3-jolsa@kernel.org
2026-07-01bpf: Add tracing_multi link info supportJiri Olsa
Adding BPF_OBJ_GET_INFO_BY_FD support for tracing_multi links. We expose following tracing_multi link data: - attach_type of the program - number of ids - array of BTF ids - array of its related kernel addresses - array of cookies The change follows the kprobe_multi and uprobe_multi link-info convention of optional output arrays with an in/out count, On top of standard tracing link data we also expose addresses, because they are useful info for user (especially when the attachment was done via pattern). This data is hidden when kallsyms does not allow exposing kernel pointer values. Assisted-by: Codex:GPT-5 Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Leon Hwang <leon.hwang@linux.dev> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260629212208.895962-2-jolsa@kernel.org
2026-07-01x86/mm: Fix typo in commentYou-Li Lin
Fix "begining" to "beginning" in a code comment. Signed-off-by: You-Li Lin <lhu540507@gmail.com> Acked-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260627051343.51326-1-lhu540507@gmail.com
2026-07-01ASoC: codecs: tas675x: misc bugfixes and minor changesMark Brown
Sen Wang <sen@ti.com> says: Few miscellaneous bug fixes after the initial merge of TAS675x driver, of which includes: - Adding READ_ONCE for all concurrent read params - Corrected kcontrol bits for temperature range - Corrected conversion notes in the driver documentation Link: https://patch.msgid.link/20260630183126.2588322-1-sen@ti.com
2026-07-01Documentation: sound: tas675x: Fix temperature range and impedance documentationSen Wang
Two corrections against the TRM (SLOU589A): - Corrected channel temperature range - Corrected conversion formula for global temperature Fixes: ba46edca354e ("Documentation: sound: Add TAS675x codec mixer controls documentation") Signed-off-by: Sen Wang <sen@ti.com> Link: https://patch.msgid.link/20260630183126.2588322-4-sen@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-01ASoC: codecs: tas675x: Fix CHx temperature range register bit fieldsSen Wang
The initial merged patch mixed up the bits for temp reg with LDG report, now fixing to the right bits according to TRM (SLOU589A). Fixes: 133c81f84471 ("ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver") Signed-off-by: Sen Wang <sen@ti.com> Link: https://patch.msgid.link/20260630183126.2588322-3-sen@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-01ASoC: codecs: tas675x: use READ_ONCE for params to be used concurrentlySen Wang
active_playback_dais and active_capture_dais are written atomically via set_bit()/clear_bit() and can be read concurrently from the fault_check_work delayed work handler. fault_check_work already uses READ_ONCE; extend the same guard to all other reads in tas675x_hw_params() and tas675x_mute_stream(). Fixes: 133c81f84471 ("ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver") Signed-off-by: Sen Wang <sen@ti.com> Link: https://patch.msgid.link/20260630183126.2588322-2-sen@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-01selftests/hid: multitouch: test a large ContactCountMaximumTrung Nguyen
Add a regression test for the out-of-bounds bit operations on struct mt_device.mt_io_flags. A HID multitouch device can advertise a ContactCountMaximum far larger than the number of contacts a single report describes, up to 255. The driver used to keep the per-slot active state in the bits of a single unsigned long and index set_bit()/clear_bit() by the slot number, so such a device drove those operations out of bounds. The sticky-fingers release timer made it fatal: mt_release_contacts() cleared one bit per slot and overwrote the adjacent members of struct mt_device. The new device advertises a ContactCountMaximum of 250 while exposing only a few finger collections (a large contact count cannot be expressed with one finger collection per contact within the HID descriptor size limit). The test sends a single contact and lets the 100ms sticky-fingers timer release it. A kernel without the fix panics in mt_release_contacts(); a fixed kernel reports the release cleanly. Signed-off-by: Trung Nguyen <trungnh@cystack.net> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-07-01HID: multitouch: fix out-of-bounds bit access on mt_io_flagsTrung Nguyen
mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG. As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs for (i = 0; i < mt->num_slots; i++) clear_bit(i, &td->mt_io_flags); with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received). The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required. Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two "mt_io_flags & MT_IO_SLOTS_MASK" arming checks become bitmap_empty(td->active_slots, td->maxcontacts). Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit. Fixes: 46f781e0d151 ("HID: multitouch: fix sticky fingers") Cc: stable@vger.kernel.org Signed-off-by: Trung Nguyen <trungnh@cystack.net> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-07-01Merge branch 'bpf-copy-per-cpu-map-value-padding-in-copy_map_value_long'Andrii Nakryiko
Leon Hwang says: ==================== bpf: Copy per-CPU map value padding in copy_map_value_long() Sashiko reported [1]: This is a pre-existing issue, but does iterating over per-CPU maps expose uninitialized kernel heap memory? When working with per-CPU maps, temporary buffers are allocated using kmalloc without the __GFP_ZERO flag in functions like bpf_iter_init_array_map in kernel/bpf/arraymap.c: kernel/bpf/arraymap.c:bpf_iter_init_array_map() { ... value_buf = kmalloc(buf_size, GFP_USER | __GFP_NOWARN); ... } This is also done in kernel/bpf/hashtab.c:bpf_iter_init_hash_map(). If the map contains a BTF record, bpf_obj_memcpy in include/linux/bpf.h explicitly stops at map->value_size instead of filling the entire rounded-up size: include/linux/bpf.h:bpf_obj_memcpy() { ... memcpy(dst + curr_off, src + curr_off, size - curr_off); ... } This fails to overwrite the padding bytes up to round_up(map->value_size, 8). [1] https://lore.kernel.org/bpf/20260622150844.28C551F000E9@smtp.kernel.org/ === For example, struct map_uninit_value { struct prog_test_ref_kfunc __kptr_untrusted *unref_ptr; __u32 data; } __attribute__((packed)); struct { __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY); __type(key, int); __type(value, struct map_uninit_value); __uint(max_entries, 1); } pcpu_array SEC(".maps"); There are 4 padding bytes in the kernel percpu_array map elements. When lookup element from 'pcpu_array' map, for each CPU, the 4 padding bytes memory allocated by syscall.c::map_lookup_elem():kvmalloc() could be exposed to user space. Without the fix, the selftest could fail with: test_map_uninit_mem_exposure:FAIL:zeroed tail bytes unexpected memory mismatch actual: 2B 2B 2B 2B expected: 00 00 00 00 ==================== Link: https://patch.msgid.link/20260624155115.85196-1-leon.hwang@linux.dev Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2026-07-01selftests/bpf: Verify no non-zeroed kernel heap memory exposureLeon Hwang
When lookup element from those per-CPU maps, which have special field in their values and their value size is not equal to roundup(value_sz, 8), the padding size of temporary non-zeroed kernel heap memory allocated by kvmalloc should not be exposed to user space. Without the fix: test_map_uninit_mem_exposure:FAIL:zeroed tail bytes unexpected memory mismatch actual: 2B 2B 2B 2B expected: 00 00 00 00 Assisted-by: Codex:gpt-5.5 Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260624155115.85196-3-leon.hwang@linux.dev
2026-07-01bpf: Copy per-CPU map value padding in copy_map_value_long()Leon Hwang
In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer. However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8). The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps. Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy path. Fixes: 448325199f57 ("bpf: Add copy_map_value_long to copy to remote percpu memory") Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260624155115.85196-2-leon.hwang@linux.dev
2026-07-01Merge branch 'tools-bpf-bpftool-fix-vmlinux-btf-state-cleanup'Andrii Nakryiko
Yichong Chen says: ==================== tools/bpf/bpftool: Fix vmlinux BTF state cleanup This series fixes stale vmlinux BTF state in bpftool batch mode. Patch 1 resets the map command cached vmlinux BTF pointer when the command releases it, and avoids freeing the cached object from the map lookup path. Patch 2 resets the struct_ops command cached vmlinux BTF pointer and dependent cached map info state after each struct_ops command. Changes in v4: - Add Emil's Reviewed-by tag to patch 1. - Inline the struct_ops cleanup instead of adding a helper. Changes in v3: - Add Fixes tags to both patches. Changes in v2: - Fold the map lookup path fix into patch 1. - Update patch 1 subject and commit message to cover map commands rather than only map dump. ==================== Link: https://patch.msgid.link/12A35C14DA710D2E+20260624025055.1574875-1-chenyichong@uniontech.com Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2026-07-01tools/bpf/bpftool: Reset vmlinux BTF after struct_ops commandsYichong Chen
struct_ops frees the global btf_vmlinux object. In batch mode, a later struct_ops command can reuse stale state. Reset the BTF pointer and cached map info state. Fixes: 65c93628599d ("bpftool: Add struct_ops support") Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/9F9017160ABE125F+20260624025055.1574875-3-chenyichong@uniontech.com
2026-07-01tools/bpf/bpftool: Reset vmlinux BTF after map commandsYichong Chen
get_map_kv_btf() caches the vmlinux BTF object when a map uses btf_vmlinux_value_type_id. map dump released that object when the command completed, but left the global pointer stale. The same cached object can also be returned to print_key_value(), which freed it directly. That leaves btf_vmlinux dangling before the command cleanup path runs. Use free_map_kv_btf() for per-entry cleanup, and reset the cached btf_vmlinux pointer when the map command releases the object. This keeps batch mode from reusing a freed BTF object. Fixes: 4e1ea33292ff ("bpftool: Support dumping a map with btf_vmlinux_value_type_id") Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/9072F43B3F74DF91+20260624025055.1574875-2-chenyichong@uniontech.com
2026-07-01bpftool: Strip all -Wformat* flags from bootstrap libbpf buildAndrii Nakryiko
Commit 9080b97689db ("bpftool: Pass host flags to bootstrap libbpf") started building the bootstrap libbpf with HOST_CFLAGS, stripping the warning options that are unsuitable for that build by filtering out -W -Wall -Wextra -Wformat -Wformat-signedness. HOST_CFLAGS inherits EXTRA_WARNINGS, which includes -Wformat-security and -Wformat-y2k. The filter drops -Wall and -Wformat (the latter being what actually enables -Wformat), but leaves those two -Wformat-* children in LIBBPF_BOOTSTRAP_CFLAGS. Building the bootstrap libbpf with it then warns: cc1: warning: '-Wformat-y2k' ignored without '-Wformat' cc1: warning: '-Wformat-security' ignored without '-Wformat' The warning is easy to miss in an in-tree build: tools/lib/bpf/Makefile re-adds -Wall via "override CFLAGS += -Wall", which re-enables -Wformat for the libbpf objects, so only libbpf's feature-detection probe (which uses the passed CFLAGS verbatim) leaks the two warnings. The standalone libbpf Makefile (github.com/libbpf/libbpf, used by the bpftool mirror) instead uses "CFLAGS ?= ... -Wall", which the passed-in CFLAGS overrides, so -Wall is never re-added and every bootstrap object warns. Use a -Wformat% wildcard in the filter-out so the orphaned children are removed together with the parent. Fixes: 9080b97689db ("bpftool: Pass host flags to bootstrap libbpf") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/bpf/20260630205418.3483969-1-andrii@kernel.org
2026-07-01iio: dac: add mcf54415 DACAngelo Dureghello
Add basic version of mcf54415 DAC driver. DAC is embedded in the SoC and DAC configuration registers are mapped in the internal IO address space. The DAC accepts a 12-bit digital signal and creates a monotonic 12-bit analog output varying from DAC_VREFL to DAC_VREFH. The DAC module consists of a conversion unit, an output amplifier, and the associated digital control blocks. Default register values for DAC_VREFL and DAC_VREFH are respectively 0 and 0xfff, left untouched in this initial version. This initial version of the driver is minimalistic, "output raw" only, to be extended in the future. DMA and external sync are disabled, default mode is high speed, default format is right-justified 12-bit on 16-bit word. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2026-07-01workqueue: dump the last woken worker for stalled poolsBreno Leitao
To identify the task most likely responsible for a stall, add last_woken_worker (L: pool->lock) to worker_pool and record it in kick_pool() just before wake_up_process(). This captures the idle worker that was kicked to take over when the last running worker went to sleep; if the pool is now stuck with no running worker, that task is the prime suspect and its backtrace is dumped by show_pool_no_running_worker(). Using struct worker * rather than struct task_struct * avoids any lifetime concern: workers are only destroyed via set_worker_dying() which requires pool->lock, and set_worker_dying() clears last_woken_worker when the dying worker matches. show_cpu_pool_busy_workers() holds pool->lock while calling sched_show_task(), so last_woken_worker is either NULL or points to a live worker with a valid task. More precisely, set_worker_dying() clears last_woken_worker before setting WORKER_DIE, so a non-NULL last_woken_worker means the kthread has not yet exited and worker->task is still alive. Suggested-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-07-01RDMA/nldev: Add resource summary max values for usage displayTao Cui
Add RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX netlink attribute to expose device resource limits (max_qp, max_cq, max_mr, max_pd, max_srq) in the resource summary alongside the existing current count. This allows userspace tools like iproute2's rdma to display resource usage in curr/max format. Expected output from "rdma resource show": Before: 0: mlx5_0: qp 123 cq 45 mr 200 pd 10 After: 0: mlx5_0: qp 123/131072 cq 45/65536 mr 200/1000000 pd 10/32768 In JSON output, both "curr" and "max" fields will be provided so that scripts can compute percentages if needed. The new attribute is optional and backward compatible - old userspace tools will simply ignore it. Signed-off-by: Tao Cui <cuitao@kylinos.cn> Link: https://patch.msgid.link/20260615003646.168704-1-cui.tao@linux.dev Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-01iio: imu: adis16550: Simplify device abstractionUwe Kleine-König (The Capable Hub)
The driver supports a single chip variant only. Simplify the driver by hard-coding the device properties instead of using the id_table's abstraction for a single chip type and a lookup in a table with only one entry. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2026-07-01iio: temperature: tmp117: add TI TMP119 supportWil Stark
Add support for the TMP119 temperature sensor, which has the same programming model as the TMP117. [rgantois: Commit log] Signed-off-by: Wil Stark <wil_stark@keysight.com> [rgantois: Rebased from v6.6.58 to v7.2-rc1] Signed-off-by: Romain Gantois <romain.gantois@bootlin.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2026-07-01dt-bindings: iio: ti,tmp117: add binding for the TMP119Romain Gantois
The TMP119 has the same register layout as the TMP117, and a better local sensor accuracy. Add a compatible for it. Use ti,tmp117 as a fallback compatible for ti,tmp119. Signed-off-by: Romain Gantois <romain.gantois@bootlin.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2026-07-01iio: adc: ti-tsc2046: Simplify device handlingUwe Kleine-König (The Capable Hub)
The driver was introduced in 2021 and since then only supports a single chip variant. Simplify the driver by hard-coding the device properties instead of using the id_table's abstraction for a single chip type. Also drop the write-only struct member dcfg and the then unused struct definition. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2026-07-01drm/mxsfb/lcdif: don't hide lcdif_attach_bridge() deferral messagesLuca Ceresoli
lcdif_attach_bridge() uses dev_err_probe() on all its error returns to store a specific deferral message. However its caller lcdif_load() calls dev_err_probe() again on error, overwriting the specific deferral messages with a unique, unavoidably generic, message. Make the specific deferral message visible by using a plain 'return ret' on the caller. Acked-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260619-drm-lcdif-deferral-msg-v1-1-ce2392dca985@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-01drm/amdgpu/jpeg: fix jpeg_v4_0_3_is_idle detectionBoyuan Zhang
jpeg_v4_0_3_is_idle() initializes ret to false and then accumulates ring idle status using &=. Since false & condition always remains false, the function can never report the JPEG block as idle. Initialize ret to true so the function returns true only when all JPEG rings report RB_JOB_DONE. Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e9df8e9d04e0593d17ddb069f3b7958991cd18c9) Cc: stable@vger.kernel.org
2026-07-01drm/amdgpu: Fix kernel panic during driver load failureHarish Kasiviswanathan
Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0) Cc: stable@vger.kernel.org
2026-07-01drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks ↵WenTao Liang
prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. Fixes: 54618888d1ea ("drm/amd/display: break down dc_link.c") Signed-off-by: WenTao Liang <vulab@iscas.ac.cn> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260626124555.36910-1-vulab@iscas.ac.cn Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d) Cc: stable@vger.kernel.org
2026-07-01drm/amd/pm: fix smu13 power limit range calculationYang Wang
SMU13 reports SocketPowerLimitAc/Dc as the default power limit, but MsgLimits.Power may carry a different firmware bound for the same PPT throttler. Using only the socket limit for both min and max can therefore expose an incorrect power range. Keep the socket limit as the default, but derive the range from both values: use the lower value for the min base and the higher value for the max base before applying OD percentages. Keep the current limit query independent from the cap calculation. Fixes: 1eaf26db9590 ("drm/amd/pm: fix smu13 power limit default/cap calculation") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5419 Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f45bbf0f62f266ed8422d84f347d75d5fca846a7) Cc: stable@vger.kernel.org
2026-07-01drm/amdgpu: flush pending RCU callbacks on module unloadPerry Yuan
Call rcu_barrier() in module exit to wait for outstanding call_rcu() callbacks before freeing module text, preventing late callback execution in freed memory. BUG: unable to handle page fault for address: ffffffffc1d59c40 PGD 6a12067 P4D 6a12067 PUD 6a14067 PMD 13698b067 PTE 0 Oops: 0010 [#1] SMP NOPTI RIP: 0010:0xffffffffc1d59c40 Code: Unable to access opcode bytes at RIP 0xffffffffc1d59c16. RSP: 0018:ffffc900198c0f28 EFLAGS: 00010286 RAX: ffffffffc1d59c40 RBX: ffff897c7d6b61c0 RCX: ffff88826aff4590 RDX: ffff8884d8b35490 RSI: ffffc900198c0f30 RDI: ffff88812af67290 RBP: 000000000000000a (DONE segment entries) R08: 0000000000000000 R09: 0000000000000100 R10: 0000000000000000 R11: ffffffff82a06100 R12: ffff88811a4e3700 R13: 0000000000000000 R14: ffff897c7d6b6270 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff897c7d680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc1d59c16 CR3: 00000104a980a001 CR4: 0000000002770ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? rcu_do_batch+0x163/0x450 ? rcu_core+0x177/0x1c0 ? __do_softirq+0xc1/0x280 ? asm_call_irq_on_stack+0xf/0x20 </IRQ> ? do_softirq_own_stack+0x37/0x50 ? irq_exit_rcu+0xc4/0x100 ? sysvec_apic_timer_interrupt+0x36/0x80 ? asm_sysvec_apic_timer_interrupt+0x12/0x20 ? cpuidle_enter_state+0xd4/0x360 ? cpuidle_enter+0x29/0x40 ? cpuidle_idle_call+0x108/0x1a0 ? do_idle+0x77/0xf0 ? cpu_startup_entry+0x19/0x20 ? secondary_startup_64_no_verify+0xbf/0xcb Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit feaa5039f6c12acc9aa934c2d45dcd251a12c69f)
2026-07-01drm/amdgpu: Fix AMDGPU_GTT_MAX_TRANSFER_SIZE for non-4K systemsDonet Tom
Running RCCL unit tests on a system with a 64K PAGE_SIZE triggers the following warning and causes the test to terminate on latest upstream kernel: WARNING: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1335 at amdgpu_bo_release_notify+0x1bc/0x280 [amdgpu], CPU#18: rccl-UnitTests/33151 Call trace: amdgpu_bo_release_notify ttm_bo_release amdgpu_gem_object_free drm_gem_object_free amdgpu_bo_unref amdgpu_bo_create amdgpu_bo_create_user amdgpu_gem_object_create amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu kfd_ioctl_alloc_memory_of_gpu kfd_ioctl sys_ioctl The warning is triggered because amdgpu_ttm_next_clear_entity() returns NULL when a clear buffer operation is requested. This happens because the GART window allocation for the default_entity, clear_entity and move_entity fails during initialization. Commit [1] introduced separate GART windows for the default_entity, clear_entity and move_entity of each SDMA instance. Their sizes are derived from AMDGPU_GTT_MAX_TRANSFER_SIZE, which is currently defined as 1024 pages. This implicitly assumes a 4K PAGE_SIZE, where 1024 pages correspond to a 4MB transfer. On a 64K PAGE_SIZE system, however, the same value expands to 64MB. The default_entity and clear_entity each allocate one AMDGPU_GTT_MAX_TRANSFER_SIZE GART window, while the move_entity allocates two such windows. This results in 16MB of GART space per SDMA instance on a 4K PAGE_SIZE system, but 256MB per SDMA instance on a 64K PAGE_SIZE system. On an MI210 system with five SDMA instances and a 512MB GART aperture, the total GART space required becomes 1.25GB, exceeding the available GART aperture. Consequently, GART window allocation fails, amdgpu_ttm_next_clear_entity() returns NULL, and the above warning is triggered. Redefine AMDGPU_GTT_MAX_TRANSFER_SIZE in bytes instead of page units. Where a page count is required, convert it using PAGE_SHIFT. This preserves the existing 4MB transfer size across all PAGE_SIZE configurations while keeping GART window allocations within the available GART aperture. [1] https://lore.kernel.org/all/20260408100327.1372-3-pierre-eric.pelloux-prayer@amd.com/#t Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5435 Fixes: 897ee11ec020 ("drm/amdgpu: create multiple clear/move ttm entities") Signed-off-by: Donet Tom <donettom@linux.ibm.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 27213b776a666d3030de5acc3cd75278197b0494) Cc: stable@vger.kernel.org
2026-07-01drm/amdkfd: Use kvcalloc to allocate arraysDavid Francis
There were a few instances in kfd_chardev.c of kvzalloc being used to allocate memory for an array. Switch those to kvcalloc, which - is the standard way of allocating a zero-initialized array - does a check for the mul overflowing Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 60b048c93f7a3add39757ad65fe2bb6e58eeae23) Cc: stable@vger.kernel.org
2026-07-01drm/amdgpu: add support for GC IP version 11.7.1Granthali Vinodkumar Dhandar
Initialize GC IP 11_7_1 Signed-off-by: Granthali Vinodkumar Dhandar <granthali.vinodkumardhandar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit a928d8d81ec5cdb5a8944d08136720811efad0f6)
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-19 09:15:48 +0000