Select Git revision
Search by author
- Any Author
- authors
-
72162444 72162444 gaochangning
-
Aakash Dave aakash.dave
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Lan aaron.lan
-
Aaron Nabil aaronna
-
Aaron Pohle aaron.pohle
-
Abbott Chung chung.abbott
-
Abdallah Omar abdallah_omar
-
Abdessamii Chalbi abdessamii.chalbi
-
Abdul Hussain Sirajudeen abdul.hussain
-
Abdullah Alghamdi a.alghamdi
-
Abdullah Elmarghany abdullah_elmarghany
-
Abel Fang abel_fang
-
Abel Vesa
abel.vesa
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
- Mar 22, 2025
-
-
Alban Kurti authored
[ Upstream commit 6933c106 ] Several pr_info! calls in rust/kernel/init.rs (both in code examples and macro documentation) were missing a newline, causing logs to run together. This commit updates these calls to include a trailing newline, improving readability and consistency with the C side. Fixes: 6841d45a ("rust: init: add `stack_pin_init!` macro") Fixes: 7f8977a7 ("rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>`") Fixes: d0fdc396 ("rust: init: add `PinnedDrop` trait and macros") Fixes: 4af84c6a ("rust: init: update expanded macro explanation") Reported-by:
Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1139 Signed-off-by:
Alban Kurti <kurti@invicto.ai> Link: https://lore.kernel.org/r/20250206-printing_fix-v3-3-a85273b501ae@invicto.ai [ Replaced Closes with Link since it fixes part of the issue. Added one more Fixes tag (still same set of stable kernels). - Miguel ] Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Charles Keepax authored
[ Upstream commit e26f1cfe ] The range of ADC volume is -1 -> 3 (-6 to 18dB) so the number of levels should actually be 4. Fixes: fc918cbe ("ASoC: cs42l43: Add support for the cs42l43") Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250306133254.1861046-1-ckeepax@opensource.cirrus.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Ivan Abramov authored
[ Upstream commit 9af152dc ] Since pci_get_domain_bus_and_slot() can return NULL, add NULL check for pci_gfx_root in the mid_get_vbt_data(). This change is similar to the checks implemented in mid_get_fuse_settings() and mid_get_pci_revID(), which were introduced by commit 0cecdd81 ("gma500: Final enables for Oaktrail") as "additional minor bulletproofing". Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: f910b411 ("gma500: Add the glue to the various BIOS and firmware interfaces") Signed-off-by:
Ivan Abramov <i.abramov@mt-integration.ru> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306112046.17144-1-i.abramov@mt-integration.ru Signed-off-by:
-
Alban Kurti authored
[ Upstream commit 6f5c36f5 ] Added missing newline at the end of pr_warn! usage so the log is not missed. Fixes: 6551a7fe ("rust: error: Add Error::from_errno{_unchecked}()") Reported-by:
-
Charles Keepax authored
[ Upstream commit 0eba2a7e ] This reverts commit 9bdd10d5 ("ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min"), and makes some additional related updates. There are two ways the platform_max could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it was technically correct as snd_soc_limit_volume() also used the register interpretation. However, even then most of the other usages treated platform_max as a control value, and snd_soc_limit_volume() has since been updated to also do so in commit fb9ad244 ("ASoC: ops: add correct range check for limiting volume"). That patch however, missed updating snd_soc_put_volsw() back to the control interpretation, and fixing snd_soc_info_volsw_range(). The control interpretation makes more sense as limiting is typically done from the machine driver, so it is appropriate to use the customer facing representation rather than the internal codec representation. Update all the code to consistently use this interpretation of platform_max. Finally, also add some comments to the soc_mixer_control struct to hopefully avoid further patches switching between the two approaches. Fixes: fb9ad244 ("ASoC: ops: add correct range check for limiting volume") Signed-off-by:
-
Andrea Righi authored
commit 9360dfe4 upstream. If a BPF scheduler provides an invalid CPU (outside the nr_cpu_ids range) as prev_cpu to scx_bpf_select_cpu_dfl() it can cause a kernel crash. To prevent this, validate prev_cpu in scx_bpf_select_cpu_dfl() and trigger an scx error if an invalid CPU is specified. Fixes: f0e1a064 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by:
Andrea Righi <arighi@nvidia.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andrei Botila authored
commit 48939523 upstream. TJA1120B/TJA1121B can achieve a stable operation of SGMII after a startup event by putting the SGMII PCS into power down mode and restart afterwards. It is necessary to put the SGMII PCS into power down mode and back up. Cc: stable@vger.kernel.org Fixes: f1fe5dff ("net: phy: nxp-c45-tja11xx: add TJA1120 support") Signed-off-by:
Andrei Botila <andrei.botila@oss.nxp.com> Link: https://patch.msgid.link/20250304160619.181046-3-andrei.botila@oss.nxp.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Andrei Botila authored
commit a07364b3 upstream. The most recent sillicon versions of TJA1120 and TJA1121 can achieve full silicon performance by putting the PHY in managed mode. It is necessary to apply these PHY writes before link gets established. Application of this fix is required after restart of device and wakeup from sleep. Cc: stable@vger.kernel.org Fixes: f1fe5dff ("net: phy: nxp-c45-tja11xx: add TJA1120 support") Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250304160619.181046-2-andrei.botila@oss.nxp.com Signed-off-by:
-
Paulo Alcantara authored
commit fc99045e upstream. When mounting a CIFS share with 'guest' mount option, mount.cifs(8) will set empty password= and password2= options. Currently we only handle empty strings from user= and password= options, so the mount will fail with cifs: Bad value for 'password2' Fix this by handling empty string from password2= option as well. Link: https://bbs.archlinux.org/viewtopic.php?id=303927 Reported-by:
Adam Williamson <awilliam@redhat.com> Closes: https://lore.kernel.org/r/83c00b5fea81c07f6897a5dd3ef50fd3b290f56c.camel@redhat.com Fixes: 35f83426 ("smb3: fix broken reconnect when password changing on the server by allowing password rotation") Cc: stable@vger.kernel.org Signed-off-by:
Paulo Alcantara (Red Hat) <pc@manguebit.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Haoxiang Li authored
commit d2b9d97e upstream. Add qlcnic_sriov_free_vlans() in qlcnic_sriov_alloc_vlans() if any sriov_vlans fails to be allocated. Add qlcnic_sriov_free_vlans() to free the memory allocated by qlcnic_sriov_alloc_vlans() if "sriov->allowed_vlans" fails to be allocated. Fixes: 91b7282b ("qlcnic: Support VLAN id config.") Cc: stable@vger.kernel.org Signed-off-by:
Haoxiang Li <haoxiang_li2024@163.com> Link: https://patch.msgid.link/20250307094952.14874-1-haoxiang_li2024@163.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Piotr Jaroszynski authored
commit f7edb07a upstream. Update the __flush_tlb_range_op macro not to modify its parameters as these are unexepcted semantics. In practice, this fixes the call to mmu_notifier_arch_invalidate_secondary_tlbs() in __flush_tlb_range_nosync() to use the correct range instead of an empty range with start=end. The empty range was (un)lucky as it results in taking the invalidate-all path that doesn't cause correctness issues, but can certainly result in suboptimal perf. This has been broken since commit 6bbd42e2 ("mmu_notifiers: call invalidate_range() when invalidating TLBs") when the call to the notifiers was added to __flush_tlb_range(). It predates the addition of the __flush_tlb_range_op() macro from commit 36083902 ("arm64: tlb: Refactor the core flush algorithm of __flush_tlb_range") that made the bug hard to spot. Fixes: 6bbd42e2 ("mmu_notifiers: call invalidate_range() when invalidating TLBs") Signed-off-by:
Piotr Jaroszynski <pjaroszynski@nvidia.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Raghavendra Rao Ananta <rananta@google.com> Cc: SeongJae Park <sj@kernel.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Nicolin Chen <nicolinc@nvidia.com> Cc: linux-arm-kernel@lists.infradead.org Cc: iommu@lists.linux.dev Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Reviewed-by:
Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/r/20250304085127.2238030-1-pjaroszynski@nvidia.com Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Zhenhua Huang authored
commit d4234d13 upstream. On the arm64 platform with 4K base page config, SECTION_SIZE_BITS is set to 27, making one section 128M. The related page struct which vmemmap points to is 2M then. Commit c1cc1552 ("arm64: MMU initialisation") optimizes the vmemmap to populate at the PMD section level which was suitable initially since hot plug granule is always one section(128M). However, commit ba72b4c8 ("mm/sparsemem: support sub-section hotplug") introduced a 2M(SUBSECTION_SIZE) hot plug granule, which disrupted the existing arm64 assumptions. The first problem is that if start or end is not aligned to a section boundary, such as when a subsection is hot added, populating the entire section is wasteful. The next problem is if we hotplug something that spans part of 128 MiB section (subsections, let's call it memblock1), and then hotplug something that spans another part of a 128 MiB section(subsections, let's call it memblock2), and subsequently unplug memblock1, vmemmap_free() will clear the entire PMD entry which also supports memblock2 even though memblock2 is still active. Assuming hotplug/unplug sizes are guaranteed to be symmetric. Do the fix similar to x86-64: populate to pages levels if start/end is not aligned with section boundary. Cc: stable@vger.kernel.org # v5.4+ Fixes: ba72b4c8 ("mm/sparsemem: support sub-section hotplug") Acked-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
Zhenhua Huang <quic_zhenhuah@quicinc.com> Reviewed-by:
Oscar Salvador <osalvador@suse.de> Reviewed-by:
-
Kent Overstreet authored
commit 57e9417f upstream. Fix memory corruption due to incorrect parameter being passed to bio_init Signed-off-by:
Kent Overstreet <kent.overstreet@linux.dev> Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org # v6.5+ Fixes: 1d9a9438 ("dm flakey: clone pages on write bio before corrupting them") Signed-off-by:
-
Mina Almasry authored
commit f3600c86 upstream. Currently on stable trees we have support for netmem/devmem RX but not TX. It is not safe to forward/redirect an RX unreadable netmem packet into the device's TX path, as the device may call dma-mapping APIs on dma addrs that should not be passed to it. Fix this by preventing the xmit of unreadable skbs. Tested by configuring tc redirect: sudo tc qdisc add dev eth1 ingress sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ip_proto \ tcp src_ip 192.168.1.12 action mirred egress redirect dev eth1 Before, I see unreadable skbs in the driver's TX path passed to dma mapping APIs. After, I don't see unreadable skbs in the driver's TX path passed to dma mapping APIs. Fixes: 65249feb ("net: add support for skbs with unreadable frags") Suggested-by:
Mina Almasry <almasrymina@google.com> Link: https://patch.msgid.link/20250306215520.1415465-1-almasrymina@google.com Signed-off-by:
-
Thomas Mizrahi authored
commit 0704a15b upstream. The internal microphone on the Lenovo ThinkPad E16 model requires a quirk entry to work properly. This was fixed in a previous patch (linked below), but depending on the specific variant of the model, the product name may be "21M5" or "21M6". The following patch fixed this issue for the 21M5 variant: https://lore.kernel.org/all/20240725065442.9293-1-tiwai@suse.de/ This patch adds support for the microphone on the 21M6 variant. Link: https://github.com/ramaureirac/thinkpad-e14-linux/issues/31 Cc: stable@vger.kernel.org Signed-off-by:
Thomas Mizrahi <thomasmizra@gmail.com> Link: https://patch.msgid.link/20250308041303.198765-1-thomasmizra@gmail.com Signed-off-by:
-
Peter Ujfalusi authored
commit 4363f02a upstream. Initialize current_be_id to 0 to handle the unlikely case when there are no devices connected to a DAI. In this case create_sdw_dailink() would return without touching the passed pointer to current_be_id. Found by gcc -fanalyzer Fixes: 59bf457d ("ASoC: intel: sof_sdw: Factor out SoundWire DAI creation") Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20250303065552.78328-1-yung-chuan.liao@linux.intel.com Signed-off-by:
-
Peter Griffin authored
commit f2052a4a upstream. EARLY_WAKEUP_SW_TRIG_*_SET and EARLY_WAKEUP_SW_TRIG_*_CLEAR registers are only writeable. Attempting to read these registers during samsung_clk_save() causes a synchronous external abort. Remove these 8 registers from cmu_top_clk_regs[] array so that system suspend gets further. Note: the code path can be exercised using the following command: echo mem > /sys/power/state Fixes: 2c597bb7 ("clk: samsung: clk-gs101: Add cmu_top, cmu_misc and cmu_apm support") Signed-off-by:
Peter Griffin <peter.griffin@linaro.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250303-clk-suspend-fix-v1-1-c2edaf66260f@linaro.org Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Varada Pavani authored
commit 53517a70 upstream. Currently PLL142XX locktime is 270. As per spec, it should be 150. Hence update PLL142XX controller locktime to 150. Cc: stable@vger.kernel.org Fixes: 4f346005 ("clk: samsung: fsd: Add initial clock support") Signed-off-by:
Varada Pavani <v.pavani@samsung.com> Link: https://lore.kernel.org/r/20250225131918.50925-3-v.pavani@samsung.com Signed-off-by:
-
Namjae Jeon authored
commit 3aa660c0 upstream. ksmbd_work could be freed when after connection release. Increment r_count of ksmbd_conn to indicate that requests are not finished yet and to not release the connection. Cc: stable@vger.kernel.org Reported-by:
Norbert Szetei <norbert@doyensec.com> Tested-by:
Namjae Jeon <linkinjeon@kernel.org> Signed-off-by:
-
Namjae Jeon authored
commit bb39ed47 upstream. ->interim_entry of ksmbd_work could be deleted after oplock is freed. We don't need to manage it with linked list. The interim request could be immediately sent whenever a oplock break wait is needed. Cc: stable@vger.kernel.org Reported-by:
-
Mario Limonciello authored
commit e65e7bea upstream. [Why] A slab-use-after-free is reported when HDCP is destroyed but the property_validate_dwork queue is still running. [How] Cancel the delayed work when destroying workqueue. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4006 Fixes: da3fd7ac ("drm/amd/display: Update CP property based on HW query") Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Alex Hung <alex.hung@amd.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
Tom Chung <chiahsuan.chung@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 725a04ba) Cc: stable@vger.kernel.org Signed-off-by:
-
Alex Hung authored
commit 79e31396 upstream. [WHY & HOW] A warning message "WARNING: CPU: 4 PID: 459 at ... /dc_resource.c:3397 calculate_phy_pix_clks+0xef/0x100 [amdgpu]" occurs because the display_color_depth == COLOR_DEPTH_141414 is not handled. This is observed in Radeon RX 6600 XT. It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests. Also fixes the indentation in get_norm_pix_clk. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Mario Limonciello authored
commit 5760388d upstream. [Why] GPU reset will attempt to restore cached state, but brightness doesn't get restored. It will come back at 100% brightness, but userspace thinks it's the previous value. [How] When running resume sequence if GPU is in reset restore brightness to previous value. Acked-by:
Wayne Lin <Wayne.Lin@amd.com> Signed-off-by:
-
Aliaksei Urbanski authored
commit e204aab7 upstream. Starting from 6.11, AMDGPU driver, while being loaded with amdgpu.dc=1, due to lack of .is_two_pixels_per_container function in dce60_tg_funcs, causes a NULL pointer dereference on PCs with old GPUs, such as R9 280X. So this fix adds missing .is_two_pixels_per_container to dce60_tg_funcs. Reported-by:
Rosen Penev <rosenp@gmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3942 Fixes: e6a901a0 ("drm/amd/display: use even ODM slice width for two pixels per container") Signed-off-by:
Aliaksei Urbanski <aliaksei.urbanski@gmail.com> Signed-off-by:
-
Mario Limonciello authored
commit b5a981e1 upstream. [Why] To avoid flickering during boot default brightness level set by BIOS should be maintained for as much of the boot as feasible. commit 2fe87f54 ("drm/amd/display: Set default brightness according to ACPI") attempted to set the right levels for AC vs DC, but brightness still got reset to maximum level in initialization code for setup_backlight_device(). [How] Remove the hardcoded initialization in setup_backlight_device() and instead program brightness value to match BIOS (AC or DC). This avoids a brightness flicker from kernel changing the value. Userspace may however still change it during boot. Fixes: 2fe87f54 ("drm/amd/display: Set default brightness according to ACPI") Acked-by:
-
Leo Li authored
commit 40b8c149 upstream. [Why] It seems HPD interrupts are enabled by default for all connectors, even if the hpd source isn't valid. An eDP for example, does not have a valid hpd source (but does have a valid hpdrx source; see construct_phy()). Thus, eDPs should have their hpd interrupt disabled. In the past, this wasn't really an issue. Although the driver gets interrupted, then acks by writing to hw registers, there weren't any subscribed handlers that did anything meaningful (see register_hpd_handlers()). But things changed with the introduction of IPS. s2idle requires that the driver allows IPS for DMUB fw to put hw to sleep. Since register access requires hw to be awake, the driver will block IPS entry to do so. And no IPS means no hw sleep during s2idle. This was the observation on DCN35 systems with an eDP. During suspend, the eDP toggled its hpd pin as part of the panel power down sequence. The driver was then interrupted, and acked by writing to registers, blocking IPS entry. [How] Since DC marks eDP connections as having invalid hpd sources (see construct_phy()), DM should disable them at the hw level. Do so in amdgpu_dm_hpd_init() by disabling all hpd ints first, then selectively enabling ones for connectors that have valid hpd sources. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
-
David Rosca authored
commit df1e82e7 upstream. We advertise DCC as supported for NV12/P010 formats on GFX12, but it would fail on this check on atomic commit. Signed-off-by:
David Rosca <david.rosca@amd.com> Reviewed-by:
Ruijing Dong <ruijing.dong@amd.com> Signed-off-by:
-
Yifan Zha authored
commit 0882ca4e upstream. [Why] If reset is detected and kfd need to evict working queues, HWS moving queue will be failed. Then remaining queues are not evicted and in active state. After reset done, kfd uses HWS to termination remaining activated queues but HWS is resetted. So remove queue will be failed again. [How] Keep removing all queues even if HWS returns failed. It will not affect cpsch as it checks reset_domain->sem. v2: If any queue failed, evict queue returns error. v3: Declare err inside the if-block. Reviewed-by:
Felix Kuehling <felix.kuehling@amd.com> Signed-off-by:
Yifan Zha <Yifan.Zha@amd.com> Signed-off-by:
-
Natalie Vock authored
commit 6cc30748 upstream. PRT BOs may not have any backing store, so bo->tbo.resource will be NULL. Check for that before dereferencing. Fixes: 0cce5f28 ("drm/amdkfd: Check correct memory types for is_system variable") Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Natalie Vock <natalie.vock@gmx.de> Signed-off-by:
-
Imre Deak authored
commit 12d8f318 upstream. The handling of the MST Connection Status Notify message is skipped if the probing of the topology is still pending. Acquiring the drm_dp_mst_topology_mgr::probe_lock for this in drm_dp_mst_handle_up_req() is problematic: the task/work this function is called from is also responsible for handling MST down-request replies (in drm_dp_mst_handle_down_rep()). Thus drm_dp_mst_link_probe_work() - holding already probe_lock - could be blocked waiting for an MST down-request reply while drm_dp_mst_handle_up_req() is waiting for probe_lock while processing a CSN message. This leads to the probe work's down-request message timing out. A scenario similar to the above leading to a down-request timeout is handling a CSN message in drm_dp_mst_handle_conn_stat(), holding the probe_lock and sending down-request messages while a second CSN message sent by the sink subsequently is handled by drm_dp_mst_handle_up_req(). Fix the above by moving the logic to skip the CSN handling to drm_dp_mst_process_up_req(). This function is called from a work (separate from the task/work handling new up/down messages), already holding probe_lock. This solves the above timeout issue, since handling of down-request replies won't be blocked by probe_lock. Fixes: ddf98348 ("drm/dp_mst: Skip CSN if topology probing is not done yet") Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org # v6.6+ Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250307183152.3822170-1-imre.deak@intel.com Signed-off-by:
-
Ville Syrjälä authored
commit de93ddf8 upstream. Video players (eg. mpv) do periodic XResetScreenSaver() calls to keep the screen on while the video playing. The modesetting ddx plumbs these straight through into the kernel as DPMS setproperty ioctls, without any filtering whatsoever. When implemented via atomic these end up as empty commits on the crtc (which will nonetheless take one full frame), which leads to a dropped frame every time XResetScreenSaver() is called. Let's just filter out redundant DPMS property changes in the kernel to avoid this issue. v2: Explain the resulting commits a bit better (Sima) Document the behaviour in uapi docs (Sima) Cc: stable@vger.kernel.org Testcase: igt/kms_flip/flip-vs-dpms-on-nop Reviewed-by:
Simona Vetter <simona.vetter@ffwll.ch> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250219160239.17502-1-ville.syrjala@linux.intel.com Signed-off-by:
-
Miguel Ojeda authored
commit cba3b869 upstream. Starting with the upcoming Rust 1.86.0 (to be released 2025-04-03), Clippy warns: error: doc list item overindented --> drivers/gpu/drm/drm_panic_qr.rs:914:5 | 914 | /// will be encoded as binary segment, otherwise it will be encoded | ^^^ help: try using ` ` (2 spaces) | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_overindented_list_items The overindentation is slightly hard to notice, since all the items start with a backquote that makes it look OK, but it is there. Thus fix it. Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by:
Alice Ryhl <aliceryhl@google.com> Signed-off-by:
-
Miguel Ojeda authored
commit 986c2e9c upstream. Starting with the upcoming Rust 1.86.0 (to be released 2025-04-03), Clippy warns: error: manually reimplementing `div_ceil` --> drivers/gpu/drm/drm_panic_qr.rs:548:26 | 548 | let pad_offset = (offset + 7) / 8; | ^^^^^^^^^^^^^^^^ help: consider using `.div_ceil()`: `offset.div_ceil(8)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_div_ceil And similarly for `stride`. Thus apply the suggestion to both. The behavior (and thus codegen) is not exactly equivalent [1][2], since `div_ceil()` returns the right value for the values that currently would overflow. Link: https://github.com/rust-lang/rust-clippy/issues/14333 [1] Link: https://godbolt.org/z/dPq6nGnv3 [2] Signed-off-by:
-
Ville Syrjälä authored
commit 6266f4a7 upstream. We currently call intel_set_cdclk_post_plane_update() far too early. When pipes are active during the reprogramming the current spot only works for the cd2x divider update case, as that is synchronize to the pipe's vblank. Squashing and crawling are not synchronized in any way, so doing the programming while the pipes/planes are potentially still using the old hardware state could lead to underruns. Move the post plane reprgramming to a spot where we know that the pipes/planes have switched over the new hardware state. Cc: stable@vger.kernel.org Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> (cherry picked from commit fb64f556) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Conor Dooley authored
commit 91cf42c6 upstream. When the size of a transfer exceeds the size of the FIFO (32 bytes), RX overflows will be generated and receive data will be corrupted and warnings will be produced. For example, here's an error generated by a transfer of 36 bytes: spi_master spi0: mchp_corespi_interrupt: RX OVERFLOW: rxlen: 4, txlen: 0 The driver is currently split between handling receiving in the interrupt handler, and sending outside of it. Move all handling out of the interrupt handling, and explicitly link the number of bytes read of of the RX FIFO to the number written into the TX one. This both resolves the overflow problems as well as simplifying the flow of the driver. CC: stable@vger.kernel.org Fixes: 9ac8d176 ("spi: add support for microchip fpga spi controllers") Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20250303-veal-snooper-712c1dfad336@wendy Signed-off-by:
-
Florent Revest authored
commit e3e89178 upstream. Currently, load_microcode_amd() iterates over all NUMA nodes, retrieves their CPU masks and unconditionally accesses per-CPU data for the first CPU of each mask. According to Documentation/admin-guide/mm/numaperf.rst: "Some memory may share the same node as a CPU, and others are provided as memory only nodes." Therefore, some node CPU masks may be empty and wouldn't have a "first CPU". On a machine with far memory (and therefore CPU-less NUMA nodes): - cpumask_of_node(nid) is 0 - cpumask_first(0) is CONFIG_NR_CPUS - cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of bounds This does not have any security implications since flashing microcode is a privileged operation but I believe this has reliability implications by potentially corrupting memory while flashing a microcode update. When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashes a microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type 'unsigned long[512]' [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Change the loop to go over only NUMA nodes which have CPUs before determining whether the first CPU on the respective node needs microcode update. [ bp: Massage commit message, fix typo. ] Fixes: 7ff6edf4 ("x86/microcode/AMD: Fix mixed steppings support") Signed-off-by:
Florent Revest <revest@chromium.org> Signed-off-by:
Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250310144243.861978-1-revest@chromium.org Signed-off-by:
-
Benno Lossin authored
commit df27cef1 upstream. According to [1], `NonNull<T>` and `#[repr(transparent)]` wrapper types such as our custom `KBox<T>` have the null pointer optimization only if `T: Sized`. Thus remove the `Zeroable` implementation for the unsized case. Link: https://doc.rust-lang.org/stable/std/option/index.html#representation [1] Reported-by:
Benno Lossin <benno.lossin@proton.me> Reviewed-by:
Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250305132836.2145476-1-benno.lossin@proton.me [ Added Closes tag and moved up the Reported-by one. - Miguel ] Signed-off-by:
-
Matthew Maurer authored
commit 5daa0c35 upstream. The kernel cannot currently self-parse BTF containing Rust debug information. pahole uses the language of the CU to determine whether to filter out debug information when generating the BTF. When LTO is enabled, Rust code can cross CU boundaries, resulting in Rust debug information in CUs labeled as C. This results in a system which cannot parse its own BTF. Signed-off-by:
Matthew Maurer <mmaurer@google.com> Cc: stable@vger.kernel.org Fixes: c1177979 ("btf, scripts: Exclude Rust CUs with pahole") Link: https://lore.kernel.org/r/20250108-rust-btf-lto-incompat-v1-1-60243ff6d820@google.com Signed-off-by:
-
Tamir Duberstein authored
commit ff64846b upstream. ISO C's `aligned_alloc` is partially implementation-defined; on some systems it inherits stricter requirements from POSIX's `posix_memalign`. This causes the call added in commit dd09538f ("rust: alloc: implement `Cmalloc` in module allocator_test") to fail on macOS because it doesn't meet the requirements of `posix_memalign`. Adjust the call to meet the POSIX requirement and add a comment. This fixes failures in `make rusttest` on macOS. Acked-by:
Danilo Krummrich <dakr@kernel.org> Cc: stable@vger.kernel.org Fixes: dd09538f ("rust: alloc: implement `Cmalloc` in module allocator_test") Signed-off-by:
Tamir Duberstein <tamird@gmail.com> Reviewed-by:
Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20250213-aligned-alloc-v7-1-d2a2d0be164b@gmail.com [ Added Cc: stable. - Miguel ] Signed-off-by:
-
Miguel Ojeda authored
commit 374908a1 upstream. In commit 392e34b6 ("kbuild: rust: remove the `alloc` crate and `GlobalAlloc`") we stopped using the upstream `alloc` crate. Thus remove a few leftover mentions treewide. Cc: stable@vger.kernel.org # Also to 6.12.y after the `alloc` backport lands Fixes: 392e34b6 ("kbuild: rust: remove the `alloc` crate and `GlobalAlloc`") Reviewed-by:
-
