6.12.36-rc1 review
Subsystems (7)
Greg Kroah-Hartman
maintainerPATCH 138/218 net: libwx: fix the creation of page_pool
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiawen Wu <[email protected]>
commit 85720e04d9af0b77f8092b12a06661a8d459d4a0 upstream.
'rx_ring->size' means the count of ring descriptors multiplied by the size of one descriptor. When increasing the count of ring descriptors, it may exceed the limit of pool size.
[ 864.209610] page_pool_create_percpu() gave up with errno -7 [ 864.209613] txgbe 0000:11:00.0: Page pool creation failed: -7
Fix to set the pool_size to the count of ring descriptors.
--- drivers/net/ethernet/wangxun/libwx/wx_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/wangxun/libwx/wx_lib.c +1 -1
@@ -2425,7 +2425,7 @@ static int wx_alloc_page_pool(struct wx_struct page_pool_params pp_params = { .flags =PP_FLAG_DMA_MAP |PP_FLAG_DMA_SYNC_DEV , .order =0 , - .pool_size = rx_ring->size, + .pool_size = rx_ring->count, .nid =dev_to_node (rx_ring->dev), .dev = rx_ring->dev, .dma_dir =DMA_FROM_DEVICE ,
Greg Kroah-Hartman
maintainerPATCH 139/218 maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liam R. Howlett <[email protected]>
commit fba46a5d83ca8decb338722fb4899026d8d9ead2 upstream.
Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through mas_node_count_gfp(), but the allocations will not happen if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations.
The MA_STATE_PREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARN_ON() during consumption.
User visible effect of this flaw is a WARN_ON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmap_region() caused by drivers altering the vma flags (which happens in v6.6, at least)
--- lib/maple_tree.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
lib/maple_tree.c +3 -1
@@ -5542,8 +5542,9 @@ int mas_preallocate(struct ma_state *masmas_wr_store_type (&wr_mas); request =mas_prealloc_calc (mas, entry);if (!request) -return ret; + goto set_flag; + mas->mas_flags &= ~MA_STATE_PREALLOC ;mas_node_count_gfp (mas, request, gfp);if (mas_is_err (mas)) {mas_set_alloc_req (mas,0 );
@@ -5553,6 +5554,7 @@ int mas_preallocate(struct ma_state *masreturn ret; } +set_flag: mas->mas_flags |=MA_STATE_PREALLOC ;return ret; }
Greg Kroah-Hartman
maintainerPATCH 140/218 mm/gup: revert "mm: gup: fix infinite loop within __get_longterm_locked"
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Hildenbrand <[email protected]>
commit 517f496e1e61bd169d585dab4dd77e7147506322 upstream.
After commit 1aaf8c122918 ("mm: gup: fix infinite loop within __get_longterm_locked") we are able to longterm pin folios that are not supposed to get longterm pinned, simply because they temporarily have the LRU flag cleared (esp. temporarily isolated).
For example, two __get_longterm_locked() callers can race, or __get_longterm_locked() can race with anything else that temporarily isolates folios.
The introducing commit mentions the use case of a driver that uses vm_ops->fault to insert pages allocated through cma_alloc() into the page tables, assuming they can later get longterm pinned. These pages/ folios would never have the LRU flag set and consequently cannot get isolated. There is no known in-tree user making use of that so far, fortunately.
To handle that in the future -- and avoid retrying forever to isolate/migrate them -- we will need a different mechanism for the CMA area *owner* to indicate that it actually already allocated the page and is fine with longterm pinning it. The LRU flag is not suitable for that.
Probably we can lookup the relevant CMA area and query the bitmap; we only have have to care about some races, probably. If already allocated, we could just allow longterm pinning)
Anyhow, let's fix the "must not be longterm pinned" problem first by reverting the original commit.
--- mm/gup.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
mm/gup.c +10 -4
@@ -2326,13 +2326,13 @@ static void pofs_unpin(struct pages_or_f/* * Returns the number of collected folios. Return value is always >= 0. */ -static void collect_longterm_unpinnable_folios ( +static unsigned long collect_longterm_unpinnable_folios (struct list_head *movable_folio_list,struct pages_or_folios *pofs) { +unsigned long i, collected =0 ;struct folio *prev_folio =NULL ;bool drain_allow = true; -unsigned long i;for (i =0 ; i < pofs->nr_entries; i++) {struct folio *folio =pofs_get_folio (pofs, i);
@@ -2344,6 +2344,8 @@ static void collect_longterm_unpinnable_if (folio_is_longterm_pinnable (folio))continue ; + collected++; +if (folio_is_device_coherent (folio))continue ;
@@ -2365,6 +2367,8 @@ static void collect_longterm_unpinnable_NR_ISOLATED_ANON +folio_is_file_lru (folio), folio_nr_pages(folio)); } + +return collected; }/*
@@ -2441,9 +2445,11 @@ static long check_and_migrate_movable_pages_or_folios(struct pages_or_folios *pofs) {LIST_HEAD (movable_folio_list); +unsigned long collected; -collect_longterm_unpinnable_folios (&movable_folio_list, pofs); -if (list_empty (&movable_folio_list)) + collected =collect_longterm_unpinnable_folios (&movable_folio_list, + pofs); +if (!collected)return 0 ;return migrate_longterm_unpinnable_folios (&movable_folio_list, pofs);
Greg Kroah-Hartman
maintainerPATCH 141/218 f2fs: fix to zero post-eof page
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
commit ba8dac350faf16afc129ce6303ca4feaf083ccb1 upstream.
fstest reports a f2fs bug:
#generic/363 42s ... [failed, exit status 1]- output mismatch (see /share/git/fstests/results//generic/363.out.bad)
# --- tests/generic/363.out 2025-01-12 21:57:40.271440542 +0800 # +++ /share/git/fstests/results//generic/363.out.bad 2025-05-19 19:55:58.000000000 +0800 # @@ -1,2 +1,78 @@ # QA output created by 363 # fsx -q -S 0 -e 1 -N 100000 # +READ BAD DATA: offset = 0xd6fb, size = 0xf044, fname = /mnt/f2fs/junk # +OFFSET GOOD BAD RANGE # +0x1540d 0x0000 0x2a25 0x0 # +operation# (mod 256) for the bad data may be 37 # +0x1540e 0x0000 0x2527 0x1 # ... # (Run 'diff -u /share/git/fstests/tests/generic/363.out /share/git/fstests/results//generic/363.out.bad' to see the entire diff)
Ran: generic/363
Failures: generic/363
Failed 1 of 1 tests
The root cause is user can update post-eof page via mmap [1], however, f2fs missed to zero post-eof page in below operations, so, once it expands i_size, then it will include dummy data locates previous post-eof page, so during below operations, we need to zero post-eof page.
Operations which can include dummy data after previous i_size after expanding i_size:
- write
- mapwrite [1]
- truncate
- fallocate
* preallocate
* zero_range
* insert_range
* collapse_range
- clone_range (doesn’t support in f2fs)
- copy_range (doesn’t support in f2fs)
[1] https://man7.org/linux/man-pages/man2/mmap.2.html 'BUG section'
--- fs/f2fs/file.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)
fs/f2fs/file.c +38 -0
@@ -35,6 +35,17 @@#include <trace/events/f2fs.h> #include <uapi/linux/f2fs.h> +static void f2fs_zero_post_eof_page (struct inode *inode,loff_t new_size) +{ +loff_t old_size =i_size_read (inode); + +if (old_size >= new_size) +return ; + +/* zero or drop pages only in range of [old_size, new_size] */ +truncate_pagecache (inode, old_size); +} +static vm_fault_t f2fs_filemap_fault (struct vm_fault *vmf) {struct inode *inode =file_inode (vmf->vma->vm_file);
@@ -103,8 +114,13 @@ static vm_fault_t f2fs_vm_page_mkwrite(sf2fs_bug_on (sbi,f2fs_has_inline_data (inode)); +filemap_invalidate_lock (inode->i_mapping); +f2fs_zero_post_eof_page (inode, (folio->index +1 ) <<PAGE_SHIFT ); +filemap_invalidate_unlock (inode->i_mapping); +file_update_time (vmf->vma->vm_file);filemap_invalidate_lock_shared (inode->i_mapping); +folio_lock (folio); if (unlikely(folio->mapping != inode->i_mapping || folio_pos(folio) > i_size_read(inode) ||
@@ -1064,6 +1080,8 @@ int f2fs_setattr(struct mnt_idmap *idmapf2fs_down_write (&fi->i_gc_rwsem[WRITE ]);filemap_invalidate_lock (inode->i_mapping); +if (attr->ia_size > old_size) +f2fs_zero_post_eof_page (inode, attr->ia_size);truncate_setsize (inode, attr->ia_size);if (attr->ia_size <= old_size)
@@ -1182,6 +1200,10 @@ static int f2fs_punch_hole(struct inodeif (ret)return ret; +filemap_invalidate_lock (inode->i_mapping); +f2fs_zero_post_eof_page (inode, offset + len); +filemap_invalidate_unlock (inode->i_mapping); + pg_start = ((unsigned long long ) offset) >>PAGE_SHIFT ; pg_end = ((unsigned long long ) offset + len) >>PAGE_SHIFT ;
@@ -1465,6 +1487,8 @@ static int f2fs_do_collapse(struct inodef2fs_down_write (&F2FS_I (inode)->i_gc_rwsem[WRITE ]);filemap_invalidate_lock (inode->i_mapping); +f2fs_zero_post_eof_page (inode, offset + len); +f2fs_lock_op (sbi);f2fs_drop_extent_tree (inode);truncate_pagecache (inode, offset);
@@ -1586,6 +1610,10 @@ static int f2fs_zero_range(struct inodeif (ret)return ret; +filemap_invalidate_lock (mapping); +f2fs_zero_post_eof_page (inode, offset + len); +filemap_invalidate_unlock (mapping); + pg_start = ((unsigned long long ) offset) >>PAGE_SHIFT ; pg_end = ((unsigned long long ) offset + len) >>PAGE_SHIFT ;
@@ -1717,6 +1745,8 @@ static int f2fs_insert_range(struct inod/* avoid gc operation during block exchange */ f2fs_down_write (&F2FS_I (inode)->i_gc_rwsem[WRITE ]);filemap_invalidate_lock (mapping); + +f2fs_zero_post_eof_page (inode, offset + len);truncate_pagecache (inode, offset);while (!ret && idx > pg_start) {
@@ -1774,6 +1804,10 @@ static int f2fs_expand_inode_data(structif (err)return err; +filemap_invalidate_lock (inode->i_mapping); +f2fs_zero_post_eof_page (inode, offset + len); +filemap_invalidate_unlock (inode->i_mapping); +f2fs_balance_fs (sbi, true); pg_start = ((unsigned long long )offset) >>PAGE_SHIFT ;
@@ -4715,6 +4749,10 @@ static ssize_t f2fs_write_checks(struct err =file_modified (file);if (err)return err; + +filemap_invalidate_lock (inode->i_mapping); +f2fs_zero_post_eof_page (inode, iocb->ki_pos +iov_iter_count (from)); +filemap_invalidate_unlock (inode->i_mapping);return count; }
Greg Kroah-Hartman
maintainerPATCH 142/218 HID: lenovo: Restrict F7/9/11 mode to compact keyboards only
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Iusico Maxim <[email protected]>
commit 9327e3ee5b077c4ab4495a09b67624f670ed88b6 upstream.
Commit 2f2bd7cbd1d1 ("hid: lenovo: Resend all settings on reset_resume for compact keyboards") introduced a regression for ThinkPad TrackPoint Keyboard II by removing the conditional check for enabling F7/9/11 mode needed for compact keyboards only. As a result, the non-compact keyboards can no longer toggle Fn-lock via Fn+Esc, although it can be controlled via sysfs knob that directly sends raw commands.
This patch restores the previous conditional check without any additions.
--- drivers/hid/hid-lenovo.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/hid/hid-lenovo.c +7 -4
@@ -529,11 +529,14 @@ static void lenovo_features_set_cptkbd(s/* * Tell the keyboard a driver understands it, and turn F7, F9, F11 into -* regular keys +* regular keys (Compact only) */ - ret =lenovo_send_cmd_cptkbd (hdev,0x01 ,0x03 ); -if (ret) -hid_warn (hdev,"Failed to switch F7/9/11 mode: %d\n" , ret); +if (hdev->product ==USB_DEVICE_ID_LENOVO_CUSBKBD || + hdev->product ==USB_DEVICE_ID_LENOVO_CBTKBD ) { + ret =lenovo_send_cmd_cptkbd (hdev,0x01 ,0x03 ); +if (ret) +hid_warn (hdev,"Failed to switch F7/9/11 mode: %d\n" , ret); + }/* Switch middle button to native mode */ ret =lenovo_send_cmd_cptkbd (hdev,0x09 ,0x01 );
Greg Kroah-Hartman
maintainerPATCH 143/218 HID: wacom: fix memory leak on kobject creation failure
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qasim Ijaz <[email protected]>
commit 5ae416c5b1e2e816aee7b3fc8347adf70afabb4c upstream.
During wacom_initialize_remotes() a fifo buffer is allocated with kfifo_alloc() and later a cleanup action is registered during devm_add_action_or_reset() to clean it up.
However if the code fails to create a kobject and register it with sysfs the code simply returns -ENOMEM before the cleanup action is registered leading to a memory leak.
Fix this by ensuring the fifo is freed when the kobject creation and registration process fails.
--- drivers/hid/wacom_sys.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/hid/wacom_sys.c +3 -1
@@ -2021,8 +2021,10 @@ static int wacom_initialize_remotes(stru remote->remote_dir =kobject_create_and_add ("wacom_remote" , &wacom->hdev->dev.kobj); -if (!remote->remote_dir) +if (!remote->remote_dir) { +kfifo_free (&remote->remote_fifo);return -ENOMEM ; + } error =sysfs_create_files (remote->remote_dir, remote_unpair_attrs);
Greg Kroah-Hartman
maintainerPATCH 144/218 HID: wacom: fix memory leak on sysfs attribute creation failure
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qasim Ijaz <[email protected]>
commit 1a19ae437ca5d5c7d9ec2678946fb339b1c706bf upstream.
When sysfs_create_files() fails during wacom_initialize_remotes() the fifo buffer is not freed leading to a memory leak.
Fix this by calling kfifo_free() before returning.
--- drivers/hid/wacom_sys.c | 1 + 1 file changed, 1 insertion(+)
drivers/hid/wacom_sys.c +1 -0
@@ -2031,6 +2031,7 @@ static int wacom_initialize_remotes(struif (error) {hid_err (wacom->hdev,"cannot create sysfs group err: %d\n" , error); +kfifo_free (&remote->remote_fifo);return error; }
Greg Kroah-Hartman
maintainerPATCH 145/218 HID: wacom: fix kobject reference count leak
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qasim Ijaz <[email protected]>
commit 85a720f4337f0ddf1603c8b75a8f1ffbbe022ef9 upstream.
When sysfs_create_files() fails in wacom_initialize_remotes() the error is returned and the cleanup action will not have been registered yet.
As a result the kobject???s refcount is never dropped, so the kobject can never be freed leading to a reference leak.
Fix this by calling kobject_put() before returning.
--- drivers/hid/wacom_sys.c | 1 + 1 file changed, 1 insertion(+)
drivers/hid/wacom_sys.c +1 -0
@@ -2032,6 +2032,7 @@ static int wacom_initialize_remotes(struhid_err (wacom->hdev,"cannot create sysfs group err: %d\n" , error);kfifo_free (&remote->remote_fifo); +kobject_put (remote->remote_dir);return error; }
Greg Kroah-Hartman
maintainerPATCH 146/218 scsi: megaraid_sas: Fix invalid node index
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Yu <[email protected]>
commit 752eb816b55adb0673727ba0ed96609a17895654 upstream.
On a system with DRAM interleave enabled, out-of-bound access is detected:
megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0
------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fix it accordingly.
--- drivers/scsi/megaraid/megaraid_sas_base.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/scsi/megaraid/megaraid_sas_base.c +5 -1
@@ -5910,7 +5910,11 @@ megasas_set_high_iops_queue_affinity_andconst struct cpumask *mask;if (instance->perf_mode ==MR_BALANCED_PERF_MODE ) { - mask =cpumask_of_node (dev_to_node (&instance->pdev->dev)); +int nid =dev_to_node (&instance->pdev->dev); + +if (nid ==NUMA_NO_NODE ) + nid =0 ; + mask =cpumask_of_node (nid);for (i =0 ; i < instance->low_latency_index_start; i++) { irq =pci_irq_vector (instance->pdev, i);
Greg Kroah-Hartman
maintainerPATCH 147/218 scsi: ufs: core: Fix clk scaling to be conditional in reset and restore
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: anvithdosapati <[email protected]>
commit 2e083cd802294693a5414e4557a183dd7e442e71 upstream.
In ufshcd_host_reset_and_restore(), scale up clocks only when clock scaling is supported. Without this change CPU latency is voted for 0 (ufshcd_pm_qos_update) during resume unconditionally.
--- drivers/ufs/core/ufshcd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/ufs/core/ufshcd.c +2 -1
@@ -7743,7 +7743,8 @@ static int ufshcd_host_reset_and_restore hba->silence_err_logs = false;/* scale up clocks to max frequency before full reinitialization */ -ufshcd_scale_clks (hba,ULONG_MAX , true); +if (ufshcd_is_clkscaling_supported (hba)) +ufshcd_scale_clks (hba,ULONG_MAX , true); err =ufshcd_hba_enable (hba);
Greg Kroah-Hartman
maintainerPATCH 148/218 drm/ast: Fix comment on modeset lock
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit 7cce65f3789e04c0f7668a66563e680d81d54493 upstream.
The ast driver protects the commit tail against concurrent reads of the display modes by acquiring a lock. The comment is misleading as the lock is not released in atomic_flush, but at the end of the commit-tail helper. Rewrite the comment.
--- drivers/gpu/drm/ast/ast_mode.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/ast/ast_mode.c +3 -3
@@ -1319,9 +1319,9 @@ static void ast_mode_config_helper_atomi/* * Concurrent operations could possibly trigger a call to -* drm_connector_helper_funcs.get_modes by trying to read the -* display modes. Protect access to I/O registers by acquiring -* the I/O-register lock. Released in atomic_flush(). +* drm_connector_helper_funcs.get_modes by reading the display +* modes. Protect access to registers by acquiring the modeset +* lock. */ mutex_lock (&ast->modeset_lock);drm_atomic_helper_commit_tail (state);
Greg Kroah-Hartman
maintainerPATCH 149/218 drm/cirrus-qemu: Fix pitch programming
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit 4bfb389a0136a13f0802eeb5e97a0e76d88f77ae upstream.
Do not set CR1B[6] when programming the pitch. The bit effects VGA text mode and is not interpreted by qemu. [1] It has no affect on the scanline pitch.
The scanline bit that is set into CR1B[6] belongs into CR13[7], which the driver sets up correctly.
This bug goes back to the driver's initial commit.
--- drivers/gpu/drm/tiny/cirrus.c | 1 - 1 file changed, 1 deletion(-)
drivers/gpu/drm/tiny/cirrus.c +0 -1
@@ -318,7 +318,6 @@ static void cirrus_pitch_set(struct cirr/* Enable extended blanking and pitch bits, and enable full memory */ cr1b =0x22 ; cr1b |= (pitch >>7 ) &0x10 ; - cr1b |= (pitch >>6 ) &0x40 ;wreg_crt (cirrus,0x1b , cr1b);cirrus_set_start_address (cirrus,0 );
Greg Kroah-Hartman
maintainerPATCH 150/218 drm/etnaviv: Protect the schedulers pending list with its lock
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maíra Canal <[email protected]>
commit 61ee19dedb8d753249e20308782bf4e9e2fb7344 upstream.
Commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active") ensured that active jobs are returned to the pending list when extending the timeout. However, it didn't use the pending list's lock to manipulate the list, which causes a race condition as the scheduler's workqueues are running.
Hold the lock while manipulating the scheduler's pending list to prevent a race.
--- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/gpu/drm/etnaviv/etnaviv_sched.c +4 -1
@@ -34,6 +34,7 @@ static enum drm_gpu_sched_stat etnaviv_s *sched_job) {struct etnaviv_gem_submit *submit =to_etnaviv_submit (sched_job); +struct drm_gpu_scheduler *sched = sched_job->sched;struct etnaviv_gpu *gpu = submit->gpu;u32 dma_addr;int change;
@@ -76,7 +77,9 @@ static enum drm_gpu_sched_stat etnaviv_sreturn DRM_GPU_SCHED_STAT_NOMINAL ; out_no_timeout: -list_add (&sched_job->list, &sched_job->sched->pending_list); +spin_lock (&sched->job_list_lock); +list_add (&sched_job->list, &sched->pending_list); +spin_unlock (&sched->job_list_lock);return DRM_GPU_SCHED_STAT_NOMINAL ; }
Greg Kroah-Hartman
maintainerPATCH 151/218 drm/tegra: Assign plane type before registration
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thierry Reding <[email protected]>
commit 9ff4fdf4f44b69237c0afc1d3a8dac916ce66f3e upstream.
Changes to a plane's type after it has been registered aren't propagated to userspace automatically. This could possibly be achieved by updating the property, but since we can already determine which type this should be before the registration, passing in the right type from the start is a much better solution.
--- drivers/gpu/drm/tegra/dc.c | 12 ++++++++---- drivers/gpu/drm/tegra/hub.c | 4 ++-- drivers/gpu/drm/tegra/hub.h | 3 ++- 3 files changed, 12 insertions(+), 7 deletions(-)
drivers/gpu/drm/tegra/dc.c +8 -4
@@ -1320,10 +1320,16 @@ static struct drm_plane *tegra_dc_add_shif (wgrp->dc == dc->pipe) {for (j =0 ; j < wgrp->num_windows; j++) {unsigned int index = wgrp->windows[j]; +enum drm_plane_type type; + +if (primary) + type =DRM_PLANE_TYPE_OVERLAY ; +else + type =DRM_PLANE_TYPE_PRIMARY ; plane =tegra_shared_plane_create (drm, dc, wgrp->index, - index); + index, type);if (IS_ERR (plane))return plane;
@@ -1331,10 +1337,8 @@ static struct drm_plane *tegra_dc_add_sh* Choose the first shared plane owned by this * head as the primary plane. */ -if (!primary) { - plane->type =DRM_PLANE_TYPE_PRIMARY ; +if (!primary) primary = plane; - } } } }
drivers/gpu/drm/tegra/hub.c +2 -2
@@ -755,9 +755,9 @@ static const struct drm_plane_helper_funstruct drm_plane *tegra_shared_plane_create (struct drm_device *drm,struct tegra_dc *dc,unsigned int wgrp, -unsigned int index) +unsigned int index, +enum drm_plane_type type) { -enum drm_plane_type type =DRM_PLANE_TYPE_OVERLAY ;struct tegra_drm *tegra = drm->dev_private;struct tegra_display_hub *hub = tegra->hub;struct tegra_shared_plane *plane;
drivers/gpu/drm/tegra/hub.h +2 -1
@@ -80,7 +80,8 @@ void tegra_display_hub_cleanup(struct testruct drm_plane *tegra_shared_plane_create (struct drm_device *drm,struct tegra_dc *dc,unsigned int wgrp, -unsigned int index); +unsigned int index, +enum drm_plane_type type);int tegra_display_hub_atomic_check (struct drm_device *drm,struct drm_atomic_state *state);
Greg Kroah-Hartman
maintainerPATCH 152/218 drm/tegra: Fix a possible null pointer dereference
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qiu-ji Chen <[email protected]>
commit 780351a5f61416ed2ba1199cc57e4a076fca644d upstream.
In tegra_crtc_reset(), new memory is allocated with kzalloc(), but no check is performed. Before calling __drm_atomic_helper_crtc_reset, state should be checked to prevent possible null pointer dereference.
--- drivers/gpu/drm/tegra/dc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/gpu/drm/tegra/dc.c +4 -1
@@ -1392,7 +1392,10 @@ static void tegra_crtc_reset(struct drm_if (crtc->state)tegra_crtc_atomic_destroy_state (crtc, crtc->state); -__drm_atomic_helper_crtc_reset (crtc, &state->base); +if (state) +__drm_atomic_helper_crtc_reset (crtc, &state->base); +else +__drm_atomic_helper_crtc_reset (crtc,NULL ); } static struct drm_crtc_state *
Greg Kroah-Hartman
maintainerPATCH 153/218 drm/udl: Unregister device before cleaning up on disconnect
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit ff9cb6d2035c586ea7c8f1754d4409eec7a2d26d upstream.
Disconnecting a DisplayLink device results in the following kernel error messages
[ 93.041748] [drm:udl_urb_completion [udl]] *ERROR* udl_urb_completion - nonzero write bulk status received: -115 [ 93.055299] [drm:udl_submit_urb [udl]] *ERROR* usb_submit_urb error fffffffe [ 93.065363] [drm:udl_urb_completion [udl]] *ERROR* udl_urb_completion - nonzero write bulk status received: -115 [ 93.078207] [drm:udl_submit_urb [udl]] *ERROR* usb_submit_urb error fffffffe
coming from KMS poll helpers. Shutting down poll helpers runs them one final time when the USB device is already gone.
Run drm_dev_unplug() first in udl's USB disconnect handler. Udl's polling code already handles disconnects gracefully if the device has been marked as unplugged.
--- drivers/gpu/drm/udl/udl_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/udl/udl_drv.c +1 -1
@@ -126,9 +126,9 @@ static void udl_usb_disconnect(struct us {struct drm_device *dev =usb_get_intfdata (interface); +drm_dev_unplug (dev);drm_kms_helper_poll_fini (dev);udl_drop_usb (dev); -drm_dev_unplug (dev); }/*
Greg Kroah-Hartman
maintainerPATCH 154/218 drm/msm/gpu: Fix crash when throttling GPU immediately during boot
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephan Gerhold <[email protected]>
commit b71717735be48d7743a34897e9e44a0b53e30c0e upstream.
There is a small chance that the GPU is already hot during boot. In that case, the call to of_devfreq_cooling_register() will immediately try to apply devfreq cooling, as seen in the following crash:
Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ...
At this point we haven't initialized the GMU at all yet, so we cannot read the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag accordingly. This means the df->suspended flag does not match the actual devfreq state after initialization and msm_devfreq_get_dev_status() will end up accessing GMU registers, causing the crash.
Fix this by setting df->suspended correctly during initialization.
Patchwork: https://patchwork.freedesktop.org/patch/650772/
--- drivers/gpu/drm/msm/msm_gpu_devfreq.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/msm/msm_gpu_devfreq.c +1 -0
@@ -156,6 +156,7 @@ void msm_devfreq_init(struct msm_gpu *gp priv->gpu_devfreq_config.downdifferential =10 ;mutex_init (&df->lock); + df->suspended = true; ret =dev_pm_qos_add_request (&gpu->pdev->dev, &df->boost_freq,DEV_PM_QOS_MIN_FREQUENCY ,0 );
Greg Kroah-Hartman
maintainerPATCH 155/218 drm/amdkfd: Fix race in GWS queue scheduling
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jay Cornwall <[email protected]>
commit cfb05257ae168a0496c7637e1d9e3ab8a25cbffe upstream.
q->gws is not updated atomically with qpd->mapped_gws_queue. If a runlist is created between pqm_set_gws and update_queue it will contain a queue which uses GWS in a process with no GWS allocated. This will result in a scheduler hang.
Use q->properties.is_gws which is changed while holding the DQM lock.
--- drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c +1 -1
@@ -237,7 +237,7 @@ static int pm_map_queues_v9(struct packe packet->bitfields2.engine_sel = engine_sel__mes_map_queues__compute_vi; - packet->bitfields2.gws_control_queue = q->gws ?1 :0 ; + packet->bitfields2.gws_control_queue = q->properties.is_gws ?1 :0 ; packet->bitfields2.extended_engine_sel = extended_engine_sel__mes_map_queues__legacy_engine_sel; packet->bitfields2.queue_type =
Greg Kroah-Hartman
maintainerPATCH 156/218 drm/bridge: cdns-dsi: Fix the clock variable for mode_valid()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aradhya Bhatia <[email protected]>
commit 132bdcec399be6ae947582249a134b38cf56731c upstream.
The crtc_* mode parameters do not get generated (duplicated in this case) from the regular parameters before the mode validation phase begins.
The rest of the code conditionally uses the crtc_* parameters only during the bridge enable phase, but sticks to the regular parameters for mode validation. In this singular instance, however, the driver tries to use the crtc_clock parameter even during the mode validation, causing the validation to fail.
Allow the D-Phy config checks to use mode->clock instead of mode->crtc_clock during mode_valid checks, like everywhere else in the driver.
--- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +2 -1
@@ -568,13 +568,14 @@ static int cdns_dsi_check_conf(struct cdstruct phy_configure_opts_mipi_dphy *phy_cfg = &output->phy_opts.mipi_dphy;unsigned long dsi_hss_hsa_hse_hbp;unsigned int nlanes = output->dev->lanes; +int mode_clock = (mode_valid_check ? mode->clock : mode->crtc_clock);int ret; ret =cdns_dsi_mode2cfg (dsi, mode, dsi_cfg, mode_valid_check);if (ret)return ret; -phy_mipi_dphy_get_default_config (mode->crtc_clock *1000 , +phy_mipi_dphy_get_default_config (mode_clock *1000 ,mipi_dsi_pixel_format_to_bpp (output->dev->format), nlanes, phy_cfg);
Greg Kroah-Hartman
maintainerPATCH 157/218 drm/bridge: cdns-dsi: Fix phy de-init and flag it so
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aradhya Bhatia <[email protected]>
commit fd2611c13f69cbbc6b81d9fc7502abf4f7031d21 upstream.
The driver code doesn't have a Phy de-initialization path as yet, and so it does not clear the phy_initialized flag while suspending. This is a problem because after resume the driver looks at this flag to determine if a Phy re-initialization is required or not. It is in fact required because the hardware is resuming from a suspend, but the driver does not carry out any re-initialization causing the D-Phy to not work at all.
Call the counterparts of phy_init() and phy_power_on(), that are phy_exit() and phy_power_off(), from _bridge_post_disable(), and clear the flags so that the Phy can be initialized again when required.
--- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +5 -1
@@ -681,6 +681,11 @@ static void cdns_dsi_bridge_post_disablestruct cdns_dsi_input *input =bridge_to_cdns_dsi_input (bridge);struct cdns_dsi *dsi =input_to_dsi (input); + dsi->phy_initialized = false; + dsi->link_initialized = false; +phy_power_off (dsi->dphy); +phy_exit (dsi->dphy); +pm_runtime_put (dsi->base.dev); }
@@ -1153,7 +1158,6 @@ static int __maybe_unused cdns_dsi_suspeclk_disable_unprepare (dsi->dsi_sys_clk);clk_disable_unprepare (dsi->dsi_p_clk);reset_control_assert (dsi->dsi_p_rst); - dsi->link_initialized = false;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 158/218 drm/bridge: cdns-dsi: Fix connecting to next bridge
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aradhya Bhatia <[email protected]>
commit 688eb4d465484bc2a3471a6a6f06f833b58c7867 upstream.
Fix the OF node pointer passed to the of_drm_find_bridge() call to find the next bridge in the display chain.
The code to find the next panel (and create its panel-bridge) works fine, but to find the next (non-panel) bridge does not.
To find the next bridge in the pipeline, we need to pass "np" - the OF node pointer of the next entity in the devicetree chain. Passing "of_node" to of_drm_find_bridge (which is what the code does currently) will fetch the bridge for the cdns-dsi which is not what's required.
Fix that.
--- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +1 -1
@@ -958,7 +958,7 @@ static int cdns_dsi_attach(struct mipi_d bridge =drm_panel_bridge_add_typed (panel,DRM_MODE_CONNECTOR_DSI ); }else { - bridge =of_drm_find_bridge (dev->dev.of_node); + bridge =of_drm_find_bridge (np);if (!bridge) bridge =ERR_PTR (-EINVAL ); }
Greg Kroah-Hartman
maintainerPATCH 159/218 drm/bridge: cdns-dsi: Check return value when getting default PHY config
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aradhya Bhatia <[email protected]>
commit c6a7ef0d4856b9629df390e9935d7fd67fe39f81 upstream.
Check for the return value of the phy_mipi_dphy_get_default_config() call, and in case of an error, return back the same.
--- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +5 -3
@@ -575,9 +575,11 @@ static int cdns_dsi_check_conf(struct cdif (ret)return ret; -phy_mipi_dphy_get_default_config (mode_clock *1000 , -mipi_dsi_pixel_format_to_bpp (output->dev->format), - nlanes, phy_cfg); + ret =phy_mipi_dphy_get_default_config (mode_clock *1000 , +mipi_dsi_pixel_format_to_bpp (output->dev->format), + nlanes, phy_cfg); +if (ret) +return ret; ret =cdns_dsi_adjust_phy_config (dsi, dsi_cfg, phy_cfg, mode, mode_valid_check);if (ret)
Greg Kroah-Hartman
maintainerPATCH 160/218 drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aradhya Bhatia <[email protected]>
commit 47c03e6660e96cbba0239125b1d4a9db3c724b1d upstream.
Once the DSI Link and DSI Phy are initialized, the code needs to wait for Clk and Data Lanes to be ready, before continuing configuration. This is in accordance with the DSI Start-up procedure, found in the Technical Reference Manual of Texas Instrument's J721E SoC[0] which houses this DSI TX controller.
If the previous bridge (or crtc/encoder) are configured pre-maturely, the input signal FIFO gets corrupt. This introduces a color-shift on the display.
Allow the driver to wait for the clk and data lanes to get ready during DSI enable.
[0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM
TRM Link: http://www.ti.com/lit/pdf/spruil1
--- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +14 -1
@@ -769,7 +769,7 @@ static void cdns_dsi_bridge_enable(strucstruct phy_configure_opts_mipi_dphy *phy_cfg = &output->phy_opts.mipi_dphy;unsigned long tx_byte_period;struct cdns_dsi_cfg dsi_cfg; -u32 tmp, reg_wakeup, div; +u32 tmp, reg_wakeup, div, status;int nlanes;if (WARN_ON (pm_runtime_get_sync (dsi->base.dev) <0 ))
@@ -786,6 +786,19 @@ static void cdns_dsi_bridge_enable(struccdns_dsi_hs_init (dsi);cdns_dsi_init_link (dsi); +/* +* Now that the DSI Link and DSI Phy are initialized, +* wait for the CLK and Data Lanes to be ready. +*/ + tmp =CLK_LANE_RDY ; +for (int i =0 ; i < nlanes; i++) + tmp |=DATA_LANE_RDY (i); + +if (readl_poll_timeout (dsi->regs +MCTL_MAIN_STS , status, + (tmp == (status & tmp)),100 ,500000 )) +dev_err (dsi->base.dev, +"Timed Out: DSI-DPhy Clock and Data Lanes not ready.\n" ); +writel (HBP_LEN (dsi_cfg.hbp) |HSA_LEN (dsi_cfg.hsa), dsi->regs +VID_HSIZE1 ); writel(HFP_LEN(dsi_cfg.hfp) | HACT_LEN(dsi_cfg.hact),
Greg Kroah-Hartman
maintainerPATCH 161/218 drm/amd/display: Add null pointer check for get_first_active_display()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wentao Liang <[email protected]>
commit c3e9826a22027a21d998d3e64882fa377b613006 upstream.
The function mod_hdcp_hdcp1_enable_encryption() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference in mod_hdcp_hdcp2_enable_encryption().
Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.
--- drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c +3 -0
@@ -368,6 +368,9 @@ enum mod_hdcp_status mod_hdcp_hdcp1_enabstruct mod_hdcp_display *display =get_first_active_display (hdcp);enum mod_hdcp_status status =MOD_HDCP_STATUS_SUCCESS ; +if (!display) +return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND ; +mutex_lock (&psp->hdcp_context.mutex); hdcp_cmd = (struct ta_hdcp_shared_memory *)psp->hdcp_context.context.mem_context.shared_buf;memset (hdcp_cmd,0 ,sizeof (struct ta_hdcp_shared_memory ));
Greg Kroah-Hartman
maintainerPATCH 162/218 drm/amdgpu: amdgpu_vram_mgr_new(): Clamp lpfn to total vram
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Olender <[email protected]>
commit 4d2f6b4e4c7ed32e7fa39fcea37344a9eab99094 upstream.
The drm_mm allocator tolerated being passed end > mm->size, but the drm_buddy allocator does not.
Restore the pre-buddy-allocator behavior of allowing such placements.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c +1 -1
@@ -463,7 +463,7 @@ static int amdgpu_vram_mgr_new(struct ttint r; lpfn = (u64 )place->lpfn <<PAGE_SHIFT ; -if (!lpfn) +if (!lpfn || lpfn > man->size) lpfn = man->size; fpfn = (u64 )place->fpfn <<PAGE_SHIFT ;
Greg Kroah-Hartman
maintainerPATCH 163/218 drm/amd/display: Correct non-OLED pre_T11_delay.
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhongwei Zhang <[email protected]>
commit 893f07452bca56ff146a6be02b3294a9ea23d18a upstream.
[Why]
Only OLED panels require non-zero pre_T11_delay defaultly. Others should be controlled by power sequence.
[How]
For non OLED, pre_T11_delay delay in code should be zero. Also post_T7_delay.
--- drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c +4 -3
@@ -951,8 +951,8 @@ void dce110_edp_backlight_control(struct dc_context *ctx = link->ctx;struct bp_transmitter_control cntl = {0 };uint8_t pwrseq_instance =0 ; -unsigned int pre_T11_delay =OLED_PRE_T11_DELAY ; -unsigned int post_T7_delay =OLED_POST_T7_DELAY ; +unsigned int pre_T11_delay = (link->dpcd_sink_ext_caps.bits.oled ?OLED_PRE_T11_DELAY :0 ); +unsigned int post_T7_delay = (link->dpcd_sink_ext_caps.bits.oled ?OLED_POST_T7_DELAY :0 );if (dal_graphics_object_id_get_connector_id (link->link_enc->connector) !=CONNECTOR_ID_EDP ) {
@@ -1067,7 +1067,8 @@ void dce110_edp_backlight_control(if (!enable) {/*follow oem panel config's requirement*/ pre_T11_delay += link->panel_config.pps.extra_pre_t11_ms; -msleep (pre_T11_delay); +if (pre_T11_delay) +msleep (pre_T11_delay); } }
Greg Kroah-Hartman
maintainerPATCH 164/218 drm/xe/vm: move rebind_work init earlier
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Auld <[email protected]>
commit a63e99b4d6d3a0353ef47146dd5bd562f08e1786 upstream.
In xe_vm_close_and_put() we need to be able to call flush_work(rebind_work), however during vm creation we can call this on the error path, before having actually set up the worker, leading to a splat from flush_work().
It looks like we can simply move the worker init step earlier to fix this.
--- drivers/gpu/drm/xe/xe_vm.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/gpu/drm/xe/xe_vm.c +4 -4
@@ -1477,8 +1477,10 @@ struct xe_vm *xe_vm_create(struct xe_dev* scheduler drops all the references of it, hence protecting the VM * for this case is necessary. */ -if (flags &XE_VM_FLAG_LR_MODE ) +if (flags &XE_VM_FLAG_LR_MODE ) { +INIT_WORK (&vm->preempt.rebind_work, preempt_rebind_work_func);xe_pm_runtime_get_noresume (xe); + } vm_resv_obj =drm_gpuvm_resv_object_alloc (&xe->drm);if (!vm_resv_obj) {
@@ -1523,10 +1525,8 @@ struct xe_vm *xe_vm_create(struct xe_dev vm->batch_invalidate_tlb = true; } -if (vm->flags &XE_VM_FLAG_LR_MODE ) { -INIT_WORK (&vm->preempt.rebind_work, preempt_rebind_work_func); +if (vm->flags &XE_VM_FLAG_LR_MODE ) vm->batch_invalidate_tlb = false; - }/* Fill pt_root after allocating scratch tables */ for_each_tile (tile, xe, id) {
Greg Kroah-Hartman
maintainerPATCH 165/218 drm/xe/sched: stop re-submitting signalled jobs
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Auld <[email protected]>
commit 0ee54d5cacc0276ec631ac149825a24b59c51c38 upstream.
Customer is reporting a really subtle issue where we get random DMAR faults, hangs and other nasties for kernel migration jobs when stressing stuff like s2idle/s3/s4. The explosions seems to happen somewhere after resuming the system with splats looking something like:
PM: suspend exit
rfkill: input handler disabled
xe 0000:00:02.0: [drm] GT0: Engine reset: engine_class=bcs, logical_mask: 0x2, guc_id=0
xe 0000:00:02.0: [drm] GT0: Timedout job: seqno=24496, lrc_seqno=24496, guc_id=0, flags=0x13 in no process [-1] xe 0000:00:02.0: [drm] GT0: Kernel-submitted job timed out
The likely cause appears to be a race between suspend cancelling the worker that processes the free_job()'s, such that we still have pending jobs to be freed after the cancel. Following from this, on resume the pending_list will now contain at least one already complete job, but it looks like we call drm_sched_resubmit_jobs(), which will then call run_job() on everything still on the pending_list. But if the job was already complete, then all the resources tied to the job, like the bb itself, any memory that is being accessed, the iommu mappings etc. might be long gone since those are usually tied to the fence signalling.
This scenario can be seen in ftrace when running a slightly modified xe_pm IGT (kernel was only modified to inject artificial latency into free_job to make the race easier to hit):
xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ... xe_exec_queue_stop: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13 xe_exec_queue_stop: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=1, guc_state=0x0, flags=0x4 xe_exec_queue_stop: dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=0, guc_state=0x0, flags=0x3 xe_exec_queue_stop: dev=0000:00:02.0, 1:0x1, gt=1, width=1, guc_id=1, guc_state=0x0, flags=0x3 xe_exec_queue_stop: dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=2, guc_state=0x0, flags=0x3 xe_exec_queue_resubmit: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13 xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ...
.....xe_exec_queue_memory_cat_error: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x3, flags=0x13
So the job_run() is clearly triggered twice for the same job, even though the first must have already signalled to completion during suspend. We can also see a CAT error after the re-submit.
To prevent this only resubmit jobs on the pending_list that have not yet signalled.
v2:
- Make sure to re-arm the fence callbacks with sched_start().
v3 (Matt B):
- Stop using drm_sched_resubmit_jobs(), which appears to be deprecated and just open-code a simple loop such that we skip calling run_job() on anything already signalled.
--- drivers/gpu/drm/xe/xe_gpu_scheduler.h | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/gpu/drm/xe/xe_gpu_scheduler.h +9 -1
@@ -51,7 +51,15 @@ static inline void xe_sched_tdr_queue_imstatic inline void xe_sched_resubmit_jobs (struct xe_gpu_scheduler *sched) { -drm_sched_resubmit_jobs (&sched->base); +struct drm_sched_job *s_job; + +list_for_each_entry (s_job, &sched->base.pending_list, list) { +struct drm_sched_fence *s_fence = s_job->s_fence; +struct dma_fence *hw_fence = s_fence->parent; + +if (hw_fence && !dma_fence_is_signaled (hw_fence)) + sched->base.ops->run_job (s_job); + } } static inline bool
Greg Kroah-Hartman
maintainerPATCH 166/218 drm/xe/guc_submit: add back fix
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Auld <[email protected]>
commit 2e824747cfbdf1fba88df5e5800d284b2602ae8f upstream.
Daniele noticed that the fix in commit 2d2be279f1ca ("drm/xe: fix UAF around queue destruction") looks to have been unintentionally removed as part of handling a conflict in some past merge commit. Add it back.
--- drivers/gpu/drm/xe/xe_guc_submit.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/gpu/drm/xe/xe_guc_submit.c +11 -0
@@ -227,6 +227,17 @@ static bool exec_queue_killed_or_banned_static void guc_submit_fini (struct drm_device *drm,void *arg) {struct xe_guc *guc = arg; +struct xe_device *xe =guc_to_xe (guc); +struct xe_gt *gt =guc_to_gt (guc); +int ret; + + ret =wait_event_timeout (guc->submission_state.fini_wq, +xa_empty (&guc->submission_state.exec_queue_lookup), +HZ *5 ); + +drain_workqueue (xe->destroy_wq); + +xe_gt_assert (gt, ret);xa_destroy (&guc->submission_state.exec_queue_lookup); }
Greg Kroah-Hartman
maintainerPATCH 167/218 drm/amd/display: Fix RMCM programming seq errors
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yihan Zhu <[email protected]>
commit 158f9944ac05dafd2d3a23d0688e6cf40ef68b90 upstream.
[WHY & HOW]
Fix RMCM programming sequence errors and mapping issues to pass the RMCM test.
--- drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c +4 -1
@@ -4651,7 +4651,10 @@ static void calculate_tdlut_setting(//the tdlut is fetched during the 2 row times of prefetch. if (p->setup_for_tdlut) { *p->tdlut_groups_per_2row_ub = (unsigned int )math_ceil2 ((double ) *p->tdlut_bytes_per_frame / *p->tdlut_bytes_per_group,1 ); - *p->tdlut_opt_time = (*p->tdlut_bytes_per_frame - p->cursor_buffer_size *1024 ) / tdlut_drain_rate; +if (*p->tdlut_bytes_per_frame > p->cursor_buffer_size *1024 ) + *p->tdlut_opt_time = (*p->tdlut_bytes_per_frame - p->cursor_buffer_size *1024 ) / tdlut_drain_rate; +else + *p->tdlut_opt_time =0 ; *p->tdlut_drain_time = p->cursor_buffer_size *1024 / tdlut_drain_rate; }
Greg Kroah-Hartman
maintainerPATCH 168/218 drm/amdgpu: Add kicker device detection
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Frank Min <[email protected]>
commit 0bbf5fd86c585d437b75003f11365b324360a5d6 upstream.
1. add kicker device list
2. add kicker device checking helper function
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 17 +++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 6 ++++++ 2 files changed, 23 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c +17 -0
@@ -30,6 +30,10 @@#define AMDGPU_UCODE_NAME_MAX (128) +static const struct kicker_device kicker_device_list[] = { + {0x744B ,0x00 }, +}; +static void amdgpu_ucode_print_common_hdr (const struct common_firmware_header *hdr) {DRM_DEBUG ("size_bytes: %u\n" ,le32_to_cpu (hdr->size_bytes));
@@ -1383,6 +1387,19 @@ static const char *amdgpu_ucode_legacy_nreturn NULL ; } +bool amdgpu_is_kicker_fw (struct amdgpu_device *adev) +{ +int i; + +for (i =0 ; i <ARRAY_SIZE (kicker_device_list); i++) { +if (adev->pdev->device == kicker_device_list[i].device && + adev->pdev->revision == kicker_device_list[i].revision) +return true; + } + +return false; +} +void amdgpu_ucode_ip_version_decode (struct amdgpu_device *adev,int block_type,char *ucode_prefix,int len) {int maj, min, rev;
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h +6 -0
@@ -595,6 +595,11 @@ struct amdgpu_firmware {uint64_t fw_buf_mc; }; +struct kicker_device { +unsigned short device; +u8 revision; +}; +void amdgpu_ucode_print_mc_hdr (const struct common_firmware_header *hdr);void amdgpu_ucode_print_smc_hdr (const struct common_firmware_header *hdr);void amdgpu_ucode_print_imu_hdr (const struct common_firmware_header *hdr);
@@ -622,5 +627,6 @@ amdgpu_ucode_get_load_type(struct amdgpuconst char *amdgpu_ucode_name (enum AMDGPU_UCODE_ID ucode_id);void amdgpu_ucode_ip_version_decode (struct amdgpu_device *adev,int block_type,char *ucode_prefix,int len); +bool amdgpu_is_kicker_fw (struct amdgpu_device *adev);#endif
Greg Kroah-Hartman
maintainerPATCH 169/218 drm/amd/display: Check dce_hwseq before dereferencing it
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Hung <[email protected]>
commit b669507b637eb6b1aaecf347f193efccc65d756e upstream.
[WHAT]
hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used.
--- drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c +1 -1
@@ -1217,7 +1217,7 @@ void dce110_blank_stream(struct pipe_ctxstruct dce_hwseq *hws = link->dc->hwseq;if (link->local_sink && link->local_sink->sink_signal ==SIGNAL_TYPE_EDP ) { -if (!link->skip_implict_edp_power_control) +if (!link->skip_implict_edp_power_control && hws) hws->funcs.edp_backlight_control (link, false); link->dc->hwss.set_abm_immediate_disable (pipe_ctx); }
Greg Kroah-Hartman
maintainerPATCH 170/218 drm/xe: Fix memset on iomem
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lucas De Marchi <[email protected]>
commit 87a15c89d8c7b00b0fc94e0d4f554f7ee2fe6961 upstream.
It should rather use xe_map_memset() as the BO is created with XE_BO_FLAG_VRAM_IF_DGFX in xe_guc_pc_init().
--- drivers/gpu/drm/xe/xe_guc_pc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/xe/xe_guc_pc.c +1 -1
@@ -975,7 +975,7 @@ int xe_guc_pc_start(struct xe_guc_pc *pc goto out; } -memset (pc->bo->vmap.vaddr,0 , size); +xe_map_memset (xe, &pc->bo->vmap,0 ,0 , size);slpc_shared_data_write (pc, header.size, size); ret =pc_action_reset (pc);
Greg Kroah-Hartman
maintainerPATCH 171/218 drm/xe: Fix taking invalid lock on wedge
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lucas De Marchi <[email protected]>
commit 1e1981b16bb1bbe2fafa57ed439b45cb5b34e32d upstream.
If device wedges on e.g. GuC upload, the submission is not yet enabled and the state is not even initialized. Protect the wedge call so it does nothing in this case. It fixes the following splat:
[] xe 0000:bf:00.0: [drm] device wedged, needs recovery [] ------------[ cut here ]------------ [] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60 ... [] RIP: 0010:__mutex_lock+0x8a1/0xe60 [] mutex_lock_nested+0x1b/0x30 [] xe_guc_submit_wedge+0x80/0x2b0 [xe]
--- drivers/gpu/drm/xe/xe_guc_submit.c | 9 +++++++++ drivers/gpu/drm/xe/xe_guc_types.h | 5 +++++ 2 files changed, 14 insertions(+)
drivers/gpu/drm/xe/xe_guc_submit.c +9 -0
@@ -309,6 +309,8 @@ int xe_guc_submit_init(struct xe_guc *guprimelockdep (guc); + guc->submission_state.initialized = true; +return drmm_add_action_or_reset (&xe->drm, guc_submit_fini, guc); }
@@ -837,6 +839,13 @@ void xe_guc_submit_wedge(struct xe_guc *xe_gt_assert (guc_to_gt (guc),guc_to_xe (guc)->wedged.mode); +/* +* If device is being wedged even before submission_state is +* initialized, there's nothing to do here. +*/ +if (!guc->submission_state.initialized) +return ; + err =devm_add_action_or_reset (guc_to_xe (guc)->drm.dev, guc_submit_wedged_fini, guc);if (err) {
drivers/gpu/drm/xe/xe_guc_types.h +5 -0
@@ -74,6 +74,11 @@ struct xe_guc {struct mutex lock;/** @submission_state.enabled: submission is enabled */ bool enabled; +/** +* @submission_state.initialized: mark when submission state is +* even initialized - before that not even the lock is valid +*/ +bool initialized;/** @submission_state.fini_wq: submit fini wait queue */ wait_queue_head_t fini_wq; } submission_state;
Greg Kroah-Hartman
maintainerPATCH 172/218 drm/xe: Fix early wedge on GuC load failure
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniele Ceraolo Spurio <[email protected]>
commit a39d082c3553d35b4fe5585e1e2fb221c130cae8 upstream.
When the GuC fails to load we declare the device wedged. However, the very first GuC load attempt on GT0 (from xe_gt_init_hwconfig) is done before the GT1 GuC objects are initialized, so things go bad when the wedge code attempts to cleanup GT1. To fix this, check the initialization status in the functions called during wedge.
--- drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c | 8 ++++++++ drivers/gpu/drm/xe/xe_guc_ct.c | 7 +++++-- drivers/gpu/drm/xe/xe_guc_ct.h | 5 +++++ drivers/gpu/drm/xe/xe_guc_submit.c | 3 +++ 4 files changed, 21 insertions(+), 2 deletions(-)
drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c +8 -0
@@ -138,6 +138,14 @@ void xe_gt_tlb_invalidation_reset(structint pending_seqno;/* +* we can get here before the CTs are even initialized if we're wedging +* very early, in which case there are not going to be any pending +* fences so we can bail immediately. +*/ +if (!xe_guc_ct_initialized (>->uc.guc.ct)) +return ; + +/* * CT channel is already disabled at this point. No new TLB requests can * appear. */
drivers/gpu/drm/xe/xe_guc_ct.c +5 -2
@@ -454,6 +454,9 @@ void xe_guc_ct_disable(struct xe_guc_ct*/ void xe_guc_ct_stop (struct xe_guc_ct *ct) { +if (!xe_guc_ct_initialized (ct)) +return ; +xe_guc_ct_set_state (ct,XE_GUC_CT_STATE_STOPPED );stop_g2h_handler (ct); }
@@ -638,7 +641,7 @@ static int __guc_ct_send_locked(struct xu16 seqno;int ret; -xe_gt_assert (gt, ct->state !=XE_GUC_CT_STATE_NOT_INITIALIZED ); +xe_gt_assert (gt,xe_guc_ct_initialized (ct));xe_gt_assert (gt, !g2h_len || !g2h_fence);xe_gt_assert (gt, !num_g2h || !g2h_fence);xe_gt_assert (gt, !g2h_len || num_g2h);
@@ -1209,7 +1212,7 @@ static int g2h_read(struct xe_guc_ct *ctu32 action;u32 *hxg; -xe_gt_assert (gt, ct->state !=XE_GUC_CT_STATE_NOT_INITIALIZED ); +xe_gt_assert (gt,xe_guc_ct_initialized (ct));lockdep_assert_held (&ct->fast_lock);if (ct->state ==XE_GUC_CT_STATE_DISABLED )
drivers/gpu/drm/xe/xe_guc_ct.h +5 -0
@@ -23,6 +23,11 @@ void xe_guc_ct_snapshot_print(struct xe_void xe_guc_ct_snapshot_free (struct xe_guc_ct_snapshot *snapshot);void xe_guc_ct_print (struct xe_guc_ct *ct,struct drm_printer *p,bool atomic); +static inline bool xe_guc_ct_initialized (struct xe_guc_ct *ct) +{ +return ct->state !=XE_GUC_CT_STATE_NOT_INITIALIZED ; +} +static inline bool xe_guc_ct_enabled (struct xe_guc_ct *ct) {return ct->state ==XE_GUC_CT_STATE_ENABLED ;
drivers/gpu/drm/xe/xe_guc_submit.c +3 -0
@@ -1722,6 +1722,9 @@ int xe_guc_submit_reset_prepare(struct x {int ret; +if (!guc->submission_state.initialized) +return 0 ; +/* * Using an atomic here rather than submission_state.lock as this * function can be called while holding the CT lock (engine reset
Greg Kroah-Hartman
maintainerPATCH 173/218 drm/i915/dsi: Fix off by one in BXT_MIPI_TRANS_VTOTAL
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ville Syrjälä <[email protected]>
commit c464ce6af332e7c802c36cd337cacf81db05400c upstream.
BXT_MIPI_TRANS_VTOTAL must be programmed with vtotal-1 instead of vtotal. Make it so.
--- drivers/gpu/drm/i915/display/vlv_dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/display/vlv_dsi.c +2 -2
@@ -1059,7 +1059,7 @@ static void bxt_dsi_get_pipe_config(stru BXT_MIPI_TRANS_VACTIVE(port)); adjusted_mode->crtc_vtotal =intel_de_read (display, -BXT_MIPI_TRANS_VTOTAL (port)); +BXT_MIPI_TRANS_VTOTAL (port)) +1 ; hactive = adjusted_mode->crtc_hdisplay; hfp =intel_de_read (display,MIPI_HFP_COUNT (display, port));
@@ -1264,7 +1264,7 @@ static void set_dsi_timings(struct intelintel_de_write (display,BXT_MIPI_TRANS_VACTIVE (port), adjusted_mode->crtc_vdisplay);intel_de_write (display,BXT_MIPI_TRANS_VTOTAL (port), - adjusted_mode->crtc_vtotal); + adjusted_mode->crtc_vtotal -1 ); } intel_de_write(display, MIPI_HACTIVE_AREA_COUNT(display, port),
Greg Kroah-Hartman
maintainerPATCH 174/218 drm/amdgpu: Fix SDMA UTC_L1 handling during start/stop sequences
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jesse Zhang <[email protected]>
commit 7f3b16f3f229e37cc3e02e9e4e7106c523b119e9 upstream.
This commit makes two key fixes to SDMA v4.4.2 handling:
1. disable UTC_L1 in sdma_cntl register when stopping SDMA engines by reading the current value before modifying UTC_L1_ENABLE bit.
2. Ensure UTC_L1_ENABLE is consistently managed by:
- Adding the missing register write when enabling UTC_L1 during start
- Keeping UTC_L1 enabled by default as per hardware requirements
v2: Correct SDMA_CNTL setting (Philip)
--- drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c +5 -1
@@ -485,7 +485,7 @@ static void sdma_v4_4_2_inst_gfx_stop(st {struct amdgpu_ring *sdma[AMDGPU_MAX_SDMA_INSTANCES ];u32 doorbell_offset, doorbell; -u32 rb_cntl, ib_cntl; +u32 rb_cntl, ib_cntl, sdma_cntl;int i;for_each_inst (i, inst_mask) {
@@ -497,6 +497,9 @@ static void sdma_v4_4_2_inst_gfx_stop(st ib_cntl =RREG32_SDMA (i, regSDMA_GFX_IB_CNTL); ib_cntl =REG_SET_FIELD (ib_cntl,SDMA_GFX_IB_CNTL ,IB_ENABLE ,0 );WREG32_SDMA (i, regSDMA_GFX_IB_CNTL, ib_cntl); + sdma_cntl =RREG32_SDMA (i, regSDMA_CNTL); + sdma_cntl =REG_SET_FIELD (sdma_cntl,SDMA_CNTL ,UTC_L1_ENABLE ,0 ); +WREG32_SDMA (i, regSDMA_CNTL, sdma_cntl);if (sdma[i]->use_doorbell) { doorbell =RREG32_SDMA (i, regSDMA_GFX_DOORBELL);
@@ -953,6 +956,7 @@ static int sdma_v4_4_2_inst_start(struct/* set utc l1 enable flag always to 1 */ temp =RREG32_SDMA (i, regSDMA_CNTL); temp =REG_SET_FIELD (temp,SDMA_CNTL ,UTC_L1_ENABLE ,1 ); +WREG32_SDMA (i, regSDMA_CNTL, temp);if (amdgpu_ip_version (adev,SDMA0_HWIP ,0 ) <IP_VERSION (4 ,4 ,5 )) {/* enable context empty interrupt during initialization */
Greg Kroah-Hartman
maintainerPATCH 175/218 drm/amdgpu: switch job hw_fence to amdgpu_fence
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit ebe43542702c3d15d1a1d95e8e13b1b54076f05a upstream.
Use the amdgpu fence container so we can store additional data in the fence. This also fixes the start_time handling for MCBP since we were casting the fence to an amdgpu_fence and it wasn't.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 - drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 - drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 30 ++++++---------------------- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 12 +++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 2 - drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 16 ++++++++++++++ 6 files changed, 32 insertions(+), 32 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c +1 -1
@@ -1902,7 +1902,7 @@ no_preempt:continue ; } job =to_amdgpu_job (s_job); -if (preempted && (&job->hw_fence) == fence) +if (preempted && (&job->hw_fence.base) == fence)/* mark the job as preempted */ job->preemption_status |=AMDGPU_IB_PREEMPTED ; }
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +1 -1
@@ -5861,7 +5861,7 @@ int amdgpu_device_gpu_recover(struct amd* * job->base holds a reference to parent fence */ -if (job &&dma_fence_is_signaled (&job->hw_fence)) { +if (job &&dma_fence_is_signaled (&job->hw_fence.base)) { job_signaled = true;dev_info (adev->dev,"Guilty job already signaled, skipping HW reset" ); goto skip_hw_reset;
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +7 -23
@@ -41,22 +41,6 @@#include "amdgpu_trace.h" #include "amdgpu_reset.h" -/* -* Fences mark an event in the GPUs pipeline and are used -* for GPU/CPU synchronization. When the fence is written, -* it is expected that all buffers associated with that fence -* are no longer in use by the associated ring on the GPU and -* that the relevant GPU caches have been flushed. -*/ - -struct amdgpu_fence { -struct dma_fence base; - -/* RB, DMA, etc. */ -struct amdgpu_ring *ring; -ktime_t start_timestamp; -}; -static struct kmem_cache *amdgpu_fence_slab;int amdgpu_fence_slab_init (void )
@@ -151,12 +135,12 @@ int amdgpu_fence_emit(struct amdgpu_ring am_fence =kmem_cache_alloc (amdgpu_fence_slab,GFP_ATOMIC );if (am_fence ==NULL )return -ENOMEM ; - fence = &am_fence->base; - am_fence->ring = ring; }else {/* take use of job-embedded fence */ - fence = &job->hw_fence; + am_fence = &job->hw_fence; } + fence = &am_fence->base; + am_fence->ring = ring; seq = ++ring->fence_drv.sync_seq;if (job && job->job_run_counter) {
@@ -718,7 +702,7 @@ void amdgpu_fence_driver_clear_job_fence* it right here or we won't be able to track them in fence_drv * and they will remain unsignaled during sa_bo free. */ - job = container_of(old, struct amdgpu_job, hw_fence); + job = container_of(old, struct amdgpu_job, hw_fence.base);if (!job->base.s_fence && !dma_fence_is_signaled (old))dma_fence_signal (old);RCU_INIT_POINTER (*ptr,NULL );
@@ -780,7 +764,7 @@ static const char *amdgpu_fence_get_timestatic const char *amdgpu_job_fence_get_timeline_name (struct dma_fence *f) { - struct amdgpu_job *job = container_of(f, struct amdgpu_job, hw_fence); + struct amdgpu_job *job = container_of(f, struct amdgpu_job, hw_fence.base);return (const char *)to_amdgpu_ring (job->base.sched)->name; }
@@ -810,7 +794,7 @@ static bool amdgpu_fence_enable_signalin*/ static bool amdgpu_job_fence_enable_signaling (struct dma_fence *f) { - struct amdgpu_job *job = container_of(f, struct amdgpu_job, hw_fence); + struct amdgpu_job *job = container_of(f, struct amdgpu_job, hw_fence.base);if (!timer_pending (&to_amdgpu_ring (job->base.sched)->fence_drv.fallback_timer))amdgpu_fence_schedule_fallback (to_amdgpu_ring (job->base.sched));
@@ -845,7 +829,7 @@ static void amdgpu_job_fence_free(struct struct dma_fence *f = container_of(rcu, struct dma_fence, rcu);/* free job if fence has a parent job */ -kfree (container_of(f ,struct amdgpu_job ,hw_fence )); + kfree(container_of(f, struct amdgpu_job, hw_fence.base)); }/**
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c +6 -6
@@ -259,8 +259,8 @@ void amdgpu_job_free_resources(struct am/* Check if any fences where initialized */ if (job->base.s_fence && job->base.s_fence->finished.ops) f = &job->base.s_fence->finished; -else if (job->hw_fence.ops) - f = &job->hw_fence; +else if (job->hw_fence.base.ops) + f = &job->hw_fence.base;else f =NULL ;
@@ -277,10 +277,10 @@ static void amdgpu_job_free_cb(struct dramdgpu_sync_free (&job->explicit_sync);/* only put the hw fence if has embedded fence */ -if (!job->hw_fence.ops) +if (!job->hw_fence.base.ops)kfree (job);else -dma_fence_put (&job->hw_fence); +dma_fence_put (&job->hw_fence.base); } void amdgpu_job_set_gang_leader(struct amdgpu_job *job,
@@ -309,10 +309,10 @@ void amdgpu_job_free(struct amdgpu_job *if (job->gang_submit != &job->base.s_fence->scheduled)dma_fence_put (job->gang_submit); -if (!job->hw_fence.ops) +if (!job->hw_fence.base.ops)kfree (job);else -dma_fence_put (&job->hw_fence); +dma_fence_put (&job->hw_fence.base); }struct dma_fence *amdgpu_job_submit (struct amdgpu_job *job)
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h +1 -1
@@ -48,7 +48,7 @@ struct amdgpu_job {struct drm_sched_job base;struct amdgpu_vm *vm;struct amdgpu_sync explicit_sync; -struct dma_fence hw_fence; +struct amdgpu_fence hw_fence;struct dma_fence *gang_submit;uint32_t preamble_status;uint32_t preemption_status;
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h +16 -0
@@ -126,6 +126,22 @@ struct amdgpu_fence_driver {struct dma_fence **fences; }; +/* +* Fences mark an event in the GPUs pipeline and are used +* for GPU/CPU synchronization. When the fence is written, +* it is expected that all buffers associated with that fence +* are no longer in use by the associated ring on the GPU and +* that the relevant GPU caches have been flushed. +*/ + +struct amdgpu_fence { +struct dma_fence base; + +/* RB, DMA, etc. */ +struct amdgpu_ring *ring; +ktime_t start_timestamp; +}; +extern const struct drm_sched_backend_ops amdgpu_sched_ops;void amdgpu_fence_driver_clear_job_fences (struct amdgpu_ring *ring);
Greg Kroah-Hartman
maintainerPATCH 176/218 drm/amd/display: Fix mpv playback corruption on weston
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Hung <[email protected]>
commit 8724a5380c4390eed81e271d22f34ff06453ded9 upstream.
[WHAT]
Severe video playback corruption is observed in the following setup:
weston 14.0.90 (built from source) + mpv v0.40.0 with command:
mpv bbb_sunflower_1080p_60fps_normal.mp4 --vo=gpu
[HOW]
ABGR16161616 needs to be included in dml2/2.1 translation.
--- drivers/gpu/drm/amd/display/dc/dml2/dml21/dml21_translation_helper.c | 1 + drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c | 1 + 2 files changed, 2 insertions(+)
drivers/gpu/drm/amd/display/dc/dml2/dml21/dml21_translation_helper.c +1 -0
@@ -762,6 +762,7 @@ static void populate_dml21_plane_config_ plane->pixel_format = dml2_420_10;break ;case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616 : +case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 :case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616F :case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616F : plane->pixel_format = dml2_444_64;
drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c +1 -0
@@ -909,6 +909,7 @@ static void populate_dml_surface_cfg_fro out->SourcePixelFormat[location] = dml_420_10;break ;case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616 : +case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 :case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616F :case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616F : out->SourcePixelFormat[location] = dml_444_64;
Greg Kroah-Hartman
maintainerPATCH 177/218 media: uvcvideo: Rollback non processed entities on error
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ricardo Ribalda <[email protected]>
commit a70705d3c020d0d5c3ab6a5cc93e011ac35e7d48 upstream.
If we fail to commit an entity, we need to restore the UVC_CTRL_DATA_BACKUP for the other uncommitted entities. Otherwise the control cache and the device would be out of sync.
Message-ID: <[email protected]>
--- drivers/media/usb/uvc/uvc_ctrl.c | 34 +++++++++++++++++++++++----------- 1 file changed, 23 insertions(+), 11 deletions(-)
drivers/media/usb/uvc/uvc_ctrl.c +23 -11
@@ -1848,7 +1848,7 @@ static int uvc_ctrl_commit_entity(structunsigned int processed_ctrls =0 ;struct uvc_control *ctrl;unsigned int i; -int ret; +int ret =0 ;if (entity ==NULL )return 0 ;
@@ -1877,8 +1877,6 @@ static int uvc_ctrl_commit_entity(struct dev->intfnum, ctrl->info.selector,uvc_ctrl_data (ctrl,UVC_CTRL_DATA_CURRENT ), ctrl->info.size); - else - ret =0 ;if (!ret) processed_ctrls++;
@@ -1890,17 +1888,24 @@ static int uvc_ctrl_commit_entity(struct ctrl->dirty =0 ; -if (ret <0 ) { +if (ret <0 && !rollback) {if (err_ctrl) *err_ctrl = ctrl; -return ret; +/* +* If we fail to set a control, we need to rollback +* the next ones. +*/ + rollback =1 ; } -if (!rollback && handle && +if (!rollback && handle && !ret && ctrl->info.flags &UVC_CTRL_FLAG_ASYNCHRONOUS )uvc_ctrl_set_handle (handle, ctrl, handle); } +if (ret) +return ret; +return processed_ctrls; }
@@ -1931,7 +1936,8 @@ int __uvc_ctrl_commit(struct uvc_fh *hanstruct uvc_video_chain *chain = handle->chain;struct uvc_control *err_ctrl;struct uvc_entity *entity; -int ret =0 ; +int ret_out =0 ; +int ret;/* Find the control. */ list_for_each_entry (entity, &chain->entities, chain) {
@@ -1942,17 +1948,23 @@ int __uvc_ctrl_commit(struct uvc_fh *han ctrls->error_idx =uvc_ctrl_find_ctrl_idx (entity, ctrls, err_ctrl); - goto done; +/* +* When we fail to commit an entity, we need to +* restore the UVC_CTRL_DATA_BACKUP for all the +* controls in the other entities, otherwise our cache +* and the hardware will be out of sync. +*/ + rollback =1 ; + + ret_out = ret; }else if (ret >0 && !rollback) {uvc_ctrl_send_events (handle, entity, ctrls->controls, ctrls->count); } } - ret =0 ; -done:mutex_unlock (&chain->ctrl_mutex); -return ret; +return ret_out; } int uvc_ctrl_get(struct uvc_video_chain *chain,
Greg Kroah-Hartman
maintainerPATCH 178/218 x86/fpu: Refactor xfeature bitmask update code for sigframe XSAVE
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chang S. Bae <[email protected]>
commit 64e54461ab6e8524a8de4e63b7d1a3e4481b5cf3 upstream.
Currently, saving register states in the signal frame, the legacy feature bits are always set in xregs_state->header->xfeatures. This code sequence can be generalized for reuse in similar cases.
Refactor the logic to ensure a consistent approach across similar usages.
--- arch/x86/kernel/fpu/signal.c | 11 +---------- arch/x86/kernel/fpu/xstate.h | 13 +++++++++++++ 2 files changed, 14 insertions(+), 10 deletions(-)
arch/x86/kernel/fpu/signal.c +1 -10
@@ -119,7 +119,6 @@ static inline bool save_xstate_epilog(vo {struct xregs_state __user *x = buf;struct _fpx_sw_bytes sw_bytes = {}; -u32 xfeatures;int err;/* Setup the bytes not touched by the [f]xsave and reserved for SW. */
@@ -133,12 +132,6 @@ static inline bool save_xstate_epilog(vo (__u32 __user *)(buf + fpstate->user_size));/* -* Read the xfeatures which we copied (directly from the cpu or -* from the state in task struct) to the user buffers. -*/ - err |=__get_user (xfeatures, (__u32 __user *)&x->header.xfeatures); - -/* * For legacy compatible, we always set FP/SSE bits in the bit * vector while saving the state to the user context. This will * enable us capturing any changes(during sigreturn) to
@@ -149,9 +142,7 @@ static inline bool save_xstate_epilog(vo* header as well as change any contents in the memory layout. * xrestore as part of sigreturn will capture all the changes. */ - xfeatures |=XFEATURE_MASK_FPSSE ; - - err |=__put_user (xfeatures, (__u32 __user *)&x->header.xfeatures); + err |=set_xfeature_in_sigframe (x,XFEATURE_MASK_FPSSE );return !err; }
arch/x86/kernel/fpu/xstate.h +13 -0
@@ -69,6 +69,19 @@ static inline u64 xfeatures_mask_indepenreturn fpu_kernel_cfg.independent_features; } +static inline int set_xfeature_in_sigframe (struct xregs_state __user *xbuf,u64 mask) +{ +u64 xfeatures; +int err; + +/* Read the xfeatures value already saved in the user buffer */ + err =__get_user (xfeatures, &xbuf->header.xfeatures); + xfeatures |= mask; + err |=__put_user (xfeatures, &xbuf->header.xfeatures); + +return err; +} +/* * Update the value of PKRU register that was already pushed onto the signal frame. */
Greg Kroah-Hartman
maintainerPATCH 179/218 x86/pkeys: Simplify PKRU update in signal frame
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chang S. Bae <[email protected]>
commit d1e420772cd1eb0afe5858619c73ce36f3e781a1 upstream.
The signal delivery logic was modified to always set the PKRU bit in xregs_state->header->xfeatures by this commit:
ae6012d72fa6 ("x86/pkeys: Ensure updated PKRU value is XRSTOR'd")
However, the change derives the bitmask value using XGETBV(1), rather than simply updating the buffer that already holds the value. Thus, this approach induces an unnecessary dependency on XGETBV1 for PKRU handling.
Eliminate the dependency by using the established helper function. Subsequently, remove the now-unused 'mask' argument.
--- arch/x86/kernel/fpu/xstate.h | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
arch/x86/kernel/fpu/xstate.h +3 -6
@@ -85,18 +85,15 @@ static inline int set_xfeature_in_sigfra/* * Update the value of PKRU register that was already pushed onto the signal frame. */ -static inline int update_pkru_in_sigframe (struct xregs_state __user *buf,u64 mask,u32 pkru) +static inline int update_pkru_in_sigframe (struct xregs_state __user *buf,u32 pkru) { -u64 xstate_bv;int err;if (unlikely (!cpu_feature_enabled (X86_FEATURE_OSPKE )))return 0 ;/* Mark PKRU as in-use so that it is restored correctly. */ - xstate_bv = (mask &xfeatures_in_use ()) |XFEATURE_MASK_PKRU ; - - err =__put_user (xstate_bv, &buf->header.xfeatures); + err =set_xfeature_in_sigframe (buf,XFEATURE_MASK_PKRU );if (err)return err;
@@ -317,7 +314,7 @@ static inline int xsave_to_user_sigframeclac ();if (!err) - err =update_pkru_in_sigframe (buf, mask, pkru); + err =update_pkru_in_sigframe (buf, pkru);return err; }
Greg Kroah-Hartman
maintainerPATCH 180/218 net: libwx: fix Tx L4 checksum
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiawen Wu <[email protected]>
commit c7d82913d5f9e97860772ee4051eaa66b56a6273 upstream.
The hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol. There was a bug to set Tx checksum flag for the other protocol that results in Tx ring hang. Fix to compute software checksum for these packets.
--- drivers/net/ethernet/wangxun/libwx/wx_lib.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/wangxun/libwx/wx_lib.c +3 -1
@@ -1336,6 +1336,7 @@ static void wx_tx_csum(struct wx_ring *tu8 tun_prot =0 ;if (skb->ip_summed !=CHECKSUM_PARTIAL ) { +csum_failed:if (!(first->tx_flags &WX_TX_FLAGS_HW_VLAN ) && !(first->tx_flags &WX_TX_FLAGS_CC ))return ;
@@ -1429,7 +1430,8 @@ static void wx_tx_csum(struct wx_ring *tWX_TXD_L4LEN_SHIFT ;break ;default : -break ; +skb_checksum_help (skb); + goto csum_failed; }/* update TX checksum flag */
Greg Kroah-Hartman
maintainerPATCH 181/218 io_uring: fix potential page leak in io_sqe_buffer_register()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Penglei Jiang <[email protected]>
Commit e1c75831f682eef0f68b35723437146ed86070b1 upstream.
If allocation of the 'imu' fails, then the existing pages aren't unpinned in the error path. This is mostly a theoretical issue, requiring fault injection to hit.
Move unpin_user_pages() to unified error handling to fix the page leak issue.
--- io_uring/rsrc.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
io_uring/rsrc.c +5 -4
@@ -983,10 +983,8 @@ static int io_sqe_buffer_register(struct goto done; ret =io_buffer_account_pin (ctx, pages, nr_pages, imu, last_hpage); -if (ret) { -unpin_user_pages (pages, nr_pages); +if (ret) goto done; - } size = iov->iov_len;/* store original address for later verification */
@@ -1010,8 +1008,11 @@ static int io_sqe_buffer_register(struct size -= vec_len; } done: -if (ret) +if (ret) {kvfree (imu); +if (pages) +unpin_user_pages (pages, nr_pages); + }kvfree (pages);return ret; }
Greg Kroah-Hartman
maintainerPATCH 182/218 io_uring/rsrc: fix folio unpinning
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Begunkov <[email protected]>
Commit 5afb4bf9fc62d828647647ec31745083637132e4 upstream.
syzbot complains about an unmapping failure:
[ 108.070381][ T14] kernel BUG at mm/gup.c:71! [ 108.070502][ T14] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 108.123672][ T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025 [ 108.127458][ T14] Workqueue: iou_exit io_ring_exit_work [ 108.174205][ T14] Call trace: [ 108.175649][ T14] sanity_check_pinned_pages+0x7cc/0x7d0 (P) [ 108.178138][ T14] unpin_user_page+0x80/0x10c [ 108.180189][ T14] io_release_ubuf+0x84/0xf8 [ 108.182196][ T14] io_free_rsrc_node+0x250/0x57c [ 108.184345][ T14] io_rsrc_data_free+0x148/0x298 [ 108.186493][ T14] io_sqe_buffers_unregister+0x84/0xa0 [ 108.188991][ T14] io_ring_ctx_free+0x48/0x480 [ 108.191057][ T14] io_ring_exit_work+0x764/0x7d8 [ 108.193207][ T14] process_one_work+0x7e8/0x155c [ 108.195431][ T14] worker_thread+0x958/0xed8 [ 108.197561][ T14] kthread+0x5fc/0x75c [ 108.199362][ T14] ret_from_fork+0x10/0x20
We can pin a tail page of a folio, but then io_uring will try to unpin the head page of the folio. While it should be fine in terms of keeping the page actually alive, mm folks say it's wrong and triggers a debug warning. Use unpin_user_folio() instead of unpin_user_page*.
--- io_uring/rsrc.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
io_uring/rsrc.c +9 -4
@@ -119,8 +119,11 @@ static void io_buffer_unmap(struct io_riif (imu != &dummy_ubuf) {if (!refcount_dec_and_test (&imu->refs))return ; -for (i =0 ; i < imu->nr_bvecs; i++) -unpin_user_page (imu->bvec[i].bv_page); +for (i =0 ; i < imu->nr_bvecs; i++) { +struct folio *folio =page_folio (imu->bvec[i].bv_page); + +unpin_user_folio (folio,1 ); + }if (imu->acct_pages)io_unaccount_mem (ctx, imu->acct_pages);kvfree (imu);
@@ -1010,8 +1013,10 @@ static int io_sqe_buffer_register(struct done:if (ret) {kvfree (imu); -if (pages) -unpin_user_pages (pages, nr_pages); +if (pages) { +for (i =0 ; i < nr_pages; i++) +unpin_user_folio (page_folio (pages[i]),1 ); + } }kvfree (pages);return ret;
Greg Kroah-Hartman
maintainerPATCH 183/218 io_uring/rsrc: dont rely on user vaddr alignment
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Begunkov <[email protected]>
Commit 3a3c6d61577dbb23c09df3e21f6f9eda1ecd634b upstream.
There is no guaranteed alignment for user pointers, however the calculation of an offset of the first page into a folio after coalescing uses some weird bit mask logic, get rid of it.
--- io_uring/rsrc.c | 5 ++++- io_uring/rsrc.h | 1 + 2 files changed, 5 insertions(+), 1 deletion(-)
io_uring/rsrc.c +4 -1
@@ -918,6 +918,7 @@ static bool io_try_coalesce_buffer(strucreturn false; data->folio_shift =folio_shift (folio); + data->first_folio_page_idx =folio_page_idx (folio, page_array[0 ]);/* * Check if pages are contiguous inside a folio, and all folios have * the same page count except for the head and tail.
@@ -998,7 +999,9 @@ static int io_sqe_buffer_register(structif (coalesced) imu->folio_shift = data.folio_shift;refcount_set (&imu->refs,1 ); - off = (unsigned long ) iov->iov_base & ((1UL << imu->folio_shift) -1 ); + off = (unsigned long )iov->iov_base & ~PAGE_MASK ; +if (coalesced) + off += data.first_folio_page_idx <<PAGE_SHIFT ; *pimu = imu; ret =0 ;
io_uring/rsrc.h +1 -0
@@ -56,6 +56,7 @@ struct io_imu_folio_data {/* For non-head/tail folios, has to be fully included */ unsigned int nr_pages_mid;unsigned int folio_shift; +unsigned long first_folio_page_idx; };void io_rsrc_node_ref_zero (struct io_rsrc_node *node);
Greg Kroah-Hartman
maintainerPATCH 184/218 io_uring/net: improve recv bundles
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
Commit 7c71a0af81ba72de9b2c501065e4e718aba9a271 upstream.
Current recv bundles are only supported for multishot receives, and additionally they also always post at least 2 CQEs if more data is available than what a buffer will hold. This happens because the initial bundle recv will do a single buffer, and then do the rest of what is in the socket as a followup receive. As shown in a test program, if 1k buffers are available and 32k is available to receive in the socket, you'd get the following completions:
bundle=1, mshot=0
cqe res 1024
cqe res 1024
[...]
cqe res 1024
bundle=1, mshot=1
cqe res 1024
cqe res 31744
where bundle=1 && mshot=0 will post 32 1k completions, and bundle=1 && mshot=1 will post a 1k completion and then a 31k completion.
To support bundle recv without multishot, it's possible to simply retry the recv immediately and post a single completion, rather than split it into two completions. With the below patch, the same test looks as follows:
bundle=1, mshot=0
cqe res 32768
bundle=1, mshot=1
cqe res 32768
where mshot=0 works fine for bundles, and both of them post just a single 32k completion rather than split it into separate completions. Posting fewer completions is always a nice win, and not needing multishot for proper bundle efficiency is nice for cases that can't necessarily use multishot.
--- io_uring/net.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
io_uring/net.c +18 -0
@@ -76,6 +76,7 @@ struct io_sr_msg {/* initialised and used only by !msg send variants */ u16 addr_len;u16 buf_group; +bool retry;void __user *addr;void __user *msg_control;/* used only for send zerocopy */
@@ -203,6 +204,7 @@ static inline void io_mshot_prep_retry(s req->flags &= ~REQ_F_BL_EMPTY ; sr->done_io =0 ; + sr->retry = false; sr->len =0 ;/* get from the provided buffer */ req->buf_index = sr->buf_group; }
@@ -409,6 +411,7 @@ int io_sendmsg_prep(struct io_kiocb *req struct io_sr_msg *sr = io_kiocb_to_cmd(req, struct io_sr_msg); sr->done_io =0 ; + sr->retry = false;if (req->opcode ==IORING_OP_SEND ) {if (READ_ONCE (sqe->__pad3[0 ]))
@@ -780,6 +783,7 @@ int io_recvmsg_prep(struct io_kiocb *req struct io_sr_msg *sr = io_kiocb_to_cmd(req, struct io_sr_msg); sr->done_io =0 ; + sr->retry = false;if (unlikely (sqe->file_index || sqe->addr2))return -EINVAL ;
@@ -828,6 +832,9 @@ int io_recvmsg_prep(struct io_kiocb *reqreturn io_recvmsg_prep_setup (req); } +/* bits to clear in old and inherit in new cflags on bundle retry */ +#define CQE_F_MASK (IORING_CQE_F_SOCK_NONEMPTY|IORING_CQE_F_MORE) +/* * Finishes io_recv and io_recvmsg. *
@@ -847,9 +854,19 @@ static inline bool io_recv_finish(structif (sr->flags &IORING_RECVSEND_BUNDLE ) { cflags |=io_put_kbufs (req, *ret,io_bundle_nbufs (kmsg, *ret), issue_flags); +if (sr->retry) + cflags = req->cqe.flags | (cflags &CQE_F_MASK );/* bundle with no more immediate buffers, we're done */ if (req->flags &REQ_F_BL_EMPTY ) goto finish; +/* if more is available, retry and append to this one */ +if (!sr->retry && kmsg->msg.msg_inq >0 && *ret >0 ) { + req->cqe.flags = cflags & ~CQE_F_MASK ; + sr->len = kmsg->msg.msg_inq; + sr->done_io += *ret; + sr->retry = true; +return false; + } }else { cflags |=io_put_kbuf (req, *ret, issue_flags); }
@@ -1228,6 +1245,7 @@ int io_send_zc_prep(struct io_kiocb *reqstruct io_kiocb *notif; zc->done_io =0 ; + zc->retry = false; req->flags |=REQ_F_POLL_NO_LAZY ;if (unlikely (READ_ONCE (sqe->__pad2[0 ]) ||READ_ONCE (sqe->addr3)))
Greg Kroah-Hartman
maintainerPATCH 185/218 io_uring/net: only retry recv bundle for a full transfer
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
Commit 3a08988123c868dbfdd054541b1090fb891fa49e upstream.
If a shorter than assumed transfer was seen, a partial buffer will have been filled. For that case it isn't sane to attempt to fill more into the bundle before posting a completion, as that will cause a gap in the received data.
Check if the iterator has hit zero and only allow to continue a bundle operation if that is the case.
Also ensure that for putting finished buffers, only the current transfer is accounted. Otherwise too many buffers may be put for a short transfer.
--- io_uring/net.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
io_uring/net.c +10 -4
@@ -852,18 +852,24 @@ static inline bool io_recv_finish(struct cflags |=IORING_CQE_F_SOCK_NONEMPTY ;if (sr->flags &IORING_RECVSEND_BUNDLE ) { - cflags |=io_put_kbufs (req, *ret,io_bundle_nbufs (kmsg, *ret), +size_t this_ret = *ret - sr->done_io; + + cflags |=io_put_kbufs (req, *ret,io_bundle_nbufs (kmsg, this_ret), issue_flags);if (sr->retry) cflags = req->cqe.flags | (cflags &CQE_F_MASK );/* bundle with no more immediate buffers, we're done */ if (req->flags &REQ_F_BL_EMPTY ) goto finish; -/* if more is available, retry and append to this one */ -if (!sr->retry && kmsg->msg.msg_inq >0 && *ret >0 ) { +/* +* If more is available AND it was a full transfer, retry and +* append to this one +*/ +if (!sr->retry && kmsg->msg.msg_inq >0 && this_ret >0 && + !iov_iter_count (&kmsg->msg.msg_iter)) { req->cqe.flags = cflags & ~CQE_F_MASK ; sr->len = kmsg->msg.msg_inq; - sr->done_io += *ret; + sr->done_io += this_ret; sr->retry = true;return false; }
Greg Kroah-Hartman
maintainerPATCH 186/218 io_uring/net: only consider msg_inq if larger than 1
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
Commit 2c7f023219966777be0687e15b57689894304cd3 upstream.
Currently retry and general validity of msg_inq is gated on it being larger than zero, but it's entirely possible for this to be slightly inaccurate. In particular, if FIN is received, it'll return 1.
Just use larger than 1 as the check. This covers both the FIN case, and at the same time, it doesn't make much sense to retry a recv immediately if there's even just a single 1 byte of valid data in the socket.
Leave the SOCK_NONEMPTY flagging when larger than 0 still, as an app may use that for the final receive.
--- io_uring/net.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
io_uring/net.c +2 -2
@@ -865,7 +865,7 @@ static inline bool io_recv_finish(struct* If more is available AND it was a full transfer, retry and * append to this one */ -if (!sr->retry && kmsg->msg.msg_inq >0 && this_ret >0 && +if (!sr->retry && kmsg->msg.msg_inq >1 && this_ret >0 && !iov_iter_count (&kmsg->msg.msg_iter)) { req->cqe.flags = cflags & ~CQE_F_MASK ; sr->len = kmsg->msg.msg_inq;
@@ -1111,7 +1111,7 @@ static int io_recv_buf_select(struct io_ arg.mode |=KBUF_MODE_FREE ; } -if (kmsg->msg.msg_inq >0 ) +if (kmsg->msg.msg_inq >1 ) arg.max_len =min_not_zero (sr->len, kmsg->msg.msg_inq); ret =io_buffers_peek (req, &arg);
Greg Kroah-Hartman
maintainerPATCH 187/218 io_uring/net: always use current transfer count for buffer put
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
A previous fix corrected the retry condition for when to continue a current bundle, but it missed that the current (not the total) transfer count also applies to the buffer put. If not, then for incrementally consumed buffer rings repeated completions on the same request may end up over consuming.
--- io_uring/net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
io_uring/net.c +1 -1
@@ -854,7 +854,7 @@ static inline bool io_recv_finish(structif (sr->flags &IORING_RECVSEND_BUNDLE ) {size_t this_ret = *ret - sr->done_io; - cflags |=io_put_kbufs (req, *ret,io_bundle_nbufs (kmsg, this_ret), + cflags |=io_put_kbufs (req, this_ret,io_bundle_nbufs (kmsg, this_ret), issue_flags);if (sr->retry) cflags = req->cqe.flags | (cflags &CQE_F_MASK );
Greg Kroah-Hartman
maintainerPATCH 188/218 io_uring/net: mark iov as dynamically allocated even for single segments
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
Commit 9a709b7e98e6fa51600b5f2d24c5068efa6d39de upstream.
A bigger array of vecs could've been allocated, but io_ring_buffers_peek() still decided to cap the mapped range depending on how much data was available. Hence don't rely on the segment count to know if the request should be marked as needing cleanup, always check upfront if the iov array is different than the fast_iov array.
--- io_uring/net.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
io_uring/net.c +6 -5
@@ -1118,6 +1118,12 @@ static int io_recv_buf_select(struct io_if (unlikely (ret <0 ))return ret; +if (arg.iovs != &kmsg->fast_iov && arg.iovs != kmsg->free_iov) { + kmsg->free_iov_nr = ret; + kmsg->free_iov = arg.iovs; + req->flags |=REQ_F_NEED_CLEANUP ; + } +/* special case 1 vec, can be a fast path */ if (ret ==1 ) { sr->buf = arg.iovs[0 ].iov_base;
@@ -1126,11 +1132,6 @@ static int io_recv_buf_select(struct io_ }iov_iter_init (&kmsg->msg.msg_iter,ITER_DEST , arg.iovs, ret, arg.out_len); -if (arg.iovs != &kmsg->fast_iov && arg.iovs != kmsg->free_iov) { - kmsg->free_iov_nr = ret; - kmsg->free_iov = arg.iovs; - req->flags |=REQ_F_NEED_CLEANUP ; - } }else {void __user *buf;
Greg Kroah-Hartman
maintainerPATCH 189/218 io_uring/kbuf: flag partial buffer mappings
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
A previous commit aborted mapping more for a non-incremental ring for bundle peeking, but depending on where in the process this peeking happened, it would not necessarily prevent a retry by the user. That can create gaps in the received/read data.
Add struct buf_sel_arg->partial_map, which can pass this information back. The networking side can then map that to internal state and use it to gate retry as well.
Since this necessitates a new flag, change io_sr_msg->retry to a retry_flags member, and store both the retry and partial map condition in there.
--- io_uring/kbuf.c | 1 + io_uring/kbuf.h | 1 + io_uring/net.c | 23 +++++++++++++++-------- 3 files changed, 17 insertions(+), 8 deletions(-)
io_uring/kbuf.c +1 -0
@@ -263,6 +263,7 @@ static int io_ring_buffers_peek(struct iif (len > arg->max_len) { len = arg->max_len;if (!(bl->flags &IOBL_INC )) { + arg->partial_map =1 ;if (iov != arg->iovs)break ; buf->len = len;
io_uring/kbuf.h +1 -0
@@ -61,6 +61,7 @@ struct buf_sel_arg {size_t max_len;unsigned short nr_iovs;unsigned short mode; +unsigned short partial_map; }; void __user *io_buffer_select(struct io_kiocb *req, size_t *len,
io_uring/net.c +15 -8
@@ -76,13 +76,18 @@ struct io_sr_msg {/* initialised and used only by !msg send variants */ u16 addr_len;u16 buf_group; -bool retry; +unsigned short retry_flags;void __user *addr;void __user *msg_control;/* used only for send zerocopy */ struct io_kiocb *notif; }; +enum sr_retry_flags { +IO_SR_MSG_RETRY =1 , +IO_SR_MSG_PARTIAL_MAP =2 , +}; +/* * Number of times we'll try and do receives if there's more data. If we * exceed this limit, then add us to the back of the queue and retry from
@@ -204,7 +209,7 @@ static inline void io_mshot_prep_retry(s req->flags &= ~REQ_F_BL_EMPTY ; sr->done_io =0 ; - sr->retry = false; + sr->retry_flags =0 ; sr->len =0 ;/* get from the provided buffer */ req->buf_index = sr->buf_group; }
@@ -411,7 +416,7 @@ int io_sendmsg_prep(struct io_kiocb *req struct io_sr_msg *sr = io_kiocb_to_cmd(req, struct io_sr_msg); sr->done_io =0 ; - sr->retry = false; + sr->retry_flags =0 ;if (req->opcode ==IORING_OP_SEND ) {if (READ_ONCE (sqe->__pad3[0 ]))
@@ -783,7 +788,7 @@ int io_recvmsg_prep(struct io_kiocb *req struct io_sr_msg *sr = io_kiocb_to_cmd(req, struct io_sr_msg); sr->done_io =0 ; - sr->retry = false; + sr->retry_flags =0 ;if (unlikely (sqe->file_index || sqe->addr2))return -EINVAL ;
@@ -856,7 +861,7 @@ static inline bool io_recv_finish(struct cflags |=io_put_kbufs (req, this_ret,io_bundle_nbufs (kmsg, this_ret), issue_flags); -if (sr->retry) +if (sr->retry_flags &IO_SR_MSG_RETRY ) cflags = req->cqe.flags | (cflags &CQE_F_MASK );/* bundle with no more immediate buffers, we're done */ if (req->flags &REQ_F_BL_EMPTY )
@@ -865,12 +870,12 @@ static inline bool io_recv_finish(struct* If more is available AND it was a full transfer, retry and * append to this one */ -if (!sr->retry && kmsg->msg.msg_inq >1 && this_ret >0 && +if (!sr->retry_flags && kmsg->msg.msg_inq >1 && this_ret >0 && !iov_iter_count (&kmsg->msg.msg_iter)) { req->cqe.flags = cflags & ~CQE_F_MASK ; sr->len = kmsg->msg.msg_inq; sr->done_io += this_ret; - sr->retry = true; + sr->retry_flags |=IO_SR_MSG_RETRY ;return false; } }else {
@@ -1123,6 +1128,8 @@ static int io_recv_buf_select(struct io_ kmsg->free_iov = arg.iovs; req->flags |=REQ_F_NEED_CLEANUP ; } +if (arg.partial_map) + sr->retry_flags |=IO_SR_MSG_PARTIAL_MAP ;/* special case 1 vec, can be a fast path */ if (ret ==1 ) {
@@ -1252,7 +1259,7 @@ int io_send_zc_prep(struct io_kiocb *reqstruct io_kiocb *notif; zc->done_io =0 ; - zc->retry = false; + zc->retry_flags =0 ; req->flags |=REQ_F_POLL_NO_LAZY ;if (unlikely (READ_ONCE (sqe->__pad2[0 ]) ||READ_ONCE (sqe->addr3)))
Greg Kroah-Hartman
maintainerPATCH 190/218 mm/vma: reset VMA iterator on commit_merge() OOM failure
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lorenzo Stoakes <[email protected]>
commit 0cf4b1687a187ba9247c71721d8b064634eda1f7 upstream.
While an OOM failure in commit_merge() isn't really feasible due to the allocation which might fail (a maple tree pre-allocation) being 'too small to fail', we do need to handle this case correctly regardless.
In vma_merge_existing_range(), we can theoretically encounter failures which result in an OOM error in two ways - firstly dup_anon_vma() might fail with an OOM error, and secondly commit_merge() failing, ultimately, to pre-allocate a maple tree node.
The abort logic for dup_anon_vma() resets the VMA iterator to the initial range, ensuring that any logic looping on this iterator will correctly proceed to the next VMA.
However the commit_merge() abort logic does not do the same thing. This resulted in a syzbot report occurring because mlockall() iterates through VMAs, is tolerant of errors, but ended up with an incorrect previous VMA being specified due to incorrect iterator state.
While making this change, it became apparent we are duplicating logic - the logic introduced in commit 41e6ddcaa0f1 ("mm/vma: add give_up_on_oom option on modify/merge, use in uffd release") duplicates the vmg->give_up_on_oom check in both abort branches.
Additionally, we observe that we can perform the anon_dup check safely on dup_anon_vma() failure, as this will not be modified should this call fail.
Finally, we need to reset the iterator in both cases, so now we can simply use the exact same code to abort for both.
We remove the VM_WARN_ON(err != -ENOMEM) as it would be silly for this to be otherwise and it allows us to implement the abort check more neatly.
--- mm/vma.c | 27 ++++++++------------------- 1 file changed, 8 insertions(+), 19 deletions(-)
mm/vma.c +8 -19
@@ -836,9 +836,6 @@ static struct vm_area_struct *vma_merge_ err =dup_anon_vma (next, vma, &anon_dup); } -if (err) - goto abort; -/* * In nearly all cases, we expand vmg->vma. There is one exception - * merge_right where we partially span the VMA. In this case we shrink
@@ -846,22 +843,11 @@ static struct vm_area_struct *vma_merge_*/ expanded = !merge_right || merge_will_delete_vma; -if (commit_merge (vmg, adjust, - merge_will_delete_vma ? vma :NULL , - merge_will_delete_next ? next :NULL , - adj_start, expanded)) { -if (anon_dup) -unlink_anon_vmas (anon_dup); - -/* -* We've cleaned up any cloned anon_vma's, no VMAs have been -* modified, no harm no foul if the user requests that we not -* report this and just give up, leaving the VMAs unmerged. -*/ -if (!vmg->give_up_on_oom) - vmg->state =VMA_MERGE_ERROR_NOMEM ; -return NULL ; - } +if (err ||commit_merge (vmg, adjust, + merge_will_delete_vma ? vma :NULL , + merge_will_delete_next ? next :NULL , + adj_start, expanded)) + goto abort; res = merge_left ? prev : next;khugepaged_enter_vma (res, vmg->flags);
@@ -873,6 +859,9 @@ abort:vma_iter_set (vmg->vmi, start);vma_iter_load (vmg->vmi); +if (anon_dup) +unlink_anon_vmas (anon_dup); +/* * This means we have failed to clone anon_vma's correctly, but no * actual changes to VMAs have occurred, so no harm no foul - if the
Greg Kroah-Hartman
maintainerPATCH 191/218 r8169: add support for RTL8125D
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
commit f75d1fbe7809bc5ed134204b920fd9e2fc5db1df upstream.
This adds support for new chip version RTL8125D, which can be found on boards like Gigabyte X870E AORUS ELITE WIFI7. Firmware rtl8125d-1.fw for this chip version is available in linux-firmware already.
--- drivers/net/ethernet/realtek/r8169.h | 1 + drivers/net/ethernet/realtek/r8169_main.c | 23 ++++++++++++++++------- drivers/net/ethernet/realtek/r8169_phy_config.c | 10 ++++++++++ 3 files changed, 27 insertions(+), 7 deletions(-)
drivers/net/ethernet/realtek/r8169.h +1 -0
@@ -68,6 +68,7 @@ enum mac_version {/* support for RTL_GIGA_MAC_VER_60 has been removed */ RTL_GIGA_MAC_VER_61 ,RTL_GIGA_MAC_VER_63 , +RTL_GIGA_MAC_VER_64 ,RTL_GIGA_MAC_VER_65 ,RTL_GIGA_MAC_VER_66 ,RTL_GIGA_MAC_NONE
drivers/net/ethernet/realtek/r8169_main.c +16 -7
@@ -55,6 +55,7 @@#define FIRMWARE_8107E_2 "rtl_nic/rtl8107e-2.fw"#define FIRMWARE_8125A_3 "rtl_nic/rtl8125a-3.fw"#define FIRMWARE_8125B_2 "rtl_nic/rtl8125b-2.fw" +#define FIRMWARE_8125D_1 "rtl_nic/rtl8125d-1.fw"#define FIRMWARE_8126A_2 "rtl_nic/rtl8126a-2.fw"#define FIRMWARE_8126A_3 "rtl_nic/rtl8126a-3.fw"
@@ -138,6 +139,7 @@ static const struct { [RTL_GIGA_MAC_VER_61 ] = {"RTL8125A" ,FIRMWARE_8125A_3 }, /* reserve 62 for CFG_METHOD_4 in the vendor driver */ [RTL_GIGA_MAC_VER_63] = {"RTL8125B", FIRMWARE_8125B_2}, + [RTL_GIGA_MAC_VER_64] = {"RTL8125D", FIRMWARE_8125D_1}, [RTL_GIGA_MAC_VER_65] = {"RTL8126A", FIRMWARE_8126A_2}, [RTL_GIGA_MAC_VER_66] = {"RTL8126A", FIRMWARE_8126A_3}, };
@@ -707,6 +709,7 @@ MODULE_FIRMWARE(FIRMWARE_8168FP_3);MODULE_FIRMWARE (FIRMWARE_8107E_2 );MODULE_FIRMWARE (FIRMWARE_8125A_3 );MODULE_FIRMWARE (FIRMWARE_8125B_2 ); +MODULE_FIRMWARE (FIRMWARE_8125D_1 );MODULE_FIRMWARE (FIRMWARE_8126A_2 );MODULE_FIRMWARE (FIRMWARE_8126A_3 );
@@ -2098,10 +2101,7 @@ static void rtl_set_eee_txidle_timer(str tp->tx_lpi_timer = timer_val;r8168_mac_ocp_write (tp,0xe048 , timer_val);break ; -case RTL_GIGA_MAC_VER_61 : -case RTL_GIGA_MAC_VER_63 : -case RTL_GIGA_MAC_VER_65 : -case RTL_GIGA_MAC_VER_66 : + case RTL_GIGA_MAC_VER_61 ... RTL_GIGA_MAC_VER_66: tp->tx_lpi_timer = timer_val;RTL_W16 (tp,EEE_TXIDLE_TIMER_8125 , timer_val);break ;
@@ -2233,6 +2233,9 @@ static enum mac_version rtl8169_get_mac_ { 0x7cf, 0x64a, RTL_GIGA_MAC_VER_66 }, { 0x7cf, 0x649, RTL_GIGA_MAC_VER_65 }, +/* 8125D family. */ + { 0x7cf, 0x688, RTL_GIGA_MAC_VER_64 }, +/* 8125B family. */ { 0x7cf, 0x641, RTL_GIGA_MAC_VER_63 },
@@ -2500,9 +2503,7 @@ static void rtl_init_rxcfg(struct rtl816case RTL_GIGA_MAC_VER_61 :RTL_W32 (tp, RxConfig,RX_FETCH_DFLT_8125 |RX_DMA_BURST );break ; -case RTL_GIGA_MAC_VER_63 : -case RTL_GIGA_MAC_VER_65 : -case RTL_GIGA_MAC_VER_66 : + case RTL_GIGA_MAC_VER_63 ... RTL_GIGA_MAC_VER_66:RTL_W32 (tp, RxConfig,RX_FETCH_DFLT_8125 |RX_DMA_BURST |RX_PAUSE_SLOT_ON );break ;
@@ -3840,6 +3841,12 @@ static void rtl_hw_start_8125b(struct rtrtl_hw_start_8125_common (tp); } +static void rtl_hw_start_8125d (struct rtl8169_private *tp) +{ +rtl_set_def_aspm_entry_latency (tp); +rtl_hw_start_8125_common (tp); +} +static void rtl_hw_start_8126a (struct rtl8169_private *tp) {rtl_disable_zrxdc_timeout (tp);
@@ -3889,6 +3896,7 @@ static void rtl_hw_config(struct rtl8169 [RTL_GIGA_MAC_VER_53] = rtl_hw_start_8117, [RTL_GIGA_MAC_VER_61] = rtl_hw_start_8125a_2, [RTL_GIGA_MAC_VER_63] = rtl_hw_start_8125b, + [RTL_GIGA_MAC_VER_64] = rtl_hw_start_8125d, [RTL_GIGA_MAC_VER_65] = rtl_hw_start_8126a, [RTL_GIGA_MAC_VER_66] = rtl_hw_start_8126a, };
@@ -3906,6 +3914,7 @@ static void rtl_hw_start_8125(struct rtl/* disable interrupt coalescing */ switch (tp->mac_version) {case RTL_GIGA_MAC_VER_61 : +case RTL_GIGA_MAC_VER_64 :for (i =0xa00 ; i <0xb00 ; i +=4 )RTL_W32 (tp, i,0 );break ;
drivers/net/ethernet/realtek/r8169_phy_config.c +10 -0
@@ -1104,6 +1104,15 @@ static void rtl8125b_hw_phy_config(strucrtl8125b_config_eee_phy (phydev); } +static void rtl8125d_hw_phy_config (struct rtl8169_private *tp, +struct phy_device *phydev) +{ +r8169_apply_firmware (tp); +rtl8125_legacy_force_mode (phydev); +rtl8168g_disable_aldps (phydev); +rtl8125b_config_eee_phy (phydev); +} +static void rtl8126a_hw_phy_config (struct rtl8169_private *tp,struct phy_device *phydev) {
@@ -1160,6 +1169,7 @@ void r8169_hw_phy_config(struct rtl8169_ [RTL_GIGA_MAC_VER_53] = rtl8117_hw_phy_config, [RTL_GIGA_MAC_VER_61] = rtl8125a_2_hw_phy_config, [RTL_GIGA_MAC_VER_63] = rtl8125b_hw_phy_config, + [RTL_GIGA_MAC_VER_64] = rtl8125d_hw_phy_config, [RTL_GIGA_MAC_VER_65] = rtl8126a_hw_phy_config, [RTL_GIGA_MAC_VER_66] = rtl8126a_hw_phy_config, };
Greg Kroah-Hartman
maintainerPATCH 192/218 net: phy: realtek: merge the drivers for internal NBase-T PHYs
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
commit f87a17ed3b51fba4dfdd8f8b643b5423a85fc551 upstream.
The Realtek RTL8125/RTL8126 NBase-T MAC/PHY chips have internal PHY's which are register-compatible, at least for the registers we use here. So let's use just one PHY driver to support all of them. These internal PHY's exist also as external C45 PHY's, but on the internal PHY's no access to MMD registers is possible. This can be used to differentiate between the internal and external version.
As a side effect the drivers for two now external-only drivers don't require read_mmd/write_mmd hooks any longer.
--- drivers/net/phy/realtek.c | 53 +++++++++++++++++++++++++++++++++++++--------- 1 file changed, 43 insertions(+), 10 deletions(-)
drivers/net/phy/realtek.c +43 -10
@@ -92,6 +92,7 @@#define RTL_GENERIC_PHYID 0x001cc800#define RTL_8211FVD_PHYID 0x001cc878 +#define RTL_8221B 0x001cc840#define RTL_8221B_VB_CG 0x001cc849#define RTL_8221B_VN_CG 0x001cc84a#define RTL_8251B 0x001cc862
@@ -1040,6 +1041,23 @@ static bool rtlgen_supports_2_5gbps(strureturn val >=0 && val &MDIO_PMA_SPEED_2_5G ; } +/* On internal PHY's MMD reads over C22 always return 0. +* Check a MMD register which is known to be non-zero. +*/ +static bool rtlgen_supports_mmd (struct phy_device *phydev) +{ +int val; + +phy_lock_mdio_bus (phydev); +__phy_write (phydev,MII_MMD_CTRL ,MDIO_MMD_PCS ); +__phy_write (phydev,MII_MMD_DATA ,MDIO_PCS_EEE_ABLE ); +__phy_write (phydev,MII_MMD_CTRL ,MDIO_MMD_PCS |MII_MMD_CTRL_NOINCR ); + val =__phy_read (phydev,MII_MMD_DATA ); +phy_unlock_mdio_bus (phydev); + +return val >0 ; +} +static int rtlgen_match_phy_device (struct phy_device *phydev) { return phydev->phy_id == RTL_GENERIC_PHYID &&
@@ -1049,7 +1067,8 @@ static int rtlgen_match_phy_device(strucstatic int rtl8226_match_phy_device (struct phy_device *phydev) {return phydev->phy_id ==RTL_GENERIC_PHYID && -rtlgen_supports_2_5gbps (phydev); +rtlgen_supports_2_5gbps (phydev) && +rtlgen_supports_mmd (phydev); } static int rtlgen_is_c45_match(struct phy_device *phydev, unsigned int id,
@@ -1061,6 +1080,11 @@ static int rtlgen_is_c45_match(struct phreturn !is_c45 && (id == phydev->phy_id); } +static int rtl8221b_match_phy_device (struct phy_device *phydev) +{ +return phydev->phy_id ==RTL_8221B &&rtlgen_supports_mmd (phydev); +} +static int rtl8221b_vb_cg_c22_match_phy_device (struct phy_device *phydev) {return rtlgen_is_c45_match (phydev,RTL_8221B_VB_CG , false);
@@ -1081,9 +1105,21 @@ static int rtl8221b_vn_cg_c45_match_phy_return rtlgen_is_c45_match (phydev,RTL_8221B_VN_CG , true); } -static int rtl8251b_c22_match_phy_device (struct phy_device *phydev) +static int rtl_internal_nbaset_match_phy_device (struct phy_device *phydev) { -return rtlgen_is_c45_match (phydev,RTL_8251B , false); +if (phydev->is_c45) +return false; + +switch (phydev->phy_id) { +case RTL_GENERIC_PHYID : +case RTL_8221B : +case RTL_8251B : +break ; +default : +return false; + } + +return rtlgen_supports_2_5gbps (phydev) && !rtlgen_supports_mmd (phydev); }static int rtl8251b_c45_match_phy_device (struct phy_device *phydev)
@@ -1345,10 +1381,8 @@ static struct phy_driver realtek_drvs[] .resume = rtlgen_resume, .read_page = rtl821x_read_page, .write_page = rtl821x_write_page, - .read_mmd = rtl822x_read_mmd, - .write_mmd = rtl822x_write_mmd, }, { - PHY_ID_MATCH_EXACT(0x001cc840), + .match_phy_device = rtl8221b_match_phy_device, .name = "RTL8226B_RTL8221B 2.5Gbps PHY", .get_features = rtl822x_get_features, .config_aneg = rtl822x_config_aneg,
@@ -1359,8 +1393,6 @@ static struct phy_driver realtek_drvs[] .resume = rtlgen_resume, .read_page = rtl821x_read_page, .write_page = rtl821x_write_page, - .read_mmd = rtl822x_read_mmd, - .write_mmd = rtl822x_write_mmd, }, { PHY_ID_MATCH_EXACT(0x001cc838), .name = "RTL8226-CG 2.5Gbps PHY",
@@ -1438,8 +1470,9 @@ static struct phy_driver realtek_drvs[] .read_page = rtl821x_read_page, .write_page = rtl821x_write_page, }, { - .match_phy_device = rtl8251b_c22_match_phy_device, - .name = "RTL8126A-internal 5Gbps PHY", + .match_phy_device = rtl_internal_nbaset_match_phy_device, + .name = "Realtek Internal NBASE-T PHY", + .flags = PHY_IS_INTERNAL, .get_features = rtl822x_get_features, .config_aneg = rtl822x_config_aneg, .read_status = rtl822x_read_status,
Greg Kroah-Hartman
maintainerPATCH 193/218 net: phy: realtek: add RTL8125D-internal PHY
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
commit 8989bad541133c43550bff2b80edbe37b8fb9659 upstream.
The first boards show up with Realtek's RTL8125D. This MAC/PHY chip comes with an integrated 2.5Gbps PHY with ID 0x001cc841. It's not clear yet whether there's an external version of this PHY and how Realtek calls it, therefore use the numeric id for now.
Message-ID: <[email protected]>
--- drivers/net/phy/realtek.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/phy/realtek.c +1 -0
@@ -1114,6 +1114,7 @@ static int rtl_internal_nbaset_match_phycase RTL_GENERIC_PHYID :case RTL_8221B :case RTL_8251B : +case 0x001cc841 :break ;default :return false;
Greg Kroah-Hartman
maintainerPATCH 194/218 btrfs: do proper folio cleanup when cow_file_range() failed
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
[ Upstream commit 06f364284794f149d2abc167c11d556cf20c954b ]
[BUG]
When testing with COW fixup marked as BUG_ON() (this is involved with the new pin_user_pages*() change, which should not result new out-of-band dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW fixup path.
This BUG_ON() happens just after a failed btrfs_run_delalloc_range():
BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28
------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1444! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G OE 6.12.0-rc7-custom+ #86 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : extent_writepage_io+0x2d4/0x308 [btrfs] lr : extent_writepage_io+0x2d4/0x308 [btrfs] Call trace: extent_writepage_io+0x2d4/0x308 [btrfs] extent_writepage+0x218/0x330 [btrfs] extent_write_cache_pages+0x1d4/0x4b0 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x180/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000) ---[ end trace 0000000000000000 ]---
[CAUSE]
That failure is mostly from cow_file_range(), where we can hit -ENOSPC.
Although the -ENOSPC is already a bug related to our space reservation code, let's just focus on the error handling.
For example, we have the following dirty range [0, 64K) of an inode, with 4K sector size and 4K page size:
0 16K 32K 48K 64K |///////////////////////////////////////| |#######################################|
Where |///| means page are still dirty, and |###| means the extent io tree has EXTENT_DELALLOC flag.
- Enter extent_writepage() for page 0
- Enter btrfs_run_delalloc_range() for range [0, 64K)
- Enter cow_file_range() for range [0, 64K)
- Function btrfs_reserve_extent() only reserved one 16K extent So we created extent map and ordered extent for range [0, 16K)
0 16K 32K 48K 64K |////////|//////////////////////////////| |<- OE ->|##############################|
And range [0, 16K) has its delalloc flag cleared.
But since we haven't yet submit any bio, involved 4 pages are still dirty.
- Function btrfs_reserve_extent() returns with -ENOSPC Now we have to run error cleanup, which will clear all EXTENT_DELALLOC* flags and clear the dirty flags for the remaining ranges:
0 16K 32K 48K 64K |////////| | | | |
Note that range [0, 16K) still has its pages dirty.
- Some time later, writeback is triggered again for the range [0, 16K) since the page range still has dirty flags.
- btrfs_run_delalloc_range() will do nothing because there is no EXTENT_DELALLOC flag.
- extent_writepage_io() finds page 0 has no ordered flag Which falls into the COW fixup path, triggering the BUG_ON().
Unfortunately this error handling bug dates back to the introduction of btrfs. Thankfully with the abuse of COW fixup, at least it won't crash the kernel.
[FIX]
Instead of immediately unlocking the extent and folios, we keep the extent and folios locked until either erroring out or the whole delalloc range finished.
When the whole delalloc range finished without error, we just unlock the whole range with PAGE_SET_ORDERED (and PAGE_UNLOCK for !keep_locked cases), with EXTENT_DELALLOC and EXTENT_LOCKED cleared.
And the involved folios will be properly submitted, with their dirty flags cleared during submission.
For the error path, it will be a little more complex:
- The range with ordered extent allocated (range (1))
We only clear the EXTENT_DELALLOC and EXTENT_LOCKED, as the remaining flags are cleaned up by btrfs_mark_ordered_io_finished()->btrfs_finish_one_ordered().
For folios we finish the IO (clear dirty, start writeback and immediately finish the writeback) and unlock the folios.
- The range with reserved extent but no ordered extent (range(2))
- The range we never touched (range(3))
For both range (2) and range(3) the behavior is not changed.
Now even if cow_file_range() failed halfway with some successfully reserved extents/ordered extents, we will keep all folios clean, so there will be no future writeback triggered on them.
--- fs/btrfs/inode.c | 77 +++++++++++++++++++++++------------------------- 1 file changed, 37 insertions(+), 40 deletions(-)
fs/btrfs/inode.c +37 -40
@@ -1408,6 +1408,17 @@ static noinline int cow_file_range(struct btrfs_inode *inode, alloc_hint =btrfs_get_extent_allocation_hint (inode, start, num_bytes); +/* +* We're not doing compressed IO, don't unlock the first page (which +* the caller expects to stay locked), don't clear any dirty bits and +* don't set any writeback bits. +* +* Do set the Ordered (Private2) bit so we know this page was properly +* setup for writepage. +*/ + page_ops = (keep_locked ?0 :PAGE_UNLOCK ); + page_ops |=PAGE_SET_ORDERED ; +/* * Relocation relies on the relocated extents to have exactly the same * size as the original extents. Normally writeback for relocation data
@@ -1470,6 +1481,10 @@ static noinline int cow_file_range(struct btrfs_inode *inode, file_extent.offset =0 ; file_extent.compression =BTRFS_COMPRESS_NONE ; +/* +* Locked range will be released either during error clean up or +* after the whole range is finished. +*/ lock_extent (&inode->io_tree, start, start + ram_size -1 , &cached);
@@ -1515,27 +1530,12 @@ static noinline int cow_file_range(struct btrfs_inode *inode,btrfs_dec_block_group_reservations (fs_info, ins.objectid); -/* -* We're not doing compressed IO, don't unlock the first page -* (which the caller expects to stay locked), don't clear any -* dirty bits and don't set any writeback bits -* -* Do set the Ordered (Private2) bit so we know this page was -* properly setup for writepage. -*/ - page_ops = (keep_locked ?0 :PAGE_UNLOCK ); - page_ops |=PAGE_SET_ORDERED ; - -extent_clear_unlock_delalloc (inode, start, start + ram_size -1 , - locked_folio, &cached, -EXTENT_LOCKED |EXTENT_DELALLOC , - page_ops); -if (num_bytes < cur_alloc_size) +if (num_bytes < ram_size) num_bytes =0 ;else - num_bytes -= cur_alloc_size; + num_bytes -= ram_size; alloc_hint = ins.objectid + ins.offset; - start += cur_alloc_size; + start += ram_size; extent_reserved = false;/*
@@ -1546,6 +1546,8 @@ static noinline int cow_file_range(struct btrfs_inode *inode,if (ret) goto out_unlock; } +extent_clear_unlock_delalloc (inode, orig_start, end, locked_folio, &cached, +EXTENT_LOCKED |EXTENT_DELALLOC , page_ops); done:if (done_offset) *done_offset = end;
@@ -1561,40 +1563,35 @@ static noinline int cow_file_range(struct btrfs_inode *inode,* Now, we have three regions to clean up: * * |-------(1)----|---(2)---|-------------(3)----------| -* `- orig_start `- start `- start + cur_alloc_size `- end +* `- orig_start `- start `- start + ram_size `- end * * We process each region below. */ - clear_bits =EXTENT_LOCKED |EXTENT_DELALLOC |EXTENT_DELALLOC_NEW | -EXTENT_DEFRAG |EXTENT_CLEAR_META_RESV ; - page_ops =PAGE_UNLOCK |PAGE_START_WRITEBACK |PAGE_END_WRITEBACK ; -/* * For the range (1). We have already instantiated the ordered extents * for this region. They are cleaned up by * btrfs_cleanup_ordered_extents() in e.g, -* btrfs_run_delalloc_range(). EXTENT_LOCKED | EXTENT_DELALLOC are -* already cleared in the above loop. And, EXTENT_DELALLOC_NEW | -* EXTENT_DEFRAG | EXTENT_CLEAR_META_RESV are handled by the cleanup -* function. +* btrfs_run_delalloc_range(). +* EXTENT_DELALLOC_NEW | EXTENT_DEFRAG | EXTENT_CLEAR_META_RESV +* are also handled by the cleanup function. * -* However, in case of @keep_locked, we still need to unlock the pages -* (except @locked_folio) to ensure all the pages are unlocked. +* So here we only clear EXTENT_LOCKED and EXTENT_DELALLOC flag, and +* finish the writeback of the involved folios, which will be never submitted. */ -if (keep_locked && orig_start < start) { +if (orig_start < start) { + clear_bits =EXTENT_LOCKED |EXTENT_DELALLOC ; + page_ops =PAGE_UNLOCK |PAGE_START_WRITEBACK |PAGE_END_WRITEBACK ; +if (!locked_folio)mapping_set_error (inode->vfs_inode.i_mapping, ret);extent_clear_unlock_delalloc (inode, orig_start, start -1 , - locked_folio,NULL ,0 , page_ops); + locked_folio,NULL , clear_bits, page_ops); } -/* -* At this point we're unlocked, we want to make sure we're only -* clearing these flags under the extent lock, so lock the rest of the -* range and clear everything up. -*/ -lock_extent (&inode->io_tree, start, end,NULL ); + clear_bits =EXTENT_LOCKED |EXTENT_DELALLOC |EXTENT_DELALLOC_NEW | +EXTENT_DEFRAG |EXTENT_CLEAR_META_RESV ; + page_ops =PAGE_UNLOCK |PAGE_START_WRITEBACK |PAGE_END_WRITEBACK ;/* * For the range (2). If we reserved an extent for our delalloc range
@@ -1608,11 +1605,11 @@ static noinline int cow_file_range(struct btrfs_inode *inode,*/ if (extent_reserved) {extent_clear_unlock_delalloc (inode, start, - start + cur_alloc_size -1 , + start + ram_size -1 , locked_folio, &cached, clear_bits, page_ops); -btrfs_qgroup_free_data (inode,NULL , start, cur_alloc_size,NULL ); - start += cur_alloc_size; +btrfs_qgroup_free_data (inode,NULL , start, ram_size,NULL ); + start += ram_size; }/*
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 195/218 iio: dac: ad3552r: changes to use FIELD_PREP
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Angelo Dureghello <[email protected]>
[ Upstream commit d5ac6cb1c8f3e14d93e2a50d9357a8acdbc5c166 ]
Changes to use FIELD_PREP, so that driver-specific ad3552r_field_prep is removed. Variables (arrays) that was used to call ad3552r_field_prep are removed too.
--- drivers/iio/dac/ad3552r.c | 167 ++++++++++++-------------------------- 1 file changed, 50 insertions(+), 117 deletions(-)
drivers/iio/dac/ad3552r.c +50 -117
@@ -6,6 +6,7 @@* Copyright 2021 Analog Devices Inc. */ #include <linux/unaligned.h> +#include <linux/bitfield.h> #include <linux/device.h> #include <linux/iio/triggered_buffer.h> #include <linux/iio/trigger_consumer.h>
@@ -210,46 +211,6 @@ static const s32 gains_scaling_table[] = { [AD3552R_CH_GAIN_SCALING_0_125 ] =125 }; -enum ad3552r_dev_attributes { -/* - Direct register values */ -/* From 0-3 */ -AD3552R_SDO_DRIVE_STRENGTH , -/* -* 0 -> Internal Vref, vref_io pin floating (default) -* 1 -> Internal Vref, vref_io driven by internal vref -* 2 or 3 -> External Vref -*/ -AD3552R_VREF_SELECT , -/* Read registers in ascending order if set. Else descending */ -AD3552R_ADDR_ASCENSION , -}; - -enum ad3552r_ch_attributes { -/* DAC powerdown */ -AD3552R_CH_DAC_POWERDOWN , -/* DAC amplifier powerdown */ -AD3552R_CH_AMPLIFIER_POWERDOWN , -/* Select the output range. Select from enum ad3552r_ch_output_range */ -AD3552R_CH_OUTPUT_RANGE_SEL , -/* -* Over-rider the range selector in order to manually set the output -* voltage range -*/ -AD3552R_CH_RANGE_OVERRIDE , -/* Manually set the offset voltage */ -AD3552R_CH_GAIN_OFFSET , -/* Sets the polarity of the offset. */ -AD3552R_CH_GAIN_OFFSET_POLARITY , -/* PDAC gain scaling */ -AD3552R_CH_GAIN_SCALING_P , -/* NDAC gain scaling */ -AD3552R_CH_GAIN_SCALING_N , -/* Rfb value */ -AD3552R_CH_RFB , -/* Channel select. When set allow Input -> DAC and Mask -> DAC */ -AD3552R_CH_SELECT , -}; -struct ad3552r_ch_data {s32 scale_int;s32 scale_dec;
@@ -285,45 +246,6 @@ struct ad3552r_desc {unsigned int num_ch; }; -static const u16 addr_mask_map[][2 ] = { - [AD3552R_ADDR_ASCENSION ] = { -AD3552R_REG_ADDR_INTERFACE_CONFIG_A , -AD3552R_MASK_ADDR_ASCENSION - }, - [AD3552R_SDO_DRIVE_STRENGTH ] = { -AD3552R_REG_ADDR_INTERFACE_CONFIG_D , -AD3552R_MASK_SDO_DRIVE_STRENGTH - }, - [AD3552R_VREF_SELECT ] = { -AD3552R_REG_ADDR_SH_REFERENCE_CONFIG , -AD3552R_MASK_REFERENCE_VOLTAGE_SEL - }, -}; - -/* 0 -> reg addr, 1->ch0 mask, 2->ch1 mask */ -static const u16 addr_mask_map_ch[][3 ] = { - [AD3552R_CH_DAC_POWERDOWN ] = { -AD3552R_REG_ADDR_POWERDOWN_CONFIG , -AD3552R_MASK_CH_DAC_POWERDOWN (0 ), -AD3552R_MASK_CH_DAC_POWERDOWN (1 ) - }, - [AD3552R_CH_AMPLIFIER_POWERDOWN ] = { -AD3552R_REG_ADDR_POWERDOWN_CONFIG , -AD3552R_MASK_CH_AMPLIFIER_POWERDOWN (0 ), -AD3552R_MASK_CH_AMPLIFIER_POWERDOWN (1 ) - }, - [AD3552R_CH_OUTPUT_RANGE_SEL ] = { -AD3552R_REG_ADDR_CH0_CH1_OUTPUT_RANGE , -AD3552R_MASK_CH_OUTPUT_RANGE_SEL (0 ), -AD3552R_MASK_CH_OUTPUT_RANGE_SEL (1 ) - }, - [AD3552R_CH_SELECT ] = { -AD3552R_REG_ADDR_CH_SELECT_16B , -AD3552R_MASK_CH (0 ), -AD3552R_MASK_CH (1 ) - } -}; -static u8 _ad3552r_reg_len (u8 addr) {switch (addr) {
@@ -399,11 +321,6 @@ static int ad3552r_read_reg(struct ad3552r_desc *dac, u8 addr, u16 *val)return 0 ; } -static u16 ad3552r_field_prep (u16 val,u16 mask) -{ -return (val <<__ffs (mask)) & mask; -} -/* Update field of a register, shift val if needed */ static int ad3552r_update_reg_field (struct ad3552r_desc *dac,u8 addr,u16 mask,u16 val)
@@ -416,21 +333,11 @@ static int ad3552r_update_reg_field(struct ad3552r_desc *dac, u8 addr, u16 mask,return ret; reg &= ~mask; - reg |=ad3552r_field_prep (val, mask); + reg |= val;return ad3552r_write_reg (dac, addr, reg); } -static int ad3552r_set_ch_value (struct ad3552r_desc *dac, -enum ad3552r_ch_attributes attr, -u8 ch, -u16 val) -{ -/* Update register related to attributes in chip */ -return ad3552r_update_reg_field (dac, addr_mask_map_ch[attr][0 ], - addr_mask_map_ch[attr][ch +1 ], val); -} -#define AD3552R_CH_DAC (_idx) ((struct iio_chan_spec) { \ .type = IIO_VOLTAGE, \ .output = true, \
@@ -510,8 +417,14 @@ static int ad3552r_write_raw(struct iio_dev *indio_dev, val);break ;case IIO_CHAN_INFO_ENABLE : - err =ad3552r_set_ch_value (dac,AD3552R_CH_DAC_POWERDOWN , - chan->channel, !val); +if (chan->channel ==0 ) + val =FIELD_PREP (AD3552R_MASK_CH_DAC_POWERDOWN (0 ), !val); +else + val =FIELD_PREP (AD3552R_MASK_CH_DAC_POWERDOWN (1 ), !val); + + err =ad3552r_update_reg_field (dac,AD3552R_REG_ADDR_POWERDOWN_CONFIG , +AD3552R_MASK_CH_DAC_POWERDOWN (chan->channel), + val);break ;default : err = -EINVAL ;
@@ -721,9 +634,9 @@ static int ad3552r_reset(struct ad3552r_desc *dac)return ret;return ad3552r_update_reg_field (dac, - addr_mask_map[AD3552R_ADDR_ASCENSION ][0 ], - addr_mask_map[AD3552R_ADDR_ASCENSION ][1 ], - val); +AD3552R_REG_ADDR_INTERFACE_CONFIG_A , +AD3552R_MASK_ADDR_ASCENSION , +FIELD_PREP (AD3552R_MASK_ADDR_ASCENSION , val)); } static void ad3552r_get_custom_range(struct ad3552r_desc *dac, s32 i, s32 *v_min,
@@ -818,20 +731,20 @@ static int ad3552r_configure_custom_gain(struct ad3552r_desc *dac, "mandatory custom-output-range-config property missing\n"); dac->ch_data[ch].range_override =1 ; - reg |=ad3552r_field_prep (1 ,AD3552R_MASK_CH_RANGE_OVERRIDE ); + reg |=FIELD_PREP (AD3552R_MASK_CH_RANGE_OVERRIDE ,1 ); err =fwnode_property_read_u32 (gain_child,"adi,gain-scaling-p" , &val);if (err)return dev_err_probe (dev, err,"mandatory adi,gain-scaling-p property missing\n" ); - reg |=ad3552r_field_prep (val,AD3552R_MASK_CH_GAIN_SCALING_P ); + reg |=FIELD_PREP (AD3552R_MASK_CH_GAIN_SCALING_P , val); dac->ch_data[ch].p = val; err =fwnode_property_read_u32 (gain_child,"adi,gain-scaling-n" , &val);if (err)return dev_err_probe (dev, err,"mandatory adi,gain-scaling-n property missing\n" ); - reg |=ad3552r_field_prep (val,AD3552R_MASK_CH_GAIN_SCALING_N ); + reg |=FIELD_PREP (AD3552R_MASK_CH_GAIN_SCALING_N , val); dac->ch_data[ch].n = val; err =fwnode_property_read_u32 (gain_child,"adi,rfb-ohms" , &val);
@@ -847,9 +760,9 @@ static int ad3552r_configure_custom_gain(struct ad3552r_desc *dac, dac->ch_data[ch].gain_offset = val; offset =abs ((s32 )val); - reg |=ad3552r_field_prep ((offset >>8 ),AD3552R_MASK_CH_OFFSET_BIT_8 ); + reg |=FIELD_PREP (AD3552R_MASK_CH_OFFSET_BIT_8 , (offset >>8 )); - reg |=ad3552r_field_prep ((s32 )val <0 ,AD3552R_MASK_CH_OFFSET_POLARITY ); + reg |=FIELD_PREP (AD3552R_MASK_CH_OFFSET_POLARITY , (s32 )val <0 ); addr =AD3552R_REG_ADDR_CH_GAIN (ch); err =ad3552r_write_reg (dac, addr, offset &AD3552R_MASK_CH_OFFSET_BITS_0_7 );
@@ -892,9 +805,9 @@ static int ad3552r_configure_device(struct ad3552r_desc *dac) } err =ad3552r_update_reg_field (dac, - addr_mask_map[AD3552R_VREF_SELECT ][0 ], - addr_mask_map[AD3552R_VREF_SELECT ][1 ], - val); +AD3552R_REG_ADDR_SH_REFERENCE_CONFIG , +AD3552R_MASK_REFERENCE_VOLTAGE_SEL , +FIELD_PREP (AD3552R_MASK_REFERENCE_VOLTAGE_SEL , val));if (err)return err;
@@ -906,9 +819,9 @@ static int ad3552r_configure_device(struct ad3552r_desc *dac) } err =ad3552r_update_reg_field (dac, - addr_mask_map[AD3552R_SDO_DRIVE_STRENGTH ][0 ], - addr_mask_map[AD3552R_SDO_DRIVE_STRENGTH ][1 ], - val); +AD3552R_REG_ADDR_INTERFACE_CONFIG_D , +AD3552R_MASK_SDO_DRIVE_STRENGTH , +FIELD_PREP (AD3552R_MASK_SDO_DRIVE_STRENGTH , val));if (err)return err; }
@@ -944,9 +857,15 @@ static int ad3552r_configure_device(struct ad3552r_desc *dac) "Invalid adi,output-range-microvolt value\n"); val = err; - err =ad3552r_set_ch_value (dac, -AD3552R_CH_OUTPUT_RANGE_SEL , - ch, val); +if (ch ==0 ) + val =FIELD_PREP (AD3552R_MASK_CH_OUTPUT_RANGE_SEL (0 ), val); +else + val =FIELD_PREP (AD3552R_MASK_CH_OUTPUT_RANGE_SEL (1 ), val); + + err =ad3552r_update_reg_field (dac, +AD3552R_REG_ADDR_CH0_CH1_OUTPUT_RANGE , +AD3552R_MASK_CH_OUTPUT_RANGE_SEL (ch), + val);if (err)return err;
@@ -964,7 +883,14 @@ static int ad3552r_configure_device(struct ad3552r_desc *dac)ad3552r_calc_gain_and_offset (dac, ch); dac->enabled_ch |=BIT (ch); - err =ad3552r_set_ch_value (dac,AD3552R_CH_SELECT , ch,1 ); +if (ch ==0 ) + val =FIELD_PREP (AD3552R_MASK_CH (0 ),1 ); +else + val =FIELD_PREP (AD3552R_MASK_CH (1 ),1 ); + + err =ad3552r_update_reg_field (dac, +AD3552R_REG_ADDR_CH_SELECT_16B , +AD3552R_MASK_CH (ch), val);if (err <0 )return err;
@@ -976,8 +902,15 @@ static int ad3552r_configure_device(struct ad3552r_desc *dac)/* Disable unused channels */ for_each_clear_bit (ch, &dac->enabled_ch, dac->model_data->num_hw_channels) { - err =ad3552r_set_ch_value (dac,AD3552R_CH_AMPLIFIER_POWERDOWN , - ch,1 ); +if (ch ==0 ) + val =FIELD_PREP (AD3552R_MASK_CH_AMPLIFIER_POWERDOWN (0 ),1 ); +else + val =FIELD_PREP (AD3552R_MASK_CH_AMPLIFIER_POWERDOWN (1 ),1 ); + + err =ad3552r_update_reg_field (dac, +AD3552R_REG_ADDR_POWERDOWN_CONFIG , +AD3552R_MASK_CH_AMPLIFIER_POWERDOWN (ch), + val);if (err)return err; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 196/218 iio: dac: ad3552r: extract common code (no changes in behavior intended)
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Angelo Dureghello <[email protected]>
[ Upstream commit f665d7d33d7909cf51e2db0f0767ecab0295c0bd ]
Extracting common code, to share common code to be used later by the AXI driver version (ad3552r-axi.c).
--- drivers/iio/dac/Makefile | 2 +- drivers/iio/dac/ad3552r-common.c | 249 +++++++++++++++++++ drivers/iio/dac/ad3552r.c | 398 +++---------------------------- drivers/iio/dac/ad3552r.h | 224 +++++++++++++++++ 4 files changed, 501 insertions(+), 372 deletions(-) create mode 100644 drivers/iio/dac/ad3552r-common.c create mode 100644 drivers/iio/dac/ad3552r.h
drivers/iio/dac/Makefile +1 -1
@@ -4,7 +4,7 @@ # # When adding new entries keep the list in alphabetical order -obj-$(CONFIG_AD3552R) += ad3552r.o +obj-$(CONFIG_AD3552R) += ad3552r.o ad3552r-common.o obj-$(CONFIG_AD5360) += ad5360.o obj-$(CONFIG_AD5380) += ad5380.o obj-$(CONFIG_AD5421) += ad5421.o
drivers/iio/dac/ad3552r-common.c new file +249 -0
249 lines not on this page · raw message
drivers/iio/dac/ad3552r.c +27 -371
463 lines not on this page · raw message
drivers/iio/dac/ad3552r.h new file +224 -0
224 lines not on this page · raw message
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 197/218 iio: dac: ad3552r-common: fix ad3541/2r ranges
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Angelo Dureghello <[email protected]>
[ Upstream commit 1e758b613212b6964518a67939535910b5aee831 ]
Fix ad3541/2r voltage ranges to be as per ad3542r datasheet, rev. C, table 38 (page 57).
The wrong ad354xr ranges was generating erroneous Vpp output.
In more details:
- fix wrong number of ranges, they are 5 ranges, not 6,
- remove non-existent 0-3V range,
- adjust order, since ad3552r_find_range() get a wrong index, producing a wrong Vpp as output.
Retested all the ranges on real hardware, EVALAD3542RFMCZ:
adi,output-range-microvolt (fdt):
<(000000) (2500000)>; ok (Rfbx1, switch 10) <(000000) (5000000)>; ok (Rfbx1, switch 10) <(000000) (10000000)>; ok (Rfbx1, switch 10)
<(-5000000) (5000000)>; ok (Rfbx2, switch +/- 5) <(-2500000) (7500000)>; ok (Rfbx2, switch -2.5/7.5)
--- drivers/iio/dac/ad3552r-common.c | 5 ++--- drivers/iio/dac/ad3552r.h | 9 ++++----- 2 files changed, 6 insertions(+), 8 deletions(-)
drivers/iio/dac/ad3552r-common.c +2 -3
@@ -22,11 +22,10 @@ EXPORT_SYMBOL_NS_GPL(ad3552r_ch_ranges, IIO_AD3552R);const s32 ad3542r_ch_ranges[AD3542R_MAX_RANGES ][2 ] = { [AD3542R_CH_OUTPUT_RANGE_0__2P5V ] = {0 ,2500 }, - [AD3542R_CH_OUTPUT_RANGE_0__3V ] = {0 ,3000 }, [AD3542R_CH_OUTPUT_RANGE_0__5V ] = {0 ,5000 }, [AD3542R_CH_OUTPUT_RANGE_0__10V ] = {0 ,10000 }, - [AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V ] = {-2500 ,7500 }, - [AD3542R_CH_OUTPUT_RANGE_NEG_5__5V ] = {-5000 ,5000 } + [AD3542R_CH_OUTPUT_RANGE_NEG_5__5V ] = {-5000 ,5000 }, + [AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V ] = {-2500 ,7500 } };EXPORT_SYMBOL_NS_GPL (ad3542r_ch_ranges,IIO_AD3552R );
drivers/iio/dac/ad3552r.h +4 -5
@@ -128,7 +128,8 @@#define AD3552R_LDAC_PULSE_US 100#define AD3552R_MAX_RANGES 5 -#define AD3542R_MAX_RANGES 6 +#define AD3542R_MAX_RANGES 5 +#define AD3552R_QUAD_SPI 2extern const s32 ad3552r_ch_ranges[AD3552R_MAX_RANGES ][2 ];extern const s32 ad3542r_ch_ranges[AD3542R_MAX_RANGES ][2 ];
@@ -185,16 +186,14 @@ enum ad3552r_ch_vref_select {enum ad3542r_ch_output_range {/* Range from 0 V to 2.5 V. Requires Rfb1x connection */ AD3542R_CH_OUTPUT_RANGE_0__2P5V , -/* Range from 0 V to 3 V. Requires Rfb1x connection */ -AD3542R_CH_OUTPUT_RANGE_0__3V ,/* Range from 0 V to 5 V. Requires Rfb1x connection */ AD3542R_CH_OUTPUT_RANGE_0__5V ,/* Range from 0 V to 10 V. Requires Rfb2x connection */ AD3542R_CH_OUTPUT_RANGE_0__10V , -/* Range from -2.5 V to 7.5 V. Requires Rfb2x connection */ -AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V ,/* Range from -5 V to 5 V. Requires Rfb2x connection */ AD3542R_CH_OUTPUT_RANGE_NEG_5__5V , +/* Range from -2.5 V to 7.5 V. Requires Rfb2x connection */ +AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V , };enum ad3552r_ch_output_range {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 198/218 drm/xe: Carve out wopcm portion from the stolen memory
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit e977499820782ab1c69f354d9f41b6d9ad1f43d9 ]
The top of stolen memory is WOPCM, which shouldn't be accessed. Remove this portion from the stolen memory region for discrete platforms. This was already done for integrated, but was missing for discrete platforms.
This also moves get_wopcm_size() so detect_bar2_dgfx() and detect_bar2_integrated can use the same function.
v2: Improve commit message and suitable stable version tag(Lucas)
--- drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c | 54 ++++++++++++++------------ 1 file changed, 30 insertions(+), 24 deletions(-)
drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c +30 -24
@@ -57,12 +57,35 @@ bool xe_ttm_stolen_cpu_access_needs_ggtt(struct xe_device *xe)return GRAPHICS_VERx100 (xe) <1270 && !IS_DGFX (xe); } +static u32 get_wopcm_size (struct xe_device *xe) +{ +u32 wopcm_size; +u64 val; + + val =xe_mmio_read64_2x32 (xe_root_mmio_gt (xe),STOLEN_RESERVED ); + val =REG_FIELD_GET64 (WOPCM_SIZE_MASK , val); + +switch (val) { + case 0x5 ... 0x6: + val--; + fallthrough; + case 0x0 ... 0x3: + wopcm_size = (1U << val) *SZ_1M ; +break ; +default : +WARN (1 ,"Missing case wopcm_size=%llx\n" , val); + wopcm_size =0 ; + } + +return wopcm_size; +} +static s64 detect_bar2_dgfx (struct xe_device *xe,struct xe_ttm_stolen_mgr *mgr) {struct xe_tile *tile =xe_device_get_root_tile (xe);struct xe_gt *mmio =xe_root_mmio_gt (xe);struct pci_dev *pdev =to_pci_dev (xe->drm.dev); -u64 stolen_size; +u64 stolen_size, wopcm_size;u64 tile_offset;u64 tile_size;
@@ -74,7 +97,13 @@ static s64 detect_bar2_dgfx(struct xe_device *xe, struct xe_ttm_stolen_mgr *mgr)if (drm_WARN_ON (&xe->drm, tile_size < mgr->stolen_base))return 0 ; +/* Carve out the top of DSM as it contains the reserved WOPCM region */ + wopcm_size =get_wopcm_size (xe); +if (drm_WARN_ON (&xe->drm, !wopcm_size)) +return 0 ; + stolen_size = tile_size - mgr->stolen_base; + stolen_size -= wopcm_size;/* Verify usage fits in the actual resource available */ if (mgr->stolen_base + stolen_size <=pci_resource_len (pdev,LMEM_BAR ))
@@ -89,29 +118,6 @@ static s64 detect_bar2_dgfx(struct xe_device *xe, struct xe_ttm_stolen_mgr *mgr)return ALIGN_DOWN (stolen_size,SZ_1M ); } -static u32 get_wopcm_size (struct xe_device *xe) -{ -u32 wopcm_size; -u64 val; - - val =xe_mmio_read64_2x32 (xe_root_mmio_gt (xe),STOLEN_RESERVED ); - val =REG_FIELD_GET64 (WOPCM_SIZE_MASK , val); - -switch (val) { - case 0x5 ... 0x6: - val--; - fallthrough; - case 0x0 ... 0x3: - wopcm_size = (1U << val) *SZ_1M ; -break ; -default : -WARN (1 ,"Missing case wopcm_size=%llx\n" , val); - wopcm_size =0 ; - } - -return wopcm_size; -} -static u32 detect_bar2_integrated (struct xe_device *xe,struct xe_ttm_stolen_mgr *mgr) {struct pci_dev *pdev =to_pci_dev (xe->drm.dev);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 199/218 usb: typec: tcpm: PSSourceOffTimer timeout in PR_Swap enters ERROR_RECOVERY
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit 659f5d55feb75782bd46cf130da3c1f240afe9ba ]
As PD2.0 spec ("6.5.6.2 PSSourceOffTimer"),the PSSourceOffTimer is used by the Policy Engine in Dual-Role Power device that is currently acting as a Sink to timeout on a PS_RDY Message during a Power Role Swap sequence. This condition leads to a Hard Reset for USB Type-A and Type-B Plugs and Error Recovery for Type-C plugs and return to USB Default Operation.
Therefore, after PSSourceOffTimer timeout, the tcpm state machine should switch from PR_SWAP_SNK_SRC_SINK_OFF to ERROR_RECOVERY. This can also solve the test items in the USB power delivery compliance test:
TEST.PD.PROT.SNK.12 PR_Swap – PSSourceOffTimer Timeout
--- drivers/usb/typec/tcpm/tcpm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/usb/typec/tcpm/tcpm.c +1 -2
@@ -5566,8 +5566,7 @@ static void run_state_machine(struct tcpm_port *port)tcpm_set_auto_vbus_discharge_threshold (port,TYPEC_PWR_MODE_USB , port->pps_data.active,0 );tcpm_set_charge (port, false); -tcpm_set_state (port,hard_reset_state (port), -PD_T_PS_SOURCE_OFF ); +tcpm_set_state (port,ERROR_RECOVERY ,PD_T_PS_SOURCE_OFF );break ;case PR_SWAP_SNK_SRC_SOURCE_ON :tcpm_enable_auto_vbus_discharge (port, true);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 200/218 drm/msm/dp: account for widebus and yuv420 during mode validation
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit df9cf852ca3099feb8fed781bdd5d3863af001c8 ]
Widebus allows the DP controller to operate in 2 pixel per clock mode. The mode validation logic validates the mode->clock against the max DP pixel clock. However the max DP pixel clock limit assumes widebus is already enabled. Adjust the mode validation logic to only compare the adjusted pixel clock which accounts for widebus against the max DP pixel clock. Also fix the mode validation logic for YUV420 modes as in that case as well, only half the pixel clock is needed.
Patchwork: https://patchwork.freedesktop.org/patch/635789/
--- drivers/gpu/drm/msm/dp/dp_display.c | 11 ++++++----- drivers/gpu/drm/msm/dp/dp_drm.c | 5 ++++- 2 files changed, 10 insertions(+), 6 deletions(-)
drivers/gpu/drm/msm/dp/dp_display.c +6 -5
@@ -928,16 +928,17 @@ enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge *bridge,return -EINVAL ; } -if (mode->clock >DP_MAX_PIXEL_CLK_KHZ ) -return MODE_CLOCK_HIGH ; - dp_display = container_of(dp, struct dp_display_private, dp_display); link_info = &dp_display->panel->link_info; -if (drm_mode_is_420_only (&dp->connector->display_info, mode) && - dp_display->panel->vsc_sdp_supported) +if ((drm_mode_is_420_only (&dp->connector->display_info, mode) && + dp_display->panel->vsc_sdp_supported) || +msm_dp_wide_bus_available (dp)) mode_pclk_khz /=2 ; +if (mode_pclk_khz >DP_MAX_PIXEL_CLK_KHZ ) +return MODE_CLOCK_HIGH ; + mode_bpp = dp->connector->display_info.bpc * num_components;if (!mode_bpp) mode_bpp = default_bpp;
drivers/gpu/drm/msm/dp/dp_drm.c +4 -1
@@ -257,7 +257,10 @@ static enum drm_mode_status edp_bridge_mode_valid(struct drm_bridge *bridge,return -EINVAL ; } -if (mode->clock >DP_MAX_PIXEL_CLK_KHZ ) +if (msm_dp_wide_bus_available (dp)) + mode_pclk_khz /=2 ; + +if (mode_pclk_khz >DP_MAX_PIXEL_CLK_KHZ )return MODE_CLOCK_HIGH ;/*
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 201/218 drm/fbdev-dma: Add shadow buffering for deferred I/O
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
[ Upstream commit 3603996432997f7c88da37a97062a46cda01ac9d ]
DMA areas are not necessarily backed by struct page, so we cannot rely on it for deferred I/O. Allocate a shadow buffer for drivers that require deferred I/O and use it as framebuffer memory.
Fixes driver errors about being "Unable to handle kernel NULL pointer dereference at virtual address" or "Unable to handle kernel paging request at virtual address".
The patch splits drm_fbdev_dma_driver_fbdev_probe() in an initial allocation, which creates the DMA-backed buffer object, and a tail that sets up the fbdev data structures. There is a tail function for direct memory mappings and a tail function for deferred I/O with the shadow buffer.
It is no longer possible to use deferred I/O without shadow buffer. It can be re-added if there exists a reliably test for usable struct page in the allocated DMA-backed buffer object.
--- drivers/gpu/drm/drm_fbdev_dma.c | 219 +++++++++++++++++++++++--------- 1 file changed, 156 insertions(+), 63 deletions(-)
drivers/gpu/drm/drm_fbdev_dma.c +156 -63
@@ -1,6 +1,7 @@// SPDX-License-Identifier: MIT #include <linux/fb.h> +#include <linux/vmalloc.h> #include <drm/drm_crtc_helper.h> #include <drm/drm_drv.h>
@@ -72,43 +73,108 @@ static const struct fb_ops drm_fbdev_dma_fb_ops = { .fb_destroy = drm_fbdev_dma_fb_destroy, }; -FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS (drm_fbdev_dma, +FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS (drm_fbdev_dma_shadowed, drm_fb_helper_damage_range, drm_fb_helper_damage_area); -static int drm_fbdev_dma_deferred_fb_mmap (struct fb_info *info,struct vm_area_struct *vma) +static void drm_fbdev_dma_shadowed_fb_destroy (struct fb_info *info) {struct drm_fb_helper *fb_helper = info->par; -struct drm_framebuffer *fb = fb_helper->fb; -struct drm_gem_dma_object *dma =drm_fb_dma_get_gem_obj (fb,0 ); +void *shadow = info->screen_buffer; + +if (!fb_helper->dev) +return ; -if (!dma->map_noncoherent) - vma->vm_page_prot =pgprot_writecombine (vma->vm_page_prot); +if (info->fbdefio) +fb_deferred_io_cleanup (info); +drm_fb_helper_fini (fb_helper); +vfree (shadow); -return fb_deferred_io_mmap (info, vma); +drm_client_buffer_vunmap (fb_helper->buffer); +drm_client_framebuffer_delete (fb_helper->buffer); +drm_client_release (&fb_helper->client); +drm_fb_helper_unprepare (fb_helper); +kfree (fb_helper); } -static const struct fb_ops drm_fbdev_dma_deferred_fb_ops = { +static const struct fb_ops drm_fbdev_dma_shadowed_fb_ops = { .owner =THIS_MODULE , .fb_open = drm_fbdev_dma_fb_open, .fb_release = drm_fbdev_dma_fb_release, -__FB_DEFAULT_DEFERRED_OPS_RDWR (drm_fbdev_dma), +FB_DEFAULT_DEFERRED_OPS (drm_fbdev_dma_shadowed),DRM_FB_HELPER_DEFAULT_OPS , -__FB_DEFAULT_DEFERRED_OPS_DRAW (drm_fbdev_dma), - .fb_mmap = drm_fbdev_dma_deferred_fb_mmap, - .fb_destroy = drm_fbdev_dma_fb_destroy, + .fb_destroy = drm_fbdev_dma_shadowed_fb_destroy, };/* * struct drm_fb_helper */ +static void drm_fbdev_dma_damage_blit_real (struct drm_fb_helper *fb_helper, +struct drm_clip_rect *clip, +struct iosys_map *dst) +{ +struct drm_framebuffer *fb = fb_helper->fb; +size_t offset = clip->y1 * fb->pitches[0 ]; +size_t len = clip->x2 - clip->x1; +unsigned int y; +void *src; + +switch (drm_format_info_bpp (fb->format,0 )) { +case 1 : + offset += clip->x1 /8 ; + len =DIV_ROUND_UP (len + clip->x1 %8 ,8 ); +break ; +case 2 : + offset += clip->x1 /4 ; + len =DIV_ROUND_UP (len + clip->x1 %4 ,4 ); +break ; +case 4 : + offset += clip->x1 /2 ; + len =DIV_ROUND_UP (len + clip->x1 %2 ,2 ); +break ; +default : + offset += clip->x1 * fb->format->cpp[0 ]; + len *= fb->format->cpp[0 ]; +break ; + } + + src = fb_helper->info->screen_buffer + offset; +iosys_map_incr (dst, offset);/* go to first pixel within clip rect */ + +for (y = clip->y1; y < clip->y2; y++) { +iosys_map_memcpy_to (dst,0 , src, len); +iosys_map_incr (dst, fb->pitches[0 ]); + src += fb->pitches[0 ]; + } +} + +static int drm_fbdev_dma_damage_blit (struct drm_fb_helper *fb_helper, +struct drm_clip_rect *clip) +{ +struct drm_client_buffer *buffer = fb_helper->buffer; +struct iosys_map dst; + +/* +* For fbdev emulation, we only have to protect against fbdev modeset +* operations. Nothing else will involve the client buffer's BO. So it +* is sufficient to acquire struct drm_fb_helper.lock here. +*/ +mutex_lock (&fb_helper->lock); + + dst = buffer->map; +drm_fbdev_dma_damage_blit_real (fb_helper, clip, &dst); + +mutex_unlock (&fb_helper->lock); + +return 0 ; +} +static int drm_fbdev_dma_helper_fb_probe (struct drm_fb_helper *fb_helper,struct drm_fb_helper_surface_size *sizes) {return drm_fbdev_dma_driver_fbdev_probe (fb_helper, sizes); } -static int drm_fbdev_dma_helper_fb_dirty (struct drm_fb_helper *helper,struct drm_clip_rect *clip) {
@@ -120,6 +186,10 @@ static int drm_fbdev_dma_helper_fb_dirty(struct drm_fb_helper *helper,return 0 ;if (helper->fb->funcs->dirty) { + ret =drm_fbdev_dma_damage_blit (helper, clip); +if (drm_WARN_ONCE (dev, ret,"Damage blitter failed: ret=%d\n" , ret)) +return ret; + ret = helper->fb->funcs->dirty (helper->fb,NULL ,0 ,0 , clip,1 );if (drm_WARN_ONCE (dev, ret,"Dirty helper failed: ret=%d\n" , ret))return ret;
@@ -137,14 +207,80 @@ static const struct drm_fb_helper_funcs drm_fbdev_dma_helper_funcs = {* struct drm_fb_helper */ +static int drm_fbdev_dma_driver_fbdev_probe_tail (struct drm_fb_helper *fb_helper, +struct drm_fb_helper_surface_size *sizes) +{ +struct drm_device *dev = fb_helper->dev; +struct drm_client_buffer *buffer = fb_helper->buffer; +struct drm_gem_dma_object *dma_obj =to_drm_gem_dma_obj (buffer->gem); +struct drm_framebuffer *fb = fb_helper->fb; +struct fb_info *info = fb_helper->info; +struct iosys_map map = buffer->map; + + info->fbops = &drm_fbdev_dma_fb_ops; + +/* screen */ + info->flags |=FBINFO_VIRTFB ;/* system memory */ +if (dma_obj->map_noncoherent) + info->flags |=FBINFO_READS_FAST ;/* signal caching */ + info->screen_size = sizes->surface_height * fb->pitches[0 ]; + info->screen_buffer = map.vaddr; +if (!(info->flags &FBINFO_HIDE_SMEM_START )) { +if (!drm_WARN_ON (dev,is_vmalloc_addr (info->screen_buffer))) + info->fix.smem_start =page_to_phys (virt_to_page (info->screen_buffer)); + } + info->fix.smem_len = info->screen_size; + +return 0 ; +} + +static int drm_fbdev_dma_driver_fbdev_probe_tail_shadowed (struct drm_fb_helper *fb_helper, +struct drm_fb_helper_surface_size *sizes) +{ +struct drm_client_buffer *buffer = fb_helper->buffer; +struct fb_info *info = fb_helper->info; +size_t screen_size = buffer->gem->size; +void *screen_buffer; +int ret; + +/* +* Deferred I/O requires struct page for framebuffer memory, +* which is not guaranteed for all DMA ranges. We thus create +* a shadow buffer in system memory. +*/ + screen_buffer =vzalloc (screen_size); +if (!screen_buffer) +return -ENOMEM ; + + info->fbops = &drm_fbdev_dma_shadowed_fb_ops; + +/* screen */ + info->flags |=FBINFO_VIRTFB ;/* system memory */ + info->flags |=FBINFO_READS_FAST ;/* signal caching */ + info->screen_buffer = screen_buffer; + info->fix.smem_len = screen_size; + + fb_helper->fbdefio.delay =HZ /20 ; + fb_helper->fbdefio.deferred_io = drm_fb_helper_deferred_io; + + info->fbdefio = &fb_helper->fbdefio; + ret =fb_deferred_io_init (info); +if (ret) + goto err_vfree; + +return 0 ; + +err_vfree: +vfree (screen_buffer); +return ret; +} +int drm_fbdev_dma_driver_fbdev_probe (struct drm_fb_helper *fb_helper,struct drm_fb_helper_surface_size *sizes) {struct drm_client_dev *client = &fb_helper->client;struct drm_device *dev = fb_helper->dev; -bool use_deferred_io = false;struct drm_client_buffer *buffer; -struct drm_gem_dma_object *dma_obj;struct drm_framebuffer *fb;struct fb_info *info;u32 format;
@@ -161,19 +297,9 @@ int drm_fbdev_dma_driver_fbdev_probe(struct drm_fb_helper *fb_helper, sizes->surface_height, format);if (IS_ERR (buffer))return PTR_ERR (buffer); - dma_obj =to_drm_gem_dma_obj (buffer->gem); fb = buffer->fb; -/* -* Deferred I/O requires struct page for framebuffer memory, -* which is not guaranteed for all DMA ranges. We thus only -* install deferred I/O if we have a framebuffer that requires -* it. -*/ -if (fb->funcs->dirty) - use_deferred_io = true; - ret =drm_client_buffer_vmap (buffer, &map);if (ret) { goto err_drm_client_buffer_delete;
@@ -194,45 +320,12 @@ int drm_fbdev_dma_driver_fbdev_probe(struct drm_fb_helper *fb_helper,drm_fb_helper_fill_info (info, fb_helper, sizes); -if (use_deferred_io) - info->fbops = &drm_fbdev_dma_deferred_fb_ops; +if (fb->funcs->dirty) + ret =drm_fbdev_dma_driver_fbdev_probe_tail_shadowed (fb_helper, sizes);else - info->fbops = &drm_fbdev_dma_fb_ops; - -/* screen */ - info->flags |=FBINFO_VIRTFB ;/* system memory */ -if (dma_obj->map_noncoherent) - info->flags |=FBINFO_READS_FAST ;/* signal caching */ - info->screen_size = sizes->surface_height * fb->pitches[0 ]; - info->screen_buffer = map.vaddr; -if (!(info->flags &FBINFO_HIDE_SMEM_START )) { -if (!drm_WARN_ON (dev,is_vmalloc_addr (info->screen_buffer))) - info->fix.smem_start =page_to_phys (virt_to_page (info->screen_buffer)); - } - info->fix.smem_len = info->screen_size; - -/* -* Only set up deferred I/O if the screen buffer supports -* it. If this disagrees with the previous test for ->dirty, -* mmap on the /dev/fb file might not work correctly. -*/ -if (!is_vmalloc_addr (info->screen_buffer) && info->fix.smem_start) { -unsigned long pfn = info->fix.smem_start >>PAGE_SHIFT ; - -if (drm_WARN_ON (dev, !pfn_to_page (pfn))) - use_deferred_io = false; - } - -/* deferred I/O */ -if (use_deferred_io) { - fb_helper->fbdefio.delay =HZ /20 ; - fb_helper->fbdefio.deferred_io = drm_fb_helper_deferred_io; - - info->fbdefio = &fb_helper->fbdefio; - ret =fb_deferred_io_init (info); -if (ret) - goto err_drm_fb_helper_release_info; - } + ret =drm_fbdev_dma_driver_fbdev_probe_tail (fb_helper, sizes); +if (ret) + goto err_drm_fb_helper_release_info;return 0 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 202/218 btrfs: skip inodes without loaded extent maps when shrinking extent maps
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
[ Upstream commit c6c9c4d56483d941f567eb921434c25fc6086dfa ]
If there are inodes that don't have any loaded extent maps, we end up grabbing a reference on them and later adding a delayed iput, which wakes up the cleaner and makes it do unnecessary work. This is common when for example the inodes were open only to run stat(2) or all their extent maps were already released through the folio release callback (btrfs_release_folio()) or released by a previous run of the shrinker, or directories which never have extent maps.
--- fs/btrfs/extent_map.c | 78 +++++++++++++++++++++++++++++++------------ 1 file changed, 57 insertions(+), 21 deletions(-)
fs/btrfs/extent_map.c +57 -21
@@ -1133,6 +1133,8 @@ static long btrfs_scan_inode(struct btrfs_inode *inode, struct btrfs_em_shrink_clong nr_dropped =0 ;struct rb_node *node; +lockdep_assert_held_write (&tree->lock); +/* * Take the mmap lock so that we serialize with the inode logging phase * of fsync because we may need to set the full sync flag on the inode,
@@ -1144,28 +1146,12 @@ static long btrfs_scan_inode(struct btrfs_inode *inode, struct btrfs_em_shrink_c* to find new extents, which may not be there yet because ordered * extents haven't completed yet. * -* We also do a try lock because otherwise we could deadlock. This is -* because the shrinker for this filesystem may be invoked while we are -* in a path that is holding the mmap lock in write mode. For example in -* a reflink operation while COWing an extent buffer, when allocating -* pages for a new extent buffer and under memory pressure, the shrinker -* may be invoked, and therefore we would deadlock by attempting to read -* lock the mmap lock while we are holding already a write lock on it. +* We also do a try lock because we don't want to block for too long and +* we are holding the extent map tree's lock in write mode. */ if (!down_read_trylock (&inode->i_mmap_lock))return 0 ; -/* -* We want to be fast so if the lock is busy we don't want to spend time -* waiting for it - either some task is about to do IO for the inode or -* we may have another task shrinking extent maps, here in this code, so -* skip this inode. -*/ -if (!write_trylock (&tree->lock)) { -up_read (&inode->i_mmap_lock); -return 0 ; - } - node =rb_first (&tree->root);while (node) {struct rb_node *next =rb_next (node);
@@ -1205,21 +1191,71 @@ static long btrfs_scan_inode(struct btrfs_inode *inode, struct btrfs_em_shrink_cbreak ; node = next; } -write_unlock (&tree->lock);up_read (&inode->i_mmap_lock);return nr_dropped; } +static struct btrfs_inode *find_first_inode_to_shrink (struct btrfs_root *root, +u64 min_ino) +{ +struct btrfs_inode *inode; +unsigned long from = min_ino; + +xa_lock (&root->inodes); +while (true) { +struct extent_map_tree *tree; + + inode =xa_find (&root->inodes, &from,ULONG_MAX ,XA_PRESENT ); +if (!inode) +break ; + + tree = &inode->extent_tree; + +/* +* We want to be fast so if the lock is busy we don't want to +* spend time waiting for it (some task is about to do IO for +* the inode). +*/ +if (!write_trylock (&tree->lock)) + goto next; + +/* +* Skip inode if it doesn't have loaded extent maps, so we avoid +* getting a reference and doing an iput later. This includes +* cases like files that were opened for things like stat(2), or +* files with all extent maps previously released through the +* release folio callback (btrfs_release_folio()) or released in +* a previous run, or directories which never have extent maps. +*/ +if (RB_EMPTY_ROOT (&tree->root)) { +write_unlock (&tree->lock); + goto next; + } + +if (igrab (&inode->vfs_inode)) +break ; + +write_unlock (&tree->lock); +next: + from =btrfs_ino (inode) +1 ; +cond_resched_lock (&root->inodes.xa_lock); + } +xa_unlock (&root->inodes); + +return inode; +} +static long btrfs_scan_root (struct btrfs_root *root,struct btrfs_em_shrink_ctx *ctx) {struct btrfs_inode *inode;long nr_dropped =0 ;u64 min_ino = ctx->last_ino +1 ; - inode =btrfs_find_first_inode (root, min_ino); + inode =find_first_inode_to_shrink (root, min_ino);while (inode) { nr_dropped +=btrfs_scan_inode (inode, ctx); +write_unlock (&inode->extent_tree.lock); min_ino =btrfs_ino (inode) +1 ; ctx->last_ino =btrfs_ino (inode);
@@ -1230,7 +1266,7 @@ static long btrfs_scan_root(struct btrfs_root *root, struct btrfs_em_shrink_ctxcond_resched (); - inode =btrfs_find_first_inode (root, min_ino); + inode =find_first_inode_to_shrink (root, min_ino); }if (inode) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 203/218 btrfs: make the extent map shrinker run asynchronously as a work queue job
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
[ Upstream commit 1020443840569535f6025a855958f07ea3eebf71 ]
Currently the extent map shrinker is run synchronously for kswapd tasks that end up calling the fs shrinker (fs/super.c:super_cache_scan()). This has some disadvantages and for some heavy workloads with memory pressure it can cause some delays and stalls that make a machine unresponsive for some periods. This happens because:
1) We can have several kswapd tasks on machines with multiple NUMA zones, and running the extent map shrinker concurrently can cause high contention on some spin locks, namely the spin locks that protect the radix tree that tracks roots, the per root xarray that tracks open inodes and the list of delayed iputs. This not only delays the shrinker but also causes high CPU consumption and makes the task running the shrinker monopolize a core, resulting in the symptoms of an unresponsive system. This was noted in previous commits such as commit ae1e766f623f ("btrfs: only run the extent map shrinker from kswapd tasks");
2) The extent map shrinker's iteration over inodes can often be slow, even after changing the data structure that tracks open inodes for a root from a red black tree (up to kernel 6.10) to an xarray (kernel 6.10+). The transition to the xarray while it made things a bit faster, it's still somewhat slow - for example in a test scenario with 10000 inodes that have no extent maps loaded, the extent map shrinker took between 5ms to 8ms, using a release, non-debug kernel. Iterating over the extent maps of an inode can also be slow if have an inode with many thousands of extent maps, since we use a red black tree to track and search extent maps. So having the extent map shrinker run synchronously adds extra delay for other things a kswapd task does.
So make the extent map shrinker run asynchronously as a job for the system unbounded workqueue, just like what we do for data and metadata space reclaim jobs.
--- fs/btrfs/disk-io.c | 2 ++ fs/btrfs/extent_map.c | 51 ++++++++++++++++++++++++++++++++++++------- fs/btrfs/extent_map.h | 3 ++- fs/btrfs/fs.h | 2 ++ fs/btrfs/super.c | 13 +++-------- 5 files changed, 52 insertions(+), 19 deletions(-)
fs/btrfs/disk-io.c +2 -0
@@ -2785,6 +2785,7 @@ void btrfs_init_fs_info(struct btrfs_fs_info *fs_info)btrfs_init_scrub (fs_info);btrfs_init_balance (fs_info);btrfs_init_async_reclaim_work (fs_info); +btrfs_init_extent_map_shrinker_work (fs_info);rwlock_init (&fs_info->block_group_cache_lock); fs_info->block_group_cache_tree =RB_ROOT_CACHED ;
@@ -4334,6 +4335,7 @@ void __cold close_ctree(struct btrfs_fs_info *fs_info)cancel_work_sync (&fs_info->async_reclaim_work);cancel_work_sync (&fs_info->async_data_reclaim_work);cancel_work_sync (&fs_info->preempt_reclaim_work); +cancel_work_sync (&fs_info->extent_map_shrinker_work);/* Cancel or finish ongoing discard work */ btrfs_discard_cleanup (fs_info);
fs/btrfs/extent_map.c +43 -8
97 lines not on this page · raw message
fs/btrfs/extent_map.h +2 -1
@@ -189,6 +189,7 @@ void btrfs_drop_extent_map_range(struct btrfs_inode *inode,int btrfs_replace_extent_map_range (struct btrfs_inode *inode,struct extent_map *new_em,bool modified); -long btrfs_free_extent_maps (struct btrfs_fs_info *fs_info,long nr_to_scan); +void btrfs_free_extent_maps (struct btrfs_fs_info *fs_info,long nr_to_scan); +void btrfs_init_extent_map_shrinker_work (struct btrfs_fs_info *fs_info);#endif
fs/btrfs/fs.h +2 -0
@@ -639,6 +639,8 @@ struct btrfs_fs_info {spinlock_t extent_map_shrinker_lock;u64 extent_map_shrinker_last_root;u64 extent_map_shrinker_last_ino; +atomic64_t extent_map_shrinker_nr_to_scan; +struct work_struct extent_map_shrinker_work;/* Protected by 'trans_lock'. */ struct list_head dirty_cowonly_roots;
fs/btrfs/super.c +3 -10
@@ -28,7 +28,6 @@#include <linux/btrfs.h> #include <linux/security.h> #include <linux/fs_parser.h> -#include <linux/swap.h> #include "messages.h" #include "delayed-inode.h" #include "ctree.h"
@@ -2399,16 +2398,10 @@ static long btrfs_free_cached_objects(struct super_block *sb, struct shrink_cont const long nr_to_scan = min_t(unsigned long, LONG_MAX, sc->nr_to_scan);struct btrfs_fs_info *fs_info =btrfs_sb (sb); -/* -* We may be called from any task trying to allocate memory and we don't -* want to slow it down with scanning and dropping extent maps. It would -* also cause heavy lock contention if many tasks concurrently enter -* here. Therefore only allow kswapd tasks to scan and drop extent maps. -*/ -if (!current_is_kswapd ()) -return 0 ; +btrfs_free_extent_maps (fs_info, nr_to_scan); -return btrfs_free_extent_maps (fs_info, nr_to_scan); +/* The extent map shrinker runs asynchronously, so always return 0. */ +return 0 ; }static const struct super_operations btrfs_super_ops = {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 204/218 btrfs: do regular iput instead of delayed iput during extent map shrinking
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
[ Upstream commit 15b3b3254d1453a8db038b7d44b311a2d6c71f98 ]
The extent map shrinker now runs in the system unbound workqueue and no longer in kswapd context so it can directly do an iput() on inodes even if that blocks or needs to acquire any lock (we aren't holding any locks when requesting the delayed iput from the shrinker). So we don't need to add a delayed iput, wake up the cleaner and delegate the iput() to the cleaner, which also adds extra contention on the spinlock that protects the delayed iputs list.
--- fs/btrfs/extent_map.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/extent_map.c +1 -1
@@ -1261,7 +1261,7 @@ static long btrfs_scan_root(struct btrfs_root *root, struct btrfs_em_shrink_ctx min_ino =btrfs_ino (inode) +1 ; ctx->last_ino =btrfs_ino (inode); -btrfs_add_delayed_iput (inode); +iput (&inode->vfs_inode);if (ctx->scanned >= ctx->nr_to_scan ||btrfs_fs_closing (inode->root->fs_info))
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 205/218 riscv/atomic: Do proper sign extension also for unsigned in arch_cmpxchg
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit 1898300abf3508bca152e65b36cce5bf93d7e63e ]
Sign extend also an unsigned compare value to match what lr.w is doing. Otherwise try_cmpxchg may spuriously return true when used on a u32 value that has the sign bit set, as it happens often in inode_set_ctime_current.
Do this in three conversion steps. The first conversion to long is needed to avoid a -Wpointer-to-int-cast warning when arch_cmpxchg is used with a pointer type. Then convert to int and back to long to always sign extend the 32-bit value to 64-bit.
--- arch/riscv/include/asm/cmpxchg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/cmpxchg.h +1 -1
@@ -169,7 +169,7 @@break ; \case 4 : \__arch_cmpxchg (".w" ,".w" sc_sfx, prepend, append, \ - __ret, __ptr, (long), __old, __new); \ + __ret, __ptr, (long)(int)(long), __old, __new); \break ; \case 8 : \ __arch_cmpxchg(".d", ".d" sc_sfx, prepend, append, \
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 206/218 LoongArch: Set hugetlb mmap base address aligned with pmd size
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bibo Mao <[email protected]>
[ Upstream commit 3109d5ff484b7bc7b955f166974c6776d91f247b ]
With ltp test case "testcases/bin/hugefork02", there is a dmesg error report message such as:
kernel BUG at mm/hugetlb.c:5550!
Oops - BUG[#1]:
CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241
Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940
a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000
a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000
t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000
t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001
t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280
s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10
s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08
ra: 9000000000485538 unmap_vmas+0x130/0x218
ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0
PRMD: 00000004 (PPLV0 +PIE -PWE)
EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64)
Call Trace:
[<90000000004eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0
[<9000000000485534>] unmap_vmas+0x12c/0x218
[<9000000000494068>] exit_mmap+0xe0/0x308
[<900000000025fdc4>] mmput+0x74/0x180
[<900000000026a284>] do_exit+0x294/0x898
[<900000000026aa30>] do_group_exit+0x30/0x98
[<900000000027bed4>] get_signal+0x83c/0x868
[<90000000002457b4>] arch_do_signal_or_restart+0x54/0xfa0
[<90000000015795e8>] irqentry_exit_to_user_mode+0xb8/0x138
[<90000000002572d0>] tlb_do_page_fault_1+0x114/0x1b4The problem is that base address allocated from hugetlbfs is not aligned with pmd size. Here add a checking for hugetlbfs and align base address with pmd size. After this patch the test case "testcases/bin/hugefork02" passes to run.
This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach generic_get_unmapped_area{_topdown} to handle hugetlb mappings").
--- arch/loongarch/mm/mmap.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
arch/loongarch/mm/mmap.c +5 -1
@@ -3,6 +3,7 @@* Copyright (C) 2020-2022 Loongson Technology Corporation Limited */ #include <linux/export.h> +#include <linux/hugetlb.h> #include <linux/io.h> #include <linux/kfence.h> #include <linux/memblock.h>
@@ -63,8 +64,11 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp, } info.length = len; - info.align_mask = do_color_align ? (PAGE_MASK &SHM_ALIGN_MASK ) :0 ; info.align_offset = pgoff <<PAGE_SHIFT ; +if (filp &&is_file_hugepages (filp)) + info.align_mask =huge_page_mask_align (filp); +else + info.align_mask = do_color_align ? (PAGE_MASK &SHM_ALIGN_MASK ) :0 ;if (dir ==DOWN ) { info.flags =VM_UNMAPPED_AREA_TOPDOWN ;
Signature · 1 line
2.39.5
Re: [PATCH 6.12 206/218] LoongArch: Set hugetlb mmap base address aligned with pmd size
Quoted 2 lines · On Thu, 03 Jul 2025 16:42:34 +0200 Greg Kroah-Hartman…
Cc [email protected] # 6.13+
This line makes sense -- it sounds like it was indeed not meant for v6.12:
https://lore.kernel.org/stable/[email protected]/
Cheers,
Miguel
Sasha Levin
maintainerRe: [PATCH 6.12 206/218] LoongArch: Set hugetlb mmap base address aligned with pmd size
Quoted 7 lines · Miguel Ojeda
Quoted 2 lines · On Thu, 03 Jul 2025 16:42:34 +0200 Greg Kroah-Hartman…
Cc [email protected] # 6.13+This line makes sense -- it sounds like it was indeed not meant for v6.12:
https://lore.kernel.org/stable/[email protected]/
Yup, now dropped. Thanks!
Signature · 2 lines
Thanks, Sasha
Greg Kroah-Hartman
maintainerPATCH 207/218 arm64: dts: rockchip: Add avdd HDMI supplies to RockPro64 board dtsi
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dragan Simic <[email protected]>
[ Upstream commit bd1c959f37f384b477f51572331b0dc828bd009a ]
Add missing "avdd-0v9-supply" and "avdd-1v8-supply" properties to the "hdmi" node in the Pine64 RockPro64 board dtsi file. To achieve this, also add the associated "vcca_0v9" regulator that produces the 0.9 V supply, [1][2] which hasn't been defined previously in the board dtsi file.
This also eliminates the following warnings from the kernel log:
dwhdmi-rockchip ff940000.hdmi: supply avdd-0v9 not found, using dummy regulator dwhdmi-rockchip ff940000.hdmi: supply avdd-1v8 not found, using dummy regulator
There are no functional changes to the way board works with these additions, because the "vcc1v8_dvp" and "vcca_0v9" regulators are always enabled, [1][2] but these additions improve the accuracy of hardware description.
These changes apply to the both supported hardware revisions of the Pine64 RockPro64, i.e. to the production-run revisions 2.0 and 2.1. [1][2]
[1] https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
[2] https://files.pine64.org/doc/rockpro64/rockpro64_v20-SCH.pdf
--- arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 12 ++++++++++++ 1 file changed, 12 insertions(+)
arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi +12 -0
@@ -227,6 +227,16 @@ vcc5v0_usb: vcc5v0-usb { vin-supply = <&vcc12v_dcin>; }; + vcca_0v9: vcca-0v9 { + compatible = "regulator-fixed"; + regulator-name = "vcca_0v9"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <900000>; + vin-supply = <&vcc3v3_sys>; + }; + vdd_log: vdd-log { compatible = "pwm-regulator"; pwms = <&pwm2 0 25000 1>;
@@ -312,6 +322,8 @@ &gmac { }; &hdmi { + avdd-0v9-supply = <&vcca_0v9>; + avdd-1v8-supply = <&vcc1v8_dvp>; ddc-i2c-bus = <&i2c3>; pinctrl-names = "default"; pinctrl-0 = <&hdmi_cec>;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 208/218 ALSA: hda/realtek: Bass speaker fixup for ASUS UM5606KA
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andres Traumann <[email protected]>
[ Upstream commit be8cd366beb80c709adbc7688ee72750f5aee3ff ]
This patch applies the ALC294 bass speaker fixup (ALC294_FIXUP_BASS_SPEAKER_15), previously introduced in commit a7df7f909cec ("ALSA: hda: improve bass speaker support for ASUS Zenbook UM5606WA"), to the ASUS Zenbook UM5606KA. This hardware configuration matches ASUS Zenbook UM5606WA, where DAC NID 0x06 was removed from the bass speaker (NID 0x15), routing both speaker pins to DAC NID 0x03.
This resolves the bass speaker routing issue, ensuring correct audio output on ASUS UM5606KA.
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -10859,6 +10859,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {SND_PCI_QUIRK (0x1043 ,0x1204 ,"ASUS Strix G615JHR_JMR_JPR" ,ALC287_FIXUP_TAS2781_I2C ),SND_PCI_QUIRK (0x1043 ,0x1214 ,"ASUS Strix G615LH_LM_LP" ,ALC287_FIXUP_TAS2781_I2C ),SND_PCI_QUIRK (0x1043 ,0x125e ,"ASUS Q524UQK" ,ALC255_FIXUP_ASUS_MIC_NO_PRESENCE ), +SND_PCI_QUIRK (0x1043 ,0x1264 ,"ASUS UM5606KA" ,ALC294_FIXUP_BASS_SPEAKER_15 ),SND_PCI_QUIRK (0x1043 ,0x1271 ,"ASUS X430UN" ,ALC256_FIXUP_ASUS_MIC_NO_PRESENCE ),SND_PCI_QUIRK (0x1043 ,0x1290 ,"ASUS X441SA" ,ALC233_FIXUP_EAPD_COEF_AND_MIC_NO_PRESENCE ), SND_PCI_QUIRK(0x1043, 0x1294, "ASUS B3405CVA", ALC245_FIXUP_CS35L41_SPI_2),
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 209/218 drm/amdkfd: remove gfx 12 trap handler page size cap
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonathan Kim <[email protected]>
[ Upstream commit cd82f29ec51b2e616289db7b258a936127c16efa ]
GFX 12 does not require a page size cap for the trap handler because it does not require a CWSR work around like GFX 11 did.
--- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdkfd/kfd_device.c +2 -1
@@ -537,7 +537,8 @@ static void kfd_cwsr_init(struct kfd_dev *kfd) kfd->cwsr_isa = cwsr_trap_gfx11_hex; kfd->cwsr_isa_size =sizeof (cwsr_trap_gfx11_hex); }else { -BUILD_BUG_ON (sizeof (cwsr_trap_gfx12_hex) >PAGE_SIZE ); +BUILD_BUG_ON (sizeof (cwsr_trap_gfx12_hex) + >KFD_CWSR_TMA_OFFSET ); kfd->cwsr_isa = cwsr_trap_gfx12_hex; kfd->cwsr_isa_size =sizeof (cwsr_trap_gfx12_hex); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 210/218 drm/amdkfd: Fix instruction hazard in gfx12 trap handler
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jay Cornwall <[email protected]>
[ Upstream commit 424648c3838133f93a34fdfe4f9d5597551e7b3b ]
VALU instructions with SGPR source need wait states to avoid hazard with SALU using different SGPR.
v2: Eliminate some hazards to reduce code explosion
--- .../gpu/drm/amd/amdkfd/cwsr_trap_handler.h | 677 ++++++++++-------- .../amd/amdkfd/cwsr_trap_handler_gfx12.asm | 82 ++- 2 files changed, 404 insertions(+), 355 deletions(-)
drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h +360 -317
@@ -3640,7 +3640,7 @@ static const uint32_t cwsr_trap_gfx9_4_3_hex[] = { };static const uint32_t cwsr_trap_gfx12_hex[] = { -0xbfa00001 ,0xbfa0024b , +0xbfa00001 ,0xbfa002a2 ,0xb0804009 ,0xb8f8f804 ,0x9178ff78 ,0x00008c00 ,0xb8fbf811 ,0x8b6eff78 ,
@@ -3714,7 +3714,15 @@ static const uint32_t cwsr_trap_gfx12_hex[] = {0x00011677 ,0xd7610000 ,0x00011a79 ,0xd7610000 ,0x00011c7e ,0xd7610000 , -0x00011e7f ,0xbefe00ff , +0x00011e7f ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xbefe00ff ,0x00003fff ,0xbeff0080 ,0xee0a407a ,0x000c0000 , 0x00004000, 0xd760007a,
@@ -3751,38 +3759,46 @@ static const uint32_t cwsr_trap_gfx12_hex[] = {0x00000200 ,0xbef600ff ,0x01000000 ,0x7e000280 ,0x7e020280 ,0x7e040280 , -0xbefd0080 ,0xbe804ec2 , -0xbf94fffe ,0xb8faf804 , -0x8b7a847a ,0x91788478 , -0x8c787a78 ,0xd7610002 , -0x0000fa71 ,0x807d817d , -0xd7610002 ,0x0000fa6c , -0x807d817d ,0x917aff6d , -0x80000000 ,0xd7610002 , -0x0000fa7a ,0x807d817d , -0xd7610002 ,0x0000fa6e , -0x807d817d ,0xd7610002 , -0x0000fa6f ,0x807d817d , -0xd7610002 ,0x0000fa78 , -0x807d817d ,0xb8faf811 , -0xd7610002 ,0x0000fa7a , -0x807d817d ,0xd7610002 , -0x0000fa7b ,0x807d817d , -0xb8f1f801 ,0xd7610002 , -0x0000fa71 ,0x807d817d , -0xb8f1f814 ,0xd7610002 , -0x0000fa71 ,0x807d817d , -0xb8f1f815 ,0xd7610002 , -0x0000fa71 ,0x807d817d , -0xb8f1f812 ,0xd7610002 , -0x0000fa71 ,0x807d817d , -0xb8f1f813 ,0xd7610002 , -0x0000fa71 ,0x807d817d , +0xbe804ec2 ,0xbf94fffe , +0xb8faf804 ,0x8b7a847a , +0x91788478 ,0x8c787a78 , +0x917aff6d ,0x80000000 , +0xd7610002 ,0x00010071 , +0xd7610002 ,0x0001026c , +0xd7610002 ,0x0001047a , +0xd7610002 ,0x0001066e , +0xd7610002 ,0x0001086f , +0xd7610002 ,0x00010a78 , +0xd7610002 ,0x00010e7b , +0xd8500000 ,0x00000000 , +0xd8500000 ,0x00000000 , +0xd8500000 ,0x00000000 , +0xd8500000 ,0x00000000 , +0xd8500000 ,0x00000000 , +0xd8500000 ,0x00000000 , +0xd8500000 ,0x00000000 , +0xd8500000 ,0x00000000 , +0xb8faf811 ,0xd7610002 , +0x00010c7a ,0xb8faf801 , +0xd7610002 ,0x0001107a , +0xb8faf814 ,0xd7610002 , +0x0001127a ,0xb8faf815 , +0xd7610002 ,0x0001147a , +0xb8faf812 ,0xd7610002 , +0x0001167a ,0xb8faf813 , +0xd7610002 ,0x0001187a ,0xb8faf802 ,0xd7610002 , -0x0000fa7a ,0x807d817d , -0xbefa50c1 ,0xbfc70000 , -0xd7610002 ,0x0000fa7a , -0x807d817d ,0xbefe00ff , +0x00011a7a ,0xbefa50c1 , +0xbfc70000 ,0xd7610002 , +0x00011c7a ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xbefe00ff ,0x0000ffff ,0xbeff0080 ,0xc4068070 ,0x008ce802 , 0x00000000, 0xbefe00c1,
@@ -3797,329 +3813,356 @@ static const uint32_t cwsr_trap_gfx12_hex[] = {0xbe824102 ,0xbe844104 ,0xbe864106 ,0xbe884108 ,0xbe8a410a ,0xbe8c410c , -0xbe8e410e ,0xd7610002 , -0x0000f200 ,0x80798179 , -0xd7610002 ,0x0000f201 , -0x80798179 ,0xd7610002 , -0x0000f202 ,0x80798179 , -0xd7610002 ,0x0000f203 , -0x80798179 ,0xd7610002 , -0x0000f204 ,0x80798179 , -0xd7610002 ,0x0000f205 , -0x80798179 ,0xd7610002 , -0x0000f206 ,0x80798179 , -0xd7610002 ,0x0000f207 , -0x80798179 ,0xd7610002 , -0x0000f208 ,0x80798179 , -0xd7610002 ,0x0000f209 , -0x80798179 ,0xd7610002 , -0x0000f20a ,0x80798179 , -0xd7610002 ,0x0000f20b , -0x80798179 ,0xd7610002 , -0x0000f20c ,0x80798179 , -0xd7610002 ,0x0000f20d , -0x80798179 ,0xd7610002 , -0x0000f20e ,0x80798179 , -0xd7610002 ,0x0000f20f , -0x80798179 ,0xbf06a079 , -0xbfa10007 ,0xc4068070 , +0xbe8e410e ,0xbf068079 , +0xbfa10032 ,0xd7610002 , +0x00010000 ,0xd7610002 , +0x00010201 ,0xd7610002 , +0x00010402 ,0xd7610002 , +0x00010603 ,0xd7610002 , +0x00010804 ,0xd7610002 , +0x00010a05 ,0xd7610002 , +0x00010c06 ,0xd7610002 , +0x00010e07 ,0xd7610002 , +0x00011008 ,0xd7610002 , +0x00011209 ,0xd7610002 , +0x0001140a ,0xd7610002 , +0x0001160b ,0xd7610002 , +0x0001180c ,0xd7610002 , +0x00011a0d ,0xd7610002 , +0x00011c0e ,0xd7610002 , +0x00011e0f ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0x80799079 , +0xbfa00038 ,0xd7610002 , +0x00012000 ,0xd7610002 , +0x00012201 ,0xd7610002 , +0x00012402 ,0xd7610002 , +0x00012603 ,0xd7610002 , +0x00012804 ,0xd7610002 , +0x00012a05 ,0xd7610002 , +0x00012c06 ,0xd7610002 , +0x00012e07 ,0xd7610002 , +0x00013008 ,0xd7610002 , +0x00013209 ,0xd7610002 , +0x0001340a ,0xd7610002 , +0x0001360b ,0xd7610002 , +0x0001380c ,0xd7610002 , +0x00013a0d ,0xd7610002 , +0x00013c0e ,0xd7610002 , +0x00013e0f ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0x80799079 , +0xc4068070 ,0x008ce802 , +0x00000000 ,0x8070ff70 , +0x00000080 ,0xbef90080 , +0x7e040280 ,0x807d907d , +0xbf0aff7d ,0x00000060 , +0xbfa2ff88 ,0xbe804100 , +0xbe824102 ,0xbe844104 , +0xbe864106 ,0xbe884108 , +0xbe8a410a ,0xd7610002 , +0x00010000 ,0xd7610002 , +0x00010201 ,0xd7610002 , +0x00010402 ,0xd7610002 , +0x00010603 ,0xd7610002 , +0x00010804 ,0xd7610002 , +0x00010a05 ,0xd7610002 , +0x00010c06 ,0xd7610002 , +0x00010e07 ,0xd7610002 , +0x00011008 ,0xd7610002 , +0x00011209 ,0xd7610002 , +0x0001140a ,0xd7610002 , +0x0001160b ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xd8500000 , +0x00000000 ,0xc4068070 ,0x008ce802 ,0x00000000 , +0xbefe00c1 ,0x857d9973 , +0x8b7d817d ,0xbf06817d , +0xbfa20002 ,0xbeff0080 , +0xbfa00001 ,0xbeff00c1 , +0xb8fb4306 ,0x8b7bc17b , +0xbfa10044 ,0x8b7aff6d , +0x80000000 ,0xbfa10041 , +0x847b897b ,0xbef6007b , +0xb8f03b05 ,0x80708170 , +0xbf0d9973 ,0xbfa20002 , +0x84708970 ,0xbfa00001 , +0x84708a70 ,0xb8fa1e06 , +0x847a8a7a ,0x80707a70 , +0x8070ff70 ,0x00000200 ,0x8070ff70 ,0x00000080 , -0xbef90080 ,0x7e040280 , -0x807d907d ,0xbf0aff7d , -0x00000060 ,0xbfa2ffbb , -0xbe804100 ,0xbe824102 , -0xbe844104 ,0xbe864106 , -0xbe884108 ,0xbe8a410a , -0xd7610002 ,0x0000f200 , -0x80798179 ,0xd7610002 , -0x0000f201 ,0x80798179 , -0xd7610002 ,0x0000f202 , -0x80798179 ,0xd7610002 , -0x0000f203 ,0x80798179 , -0xd7610002 ,0x0000f204 , -0x80798179 ,0xd7610002 , -0x0000f205 ,0x80798179 , -0xd7610002 ,0x0000f206 , -0x80798179 ,0xd7610002 , -0x0000f207 ,0x80798179 , -0xd7610002 ,0x0000f208 , -0x80798179 ,0xd7610002 , -0x0000f209 ,0x80798179 , -0xd7610002 ,0x0000f20a , -0x80798179 ,0xd7610002 , -0x0000f20b ,0x80798179 , -0xc4068070 ,0x008ce802 , -0x00000000 ,0xbefe00c1 , -0x857d9973 ,0x8b7d817d , -0xbf06817d ,0xbfa20002 , -0xbeff0080 ,0xbfa00001 , -0xbeff00c1 ,0xb8fb4306 , -0x8b7bc17b ,0xbfa10044 , -0x8b7aff6d ,0x80000000 , -0xbfa10041 ,0x847b897b , -0xbef6007b ,0xb8f03b05 , -0x80708170 ,0xbf0d9973 , -0xbfa20002 ,0x84708970 , -0xbfa00001 ,0x84708a70 , -0xb8fa1e06 ,0x847a8a7a , -0x80707a70 ,0x8070ff70 , -0x00000200 ,0x8070ff70 , -0x00000080 ,0xbef600ff , -0x01000000 ,0xd71f0000 , -0x000100c1 ,0xd7200000 , -0x000200c1 ,0x16000084 , -0x857d9973 ,0x8b7d817d , -0xbf06817d ,0xbefd0080 , -0xbfa20013 ,0xbe8300ff , -0x00000080 ,0xbf800000 , -0xbf800000 ,0xbf800000 , -0xd8d80000 ,0x01000000 , -0xbf8a0000 ,0xc4068070 , -0x008ce801 ,0x00000000 , -0x807d037d ,0x80700370 , -0xd5250000 ,0x0001ff00 , -0x00000080 ,0xbf0a7b7d , -0xbfa2fff3 ,0xbfa00012 , -0xbe8300ff ,0x00000100 , +0xbef600ff ,0x01000000 , +0xd71f0000 ,0x000100c1 , +0xd7200000 ,0x000200c1 , +0x16000084 ,0x857d9973 , +0x8b7d817d ,0xbf06817d , +0xbefd0080 ,0xbfa20013 , +0xbe8300ff ,0x00000080 ,0xbf800000 ,0xbf800000 ,0xbf800000 ,0xd8d80000 ,0x01000000 ,0xbf8a0000 ,0xc4068070 ,0x008ce801 ,0x00000000 ,0x807d037d ,0x80700370 ,0xd5250000 , -0x0001ff00 ,0x00000100 , +0x0001ff00 ,0x00000080 ,0xbf0a7b7d ,0xbfa2fff3 , -0xbefe00c1 ,0x857d9973 , -0x8b7d817d ,0xbf06817d , -0xbfa20004 ,0xbef000ff , -0x00000200 ,0xbeff0080 , -0xbfa00003 ,0xbef000ff , -0x00000400 ,0xbeff00c1 , -0xb8fb3b05 ,0x807b817b , -0x847b827b ,0x857d9973 , -0x8b7d817d ,0xbf06817d , -0xbfa2001b ,0xbef600ff , -0x01000000 ,0xbefd0084 , -0xbf0a7b7d ,0xbfa10040 , -0x7e008700 ,0x7e028701 , -0x7e048702 ,0x7e068703 , -0xc4068070 ,0x008ce800 , -0x00000000 ,0xc4068070 , -0x008ce801 ,0x00008000 , -0xc4068070 ,0x008ce802 , -0x00010000 ,0xc4068070 , -0x008ce803 ,0x00018000 , -0x807d847d ,0x8070ff70 , -0x00000200 ,0xbf0a7b7d , -0xbfa2ffeb ,0xbfa0002a , +0xbfa00012 ,0xbe8300ff , +0x00000100 ,0xbf800000 , +0xbf800000 ,0xbf800000 , +0xd8d80000 ,0x01000000 , +0xbf8a0000 ,0xc4068070 , +0x008ce801 ,0x00000000 , +0x807d037d ,0x80700370 , +0xd5250000 ,0x0001ff00 , +0x00000100 ,0xbf0a7b7d , +0xbfa2fff3 ,0xbefe00c1 , +0x857d9973 ,0x8b7d817d , +0xbf06817d ,0xbfa20004 , +0xbef000ff ,0x00000200 , +0xbeff0080 ,0xbfa00003 , +0xbef000ff ,0x00000400 , +0xbeff00c1 ,0xb8fb3b05 , +0x807b817b ,0x847b827b , +0x857d9973 ,0x8b7d817d , +0xbf06817d ,0xbfa2001b ,0xbef600ff ,0x01000000 ,0xbefd0084 ,0xbf0a7b7d , -0xbfa10015 ,0x7e008700 , +0xbfa10040 ,0x7e008700 ,0x7e028701 ,0x7e048702 ,0x7e068703 ,0xc4068070 ,0x008ce800 ,0x00000000 ,0xc4068070 ,0x008ce801 , -0x00010000 ,0xc4068070 , -0x008ce802 ,0x00020000 , +0x00008000 ,0xc4068070 , +0x008ce802 ,0x00010000 ,0xc4068070 ,0x008ce803 , -0x00030000 ,0x807d847d , -0x8070ff70 ,0x00000400 , +0x00018000 ,0x807d847d , +0x8070ff70 ,0x00000200 ,0xbf0a7b7d ,0xbfa2ffeb , -0xb8fb1e06 ,0x8b7bc17b , -0xbfa1000d ,0x847b837b , -0x807b7d7b ,0xbefe00c1 , -0xbeff0080 ,0x7e008700 , +0xbfa0002a ,0xbef600ff , +0x01000000 ,0xbefd0084 , +0xbf0a7b7d ,0xbfa10015 , +0x7e008700 ,0x7e028701 , +0x7e048702 ,0x7e068703 ,0xc4068070 ,0x008ce800 , -0x00000000 ,0x807d817d , -0x8070ff70 ,0x00000080 , -0xbf0a7b7d ,0xbfa2fff7 , -0xbfa0016e ,0xbef4007e , -0x8b75ff7f ,0x0000ffff , -0x8c75ff75 ,0x00040000 , -0xbef60080 ,0xbef700ff , -0x10807fac ,0xbef1007f , -0xb8f20742 ,0x84729972 , -0x8b6eff7f ,0x04000000 , -0xbfa1003b ,0xbefe00c1 , -0x857d9972 ,0x8b7d817d , -0xbf06817d ,0xbfa20002 , -0xbeff0080 ,0xbfa00001 , -0xbeff00c1 ,0xb8ef4306 , -0x8b6fc16f ,0xbfa10030 , -0x846f896f ,0xbef6006f , +0x00000000 ,0xc4068070 , +0x008ce801 ,0x00010000 , +0xc4068070 ,0x008ce802 , +0x00020000 ,0xc4068070 , +0x008ce803 ,0x00030000 , +0x807d847d ,0x8070ff70 , +0x00000400 ,0xbf0a7b7d , +0xbfa2ffeb ,0xb8fb1e06 , +0x8b7bc17b ,0xbfa1000d , +0x847b837b ,0x807b7d7b , +0xbefe00c1 ,0xbeff0080 , +0x7e008700 ,0xc4068070 , +0x008ce800 ,0x00000000 , +0x807d817d ,0x8070ff70 , +0x00000080 ,0xbf0a7b7d , +0xbfa2fff7 ,0xbfa0016e , +0xbef4007e ,0x8b75ff7f , +0x0000ffff ,0x8c75ff75 , +0x00040000 ,0xbef60080 , +0xbef700ff ,0x10807fac , +0xbef1007f ,0xb8f20742 , +0x84729972 ,0x8b6eff7f , +0x04000000 ,0xbfa1003b , +0xbefe00c1 ,0x857d9972 , +0x8b7d817d ,0xbf06817d , +0xbfa20002 ,0xbeff0080 , +0xbfa00001 ,0xbeff00c1 , +0xb8ef4306 ,0x8b6fc16f , +0xbfa10030 ,0x846f896f , +0xbef6006f ,0xb8f83b05 , +0x80788178 ,0xbf0d9972 , +0xbfa20002 ,0x84788978 , +0xbfa00001 ,0x84788a78 , +0xb8ee1e06 ,0x846e8a6e , +0x80786e78 ,0x8078ff78 , +0x00000200 ,0x8078ff78 , +0x00000080 ,0xbef600ff , +0x01000000 ,0x857d9972 , +0x8b7d817d ,0xbf06817d , +0xbefd0080 ,0xbfa2000d , +0xc4050078 ,0x0080e800 , +0x00000000 ,0xbf8a0000 , +0xdac00000 ,0x00000000 , +0x807dff7d ,0x00000080 , +0x8078ff78 ,0x00000080 , +0xbf0a6f7d ,0xbfa2fff4 , +0xbfa0000c ,0xc4050078 , +0x0080e800 ,0x00000000 , +0xbf8a0000 ,0xdac00000 , +0x00000000 ,0x807dff7d , +0x00000100 ,0x8078ff78 , +0x00000100 ,0xbf0a6f7d , +0xbfa2fff4 ,0xbef80080 , +0xbefe00c1 ,0x857d9972 , +0x8b7d817d ,0xbf06817d , +0xbfa20002 ,0xbeff0080 , +0xbfa00001 ,0xbeff00c1 , +0xb8ef3b05 ,0x806f816f , +0x846f826f ,0x857d9972 , +0x8b7d817d ,0xbf06817d , +0xbfa2002c ,0xbef600ff , +0x01000000 ,0xbeee0078 , +0x8078ff78 ,0x00000200 , +0xbefd0084 ,0xbf0a6f7d , +0xbfa10061 ,0xc4050078 , +0x008ce800 ,0x00000000 , +0xc4050078 ,0x008ce801 , +0x00008000 ,0xc4050078 , +0x008ce802 ,0x00010000 , +0xc4050078 ,0x008ce803 , +0x00018000 ,0xbf8a0000 , +0x7e008500 ,0x7e028501 , +0x7e048502 ,0x7e068503 , +0x807d847d ,0x8078ff78 , +0x00000200 ,0xbf0a6f7d , +0xbfa2ffea ,0xc405006e , +0x008ce800 ,0x00000000 , +0xc405006e ,0x008ce801 , +0x00008000 ,0xc405006e , +0x008ce802 ,0x00010000 , +0xc405006e ,0x008ce803 , +0x00018000 ,0xbf8a0000 , +0xbfa0003d ,0xbef600ff , +0x01000000 ,0xbeee0078 , +0x8078ff78 ,0x00000400 , +0xbefd0084 ,0xbf0a6f7d , +0xbfa10016 ,0xc4050078 , +0x008ce800 ,0x00000000 , +0xc4050078 ,0x008ce801 , +0x00010000 ,0xc4050078 , +0x008ce802 ,0x00020000 , +0xc4050078 ,0x008ce803 , +0x00030000 ,0xbf8a0000 , +0x7e008500 ,0x7e028501 , +0x7e048502 ,0x7e068503 , +0x807d847d ,0x8078ff78 , +0x00000400 ,0xbf0a6f7d , +0xbfa2ffea ,0xb8ef1e06 , +0x8b6fc16f ,0xbfa1000f , +0x846f836f ,0x806f7d6f , +0xbefe00c1 ,0xbeff0080 , +0xc4050078 ,0x008ce800 , +0x00000000 ,0xbf8a0000 , +0x7e008500 ,0x807d817d , +0x8078ff78 ,0x00000080 , +0xbf0a6f7d ,0xbfa2fff6 , +0xbeff00c1 ,0xc405006e , +0x008ce800 ,0x00000000 , +0xc405006e ,0x008ce801 , +0x00010000 ,0xc405006e , +0x008ce802 ,0x00020000 , +0xc405006e ,0x008ce803 , +0x00030000 ,0xbf8a0000 ,0xb8f83b05 ,0x80788178 ,0xbf0d9972 ,0xbfa20002 ,0x84788978 ,0xbfa00001 ,0x84788a78 ,0xb8ee1e06 ,0x846e8a6e ,0x80786e78 ,0x8078ff78 ,0x00000200 , -0x8078ff78 ,0x00000080 , -0xbef600ff ,0x01000000 , -0x857d9972 ,0x8b7d817d , -0xbf06817d ,0xbefd0080 , -0xbfa2000d ,0xc4050078 , -0x0080e800 ,0x00000000 , -0xbf8a0000 ,0xdac00000 , -0x00000000 ,0x807dff7d , -0x00000080 ,0x8078ff78 , -0x00000080 ,0xbf0a6f7d , -0xbfa2fff4 ,0xbfa0000c , -0xc4050078 ,0x0080e800 , -0x00000000 ,0xbf8a0000 , -0xdac00000 ,0x00000000 , -0x807dff7d ,0x00000100 , -0x8078ff78 ,0x00000100 , -0xbf0a6f7d ,0xbfa2fff4 , -0xbef80080 ,0xbefe00c1 , -0x857d9972 ,0x8b7d817d , -0xbf06817d ,0xbfa20002 , -0xbeff0080 ,0xbfa00001 , -0xbeff00c1 ,0xb8ef3b05 , -0x806f816f ,0x846f826f , -0x857d9972 ,0x8b7d817d , -0xbf06817d ,0xbfa2002c , +0x80f8ff78 ,0x00000050 ,0xbef600ff ,0x01000000 , -0xbeee0078 ,0x8078ff78 , -0x00000200 ,0xbefd0084 , -0xbf0a6f7d ,0xbfa10061 , -0xc4050078 ,0x008ce800 , -0x00000000 ,0xc4050078 , -0x008ce801 ,0x00008000 , -0xc4050078 ,0x008ce802 , -0x00010000 ,0xc4050078 , -0x008ce803 ,0x00018000 , -0xbf8a0000 ,0x7e008500 , -0x7e028501 ,0x7e048502 , -0x7e068503 ,0x807d847d , +0xbefd00ff ,0x0000006c , +0x80f89078 ,0xf462403a , +0xf0000000 ,0xbf8a0000 , +0x80fd847d ,0xbf800000 , +0xbe804300 ,0xbe824302 , +0x80f8a078 ,0xf462603a , +0xf0000000 ,0xbf8a0000 , +0x80fd887d ,0xbf800000 , +0xbe804300 ,0xbe824302 , +0xbe844304 ,0xbe864306 , +0x80f8c078 ,0xf462803a , +0xf0000000 ,0xbf8a0000 , +0x80fd907d ,0xbf800000 , +0xbe804300 ,0xbe824302 , +0xbe844304 ,0xbe864306 , +0xbe884308 ,0xbe8a430a , +0xbe8c430c ,0xbe8e430e , +0xbf06807d ,0xbfa1fff0 , +0xb980f801 ,0x00000000 , +0xb8f83b05 ,0x80788178 , +0xbf0d9972 ,0xbfa20002 , +0x84788978 ,0xbfa00001 , +0x84788a78 ,0xb8ee1e06 , +0x846e8a6e ,0x80786e78 ,0x8078ff78 ,0x00000200 , -0xbf0a6f7d ,0xbfa2ffea , -0xc405006e ,0x008ce800 , -0x00000000 ,0xc405006e , -0x008ce801 ,0x00008000 , -0xc405006e ,0x008ce802 , -0x00010000 ,0xc405006e , -0x008ce803 ,0x00018000 , -0xbf8a0000 ,0xbfa0003d ,0xbef600ff ,0x01000000 , -0xbeee0078 ,0x8078ff78 , -0x00000400 ,0xbefd0084 , -0xbf0a6f7d ,0xbfa10016 , -0xc4050078 ,0x008ce800 , -0x00000000 ,0xc4050078 , -0x008ce801 ,0x00010000 , -0xc4050078 ,0x008ce802 , -0x00020000 ,0xc4050078 , -0x008ce803 ,0x00030000 , -0xbf8a0000 ,0x7e008500 , -0x7e028501 ,0x7e048502 , -0x7e068503 ,0x807d847d , -0x8078ff78 ,0x00000400 , -0xbf0a6f7d ,0xbfa2ffea , -0xb8ef1e06 ,0x8b6fc16f , -0xbfa1000f ,0x846f836f , -0x806f7d6f ,0xbefe00c1 , -0xbeff0080 ,0xc4050078 , -0x008ce800 ,0x00000000 , -0xbf8a0000 ,0x7e008500 , -0x807d817d ,0x8078ff78 , -0x00000080 ,0xbf0a6f7d , -0xbfa2fff6 ,0xbeff00c1 , -0xc405006e ,0x008ce800 , -0x00000000 ,0xc405006e , -0x008ce801 ,0x00010000 , -0xc405006e ,0x008ce802 , -0x00020000 ,0xc405006e , -0x008ce803 ,0x00030000 , -0xbf8a0000 ,0xb8f83b05 , -0x80788178 ,0xbf0d9972 , -0xbfa20002 ,0x84788978 , -0xbfa00001 ,0x84788a78 , -0xb8ee1e06 ,0x846e8a6e , -0x80786e78 ,0x8078ff78 , -0x00000200 ,0x80f8ff78 , -0x00000050 ,0xbef600ff , -0x01000000 ,0xbefd00ff , -0x0000006c ,0x80f89078 , -0xf462403a ,0xf0000000 , -0xbf8a0000 ,0x80fd847d , -0xbf800000 ,0xbe804300 , -0xbe824302 ,0x80f8a078 , -0xf462603a ,0xf0000000 , -0xbf8a0000 ,0x80fd887d , -0xbf800000 ,0xbe804300 , -0xbe824302 ,0xbe844304 , -0xbe864306 ,0x80f8c078 , -0xf462803a ,0xf0000000 , -0xbf8a0000 ,0x80fd907d , -0xbf800000 ,0xbe804300 , -0xbe824302 ,0xbe844304 , -0xbe864306 ,0xbe884308 , -0xbe8a430a ,0xbe8c430c , -0xbe8e430e ,0xbf06807d , -0xbfa1fff0 ,0xb980f801 , -0x00000000 ,0xb8f83b05 , -0x80788178 ,0xbf0d9972 , -0xbfa20002 ,0x84788978 , -0xbfa00001 ,0x84788a78 , -0xb8ee1e06 ,0x846e8a6e , -0x80786e78 ,0x8078ff78 , -0x00000200 ,0xbef600ff , -0x01000000 ,0xbeff0071 , -0xf4621bfa ,0xf0000000 , -0x80788478 ,0xf4621b3a , +0xbeff0071 ,0xf4621bfa ,0xf0000000 ,0x80788478 , -0xf4621b7a ,0xf0000000 , -0x80788478 ,0xf4621c3a , +0xf4621b3a ,0xf0000000 , +0x80788478 ,0xf4621b7a ,0xf0000000 ,0x80788478 , -0xf4621c7a ,0xf0000000 , -0x80788478 ,0xf4621eba , +0xf4621c3a ,0xf0000000 , +0x80788478 ,0xf4621c7a ,0xf0000000 ,0x80788478 , -0xf4621efa ,0xf0000000 , -0x80788478 ,0xf4621e7a , +0xf4621eba ,0xf0000000 , +0x80788478 ,0xf4621efa ,0xf0000000 ,0x80788478 , -0xf4621cfa ,0xf0000000 , -0x80788478 ,0xf4621bba , +0xf4621e7a ,0xf0000000 , +0x80788478 ,0xf4621cfa ,0xf0000000 ,0x80788478 , -0xbf8a0000 ,0xb96ef814 ,0xf4621bba ,0xf0000000 ,0x80788478 ,0xbf8a0000 , -0xb96ef815 ,0xf4621bba , +0xb96ef814 ,0xf4621bba ,0xf0000000 ,0x80788478 , -0xbf8a0000 ,0xb96ef812 , +0xbf8a0000 ,0xb96ef815 ,0xf4621bba ,0xf0000000 ,0x80788478 ,0xbf8a0000 , -0xb96ef813 ,0x8b6eff7f , -0x04000000 ,0xbfa1000d , -0x80788478 ,0xf4621bba , +0xb96ef812 ,0xf4621bba ,0xf0000000 ,0x80788478 , -0xbf8a0000 ,0xbf0d806e , -0xbfa10006 ,0x856e906e , -0x8b6e6e6e ,0xbfa10003 , -0xbe804ec1 ,0x816ec16e , -0xbfa0fffb ,0xbefd006f , -0xbefe0070 ,0xbeff0071 , -0xb97b2011 ,0x857b867b , -0xb97b0191 ,0x857b827b , -0xb97bba11 ,0xb973f801 , -0xb8ee3b05 ,0x806e816e , -0xbf0d9972 ,0xbfa20002 , -0x846e896e ,0xbfa00001 , -0x846e8a6e ,0xb8ef1e06 , -0x846f8a6f ,0x806e6f6e , -0x806eff6e ,0x00000200 , -0x806e746e ,0x826f8075 , -0x8b6fff6f ,0x0000ffff , -0xf4605c37 ,0xf8000050 , -0xf4605d37 ,0xf8000060 , -0xf4601e77 ,0xf8000074 , -0xbf8a0000 ,0x8b6dff6d , -0x0000ffff ,0x8bfe7e7e , -0x8bea6a6a ,0xb97af804 , +0xbf8a0000 ,0xb96ef813 , +0x8b6eff7f ,0x04000000 , +0xbfa1000d ,0x80788478 , +0xf4621bba ,0xf0000000 , +0x80788478 ,0xbf8a0000 , +0xbf0d806e ,0xbfa10006 , +0x856e906e ,0x8b6e6e6e , +0xbfa10003 ,0xbe804ec1 , +0x816ec16e ,0xbfa0fffb , +0xbefd006f ,0xbefe0070 , +0xbeff0071 ,0xb97b2011 , +0x857b867b ,0xb97b0191 , +0x857b827b ,0xb97bba11 , +0xb973f801 ,0xb8ee3b05 , +0x806e816e ,0xbf0d9972 , +0xbfa20002 ,0x846e896e , +0xbfa00001 ,0x846e8a6e , +0xb8ef1e06 ,0x846f8a6f , +0x806e6f6e ,0x806eff6e , +0x00000200 ,0x806e746e , +0x826f8075 ,0x8b6fff6f , +0x0000ffff ,0xf4605c37 , +0xf8000050 ,0xf4605d37 , +0xf8000060 ,0xf4601e77 , +0xf8000074 ,0xbf8a0000 , +0x8b6dff6d ,0x0000ffff , +0x8bfe7e7e ,0x8bea6a6a , +0xb97af804 ,0xbe804ec2 , +0xbf94fffe ,0xbe804a6c ,0xbe804ec2 ,0xbf94fffe , -0xbe804a6c ,0xbe804ec2 , -0xbf94fffe ,0xbfb10000 , +0xbfb10000 ,0xbf9f0000 ,0xbf9f0000 ,0xbf9f0000 , 0xbf9f0000, 0xbf9f0000, - 0xbf9f0000, 0x00000000, };
drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx12.asm +44 -38
143 lines not on this page · raw message
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 211/218 net: stmmac: Fix accessing freed irq affinity_hint
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qingfang Deng <[email protected]>
[ Upstream commit c60d101a226f18e9a8f01bb4c6ca2b47dfcb15ef ]
The cpumask should not be a local variable, since its pointer is saved to irq_desc and may be accessed from procfs.
To fix it, use the persistent mask cpumask_of(cpu#).
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +4 -7
@@ -3603,7 +3603,6 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev) {struct stmmac_priv *priv =netdev_priv (dev);enum request_irq_err irq_err; -cpumask_t cpu_mask;int irq_idx =0 ;char *int_name;int ret;
@@ -3732,9 +3731,8 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev) irq_idx = i; goto irq_error; } -cpumask_clear (&cpu_mask); -cpumask_set_cpu (i %num_online_cpus (), &cpu_mask); -irq_set_affinity_hint (priv->rx_irq[i], &cpu_mask); +irq_set_affinity_hint (priv->rx_irq[i], +cpumask_of (i %num_online_cpus ())); }/* Request Tx MSI irq */
@@ -3757,9 +3755,8 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev) irq_idx = i; goto irq_error; } -cpumask_clear (&cpu_mask); -cpumask_set_cpu (i %num_online_cpus (), &cpu_mask); -irq_set_affinity_hint (priv->tx_irq[i], &cpu_mask); +irq_set_affinity_hint (priv->tx_irq[i], +cpumask_of (i %num_online_cpus ())); }return 0 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 212/218 spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miquel Raynal <[email protected]>
[ Upstream commit 0fefeade90e74bc8f40ab0e460f483565c492e28 ]
In the spi subsystem, the bus frequency is derived as follows:
- the controller may expose a minimum and maximum operating frequency
- the hardware description, through the spi peripheral properties, advise what is the maximum acceptable frequency from a device/wiring point of view.
Transfers must be observed at a frequency which fits both (so in practice, the lowest maximum).
Actually, this second point mixes two information and already takes the lowest frequency among:
- what the spi device is capable of (what is written in the component datasheet)
- what the wiring allows (electromagnetic sensibility, crossovers, terminations, antenna effect, etc).
This logic works until spi devices are no longer capable of sustaining their highest frequency regardless of the operation. Spi memories are typically subject to such variation. Some devices are capable of spitting their internally stored data (essentially in read mode) at a very fast rate, typically up to 166MHz on Winbond SPI-NAND chips, using "fast" commands. However, some of the low-end operations, such as regular page read-from-cache commands, are more limited and can only be executed at 54MHz at most. This is currently a problem in the SPI-NAND subsystem. Another situation, even if not yet supported, will be with DTR commands, when the data is latched on both edges of the clock. The same chips as mentioned previously are in this case limited to 80MHz. Yet another example might be continuous reads, which, under certain circumstances, can also run at most at 104 or 120MHz.
As a matter of fact, the "one frequency per chip" policy is outdated and more fine grain configuration is needed: we need to allow per-operation frequency limitations. So far, all datasheets I encountered advertise a maximum default frequency, which need to be lowered for certain specific operations. So based on the current infrastructure, we can still expect firmware (device trees in general) to continued advertising the same maximum speed which is a mix between the PCB limitations and the chip maximum capability, and expect per-operation lower frequencies when this is relevant.
Add a struct spi_mem_op member to carry this information. Not providing this field explicitly from upper layers means that there is no further constraint and the default spi device maximum speed will be carried instead. The SPI_MEM_OP() macro is also expanded with an optional frequency argument, because virtually all operations can be subject to such a limitation, and this will allow for a smooth and discrete transition.
For controller drivers which do not implement the spi-mem interface, the per-transfer speed is also set acordingly to a lower (than the maximum default) speed when relevant.
--- drivers/mtd/nand/spi/core.c | 2 ++ drivers/spi/spi-mem.c | 28 ++++++++++++++++++++++++++++ include/linux/spi/spi-mem.h | 12 +++++++++++- 3 files changed, 41 insertions(+), 1 deletion(-)
drivers/mtd/nand/spi/core.c +2 -0
@@ -1214,6 +1214,8 @@ spinand_select_op_variant(struct spinand_device *spinand,if (ret)break ; +spi_mem_adjust_op_freq (spinand->spimem, &op); +if (!spi_mem_supports_op (spinand->spimem, &op))break ;
drivers/spi/spi-mem.c +28 -0
@@ -184,6 +184,10 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,return false; } +if (op->max_freq && mem->spi->controller->min_speed_hz && + op->max_freq < mem->spi->controller->min_speed_hz) +return false; +return spi_mem_check_buswidth (mem, op); }EXPORT_SYMBOL_GPL (spi_mem_default_supports_op);
@@ -361,6 +365,9 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)u8 *tmpbuf;int ret; +/* Make sure the operation frequency is correct before going futher */ +spi_mem_adjust_op_freq (mem, (struct spi_mem_op *)op); + ret =spi_mem_check_op (op);if (ret)return ret;
@@ -407,6 +414,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) xfers[xferpos].tx_buf = tmpbuf; xfers[xferpos].len = op->cmd.nbytes; xfers[xferpos].tx_nbits = op->cmd.buswidth; + xfers[xferpos].speed_hz = op->max_freq;spi_message_add_tail (&xfers[xferpos], &msg); xferpos++; totalxferlen++;
@@ -421,6 +429,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) xfers[xferpos].tx_buf = tmpbuf +1 ; xfers[xferpos].len = op->addr.nbytes; xfers[xferpos].tx_nbits = op->addr.buswidth; + xfers[xferpos].speed_hz = op->max_freq;spi_message_add_tail (&xfers[xferpos], &msg); xferpos++; totalxferlen += op->addr.nbytes;
@@ -432,6 +441,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) xfers[xferpos].len = op->dummy.nbytes; xfers[xferpos].tx_nbits = op->dummy.buswidth; xfers[xferpos].dummy_data =1 ; + xfers[xferpos].speed_hz = op->max_freq;spi_message_add_tail (&xfers[xferpos], &msg); xferpos++; totalxferlen += op->dummy.nbytes;
@@ -447,6 +457,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) } xfers[xferpos].len = op->data.nbytes; + xfers[xferpos].speed_hz = op->max_freq;spi_message_add_tail (&xfers[xferpos], &msg); xferpos++; totalxferlen += op->data.nbytes;
@@ -525,6 +536,23 @@ int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op) }EXPORT_SYMBOL_GPL (spi_mem_adjust_op_size); +/** +* spi_mem_adjust_op_freq() - Adjust the frequency of a SPI mem operation to +* match controller, PCB and chip limitations +* @mem: the SPI memory +* @op: the operation to adjust +* +* Some chips have per-op frequency limitations and must adapt the maximum +* speed. This function allows SPI mem drivers to set @op->max_freq to the +* maximum supported value. +*/ +void spi_mem_adjust_op_freq (struct spi_mem *mem,struct spi_mem_op *op) +{ +if (!op->max_freq || op->max_freq > mem->spi->max_speed_hz) + op->max_freq = mem->spi->max_speed_hz; +} +EXPORT_SYMBOL_GPL (spi_mem_adjust_op_freq); +static ssize_t spi_mem_no_dirmap_read (struct spi_mem_dirmap_desc *desc,u64 offs,size_t len,void *buf) {
include/linux/spi/spi-mem.h +11 -1
@@ -68,6 +68,9 @@ enum spi_mem_data_dir { SPI_MEM_DATA_OUT, }; +#define SPI_MEM_OP_MAX_FREQ (__freq) \ + .max_freq = __freq +/** * struct spi_mem_op - describes a SPI memory operation * @cmd.nbytes: number of opcode bytes (only 1 or 2 are valid). The opcode is
@@ -95,6 +98,9 @@ enum spi_mem_data_dir {* operation does not involve transferring data * @data.buf.in: input buffer (must be DMA-able) * @data.buf.out: output buffer (must be DMA-able) +* @max_freq: frequency limitation wrt this operation. 0 means there is no +* specific constraint and the highest achievable frequency can be +* attempted. */ struct spi_mem_op { struct {
@@ -132,14 +138,17 @@ struct spi_mem_op {const void *out; } buf; } data; + +unsigned int max_freq; }; -#define SPI_MEM_OP (__cmd, __addr, __dummy, __data) \ +#define SPI_MEM_OP (__cmd, __addr, __dummy, __data, ...) \ { \ .cmd = __cmd, \ .addr = __addr, \ .dummy = __dummy, \ .data = __data, \ + __VA_ARGS__ \ }/**
@@ -365,6 +374,7 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,#endif /* CONFIG_SPI_MEM */ int spi_mem_adjust_op_size (struct spi_mem *mem,struct spi_mem_op *op); +void spi_mem_adjust_op_freq (struct spi_mem *mem,struct spi_mem_op *op);bool spi_mem_supports_op (struct spi_mem *mem,const struct spi_mem_op *op);
Signature · 1 line
2.39.5
Re: [PATCH 6.12 212/218] spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency
Hi Greg,
Quoted 1 line · Greg Kroah-Hartman
6.12-stable review patch. If anyone has any objections, please let me know.
This and patches 213, 214, and 215 seem to be new features. So why are they being added to a stable release?
Quoted 63 lines
------------------
From: Miquel Raynal <[email protected]>
[ Upstream commit
0fefeade90e74bc8f40ab0e460f483565c492e28]In the spi subsystem, the bus frequency is derived as follows:
- the controller may expose a minimum and maximum operating frequency
- the hardware description, through the spi peripheral properties, advise what is the maximum acceptable frequency from a device/wiring point of view.
Transfers must be observed at a frequency which fits both (so in practice, the lowest maximum).Actually, this second point mixes two information and already takes the lowest frequency among:
- what the spi device is capable of (what is written in the component datasheet)
- what the wiring allows (electromagnetic sensibility, crossovers, terminations, antenna effect, etc).This logic works until spi devices are no longer capable of sustaining their highest frequency regardless of the operation. Spi memories are typically subject to such variation. Some devices are capable of spitting their internally stored data (essentially in read mode) at a very fast rate, typically up to 166MHz on Winbond SPI-NAND chips, using "fast" commands. However, some of the low-end operations, such as regular page read-from-cache commands, are more limited and can only be executed at 54MHz at most. This is currently a problem in the SPI-NAND subsystem. Another situation, even if not yet supported, will be with DTR commands, when the data is latched on both edges of the clock. The same chips as mentioned previously are in this case limited to 80MHz. Yet another example might be continuous reads, which, under certain circumstances, can also run at most at 104 or 120MHz.
As a matter of fact, the "one frequency per chip" policy is outdated and more fine grain configuration is needed: we need to allow per-operation frequency limitations. So far, all datasheets I encountered advertise a maximum default frequency, which need to be lowered for certain specific operations. So based on the current infrastructure, we can still expect firmware (device trees in general) to continued advertising the same maximum speed which is a mix between the PCB limitations and the chip maximum capability, and expect per-operation lower frequencies when this is relevant.
Add a
struct spi_mem_opmember to carry this information. Not providing this field explicitly from upper layers means that there is no further constraint and the default spi device maximum speed will be carried instead. TheSPI_MEM_OP()macro is also expanded with an optional frequency argument, because virtually all operations can be subject to such a limitation, and this will allow for a smooth and discrete transition.For controller drivers which do not implement the spi-mem interface, the per-transfer speed is also set acordingly to a lower (than the maximum default) speed when relevant.
[...]
Signature · 2 lines
Regards, Pratyush Yadav
Greg Kroah-Hartman
maintainerRe: [PATCH 6.12 212/218] spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency
Quoted 8 lines · Pratyush Yadav
Hi Greg,
Quoted 1 line · Greg Kroah-Hartman
6.12-stable review patch. If anyone has any objections, please let me know.
This and patches 213, 214, and 215 seem to be new features. So why are they being added to a stable release?
It was to get commit 40369bfe717e ("spi: fsl-qspi: use devm function instead of driver remove") to apply cleanly. I'll try removing these to see if that commit can still apply somehow...
thanks,
greg k-h
Re: [PATCH 6.12 212/218] spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency
Quoted 11 lines · Greg Kroah-Hartman
Quoted 6 lines · Pratyush Yadav
Quoted 1 line · Greg Kroah-Hartman
6.12-stable review patch. If anyone has any objections, please let me know.
This and patches 213, 214, and 215 seem to be new features. So why are they being added to a stable release?
It was to get commit
40369bfe717e("spi: fsl-qspi: use devm function instead of driver remove") to apply cleanly. I'll try removing these to see if that commit can still apply somehow...
It feels like if this is important for stable it's much safer to do a specific backport rather than pull in new feature enablement?
Greg Kroah-Hartman
maintainerRe: [PATCH 6.12 212/218] spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency
Quoted 9 lines · Mark Brown
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Pratyush Yadav
Quoted 1 line · Greg Kroah-Hartman
6.12-stable review patch. If anyone has any objections, please let me know.
This and patches 213, 214, and 215 seem to be new features. So why are they being added to a stable release?
Quoted 6 lines
Quoted 3 lines
It was to get commit
40369bfe717e("spi: fsl-qspi: use devm function instead of driver remove") to apply cleanly. I'll try removing these to see if that commit can still apply somehow...It feels like if this is important for stable it's much safer to do a specific backport rather than pull in new feature enablement?
I've already dropped them, thanks!
Pratyush Yadav
Reviewed-by Frank LiRe: [PATCH 6.12 212/218] spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency
In reply to Greg Kroah-HartmanQuoted 5 lines · Greg Kroah-Hartman
Quoted 4 lines · Pratyush Yadav
Hi Greg,
On Thu, Jul 03 2025, Greg Kroah-Hartman wrote:
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
6.12-stable review patch. If anyone has any objections, please let me know.
This and patches 213, 214, and 215 seem to be new features. So why are they being added to a stable release?
It was to get commit
40369bfe717e("spi: fsl-qspi: use devm function instead of driver remove") to apply cleanly. I'll try removing these to see if that commit can still apply somehow...
The conflict resolution seems simple. Perhaps the patch below? (**not even compile tested**):
--- 8< ---
From 6edae14f9e968fbb5c566dda8055e92cd491a3a6 Mon Sep 17 00:00:00 2001
From: Han Xu <[email protected]>
Date: Wed, 26 Mar 2025 17:41:51 -0500
Subject: [PATCH] spi: fsl-qspi: use devm function instead of driver remove
Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence.
Trigger kernel panic on i.MX8MQ by
echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind
--- drivers/spi/spi-fsl-qspi.c | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-)
drivers/spi/spi-fsl-qspi.c +17 -14
@@ -839,6 +839,19 @@ static const struct spi_controller_mem_ops fsl_qspi_mem_ops = { .get_name = fsl_qspi_get_name, }; +static void fsl_qspi_cleanup (void *data) +{ +struct fsl_qspi *q = data; + +/* disable the hardware */ +qspi_writel (q,QUADSPI_MCR_MDIS_MASK , q->iobase +QUADSPI_MCR ); +qspi_writel (q,0x0 , q->iobase +QUADSPI_RSER ); + +fsl_qspi_clk_disable_unprep (q); + +mutex_destroy (&q->lock); +} +static int fsl_qspi_probe (struct platform_device *pdev) {struct spi_controller *ctlr;
@@ -928,6 +941,10 @@ static int fsl_qspi_probe(struct platform_device *pdev) ctlr->dev.of_node = np; + ret =devm_add_action_or_reset (dev, fsl_qspi_cleanup, q); +if (ret) + goto err_destroy_mutex; + ret =devm_spi_register_controller (dev, ctlr);if (ret) goto err_destroy_mutex;
@@ -947,19 +964,6 @@ static int fsl_qspi_probe(struct platform_device *pdev)return ret; } -static void fsl_qspi_remove (struct platform_device *pdev) -{ -struct fsl_qspi *q =platform_get_drvdata (pdev); - -/* disable the hardware */ -qspi_writel (q,QUADSPI_MCR_MDIS_MASK , q->iobase +QUADSPI_MCR ); -qspi_writel (q,0x0 , q->iobase +QUADSPI_RSER ); - -fsl_qspi_clk_disable_unprep (q); - -mutex_destroy (&q->lock); -} -static int fsl_qspi_suspend (struct device *dev) {return 0 ;
@@ -997,7 +1001,6 @@ static struct platform_driver fsl_qspi_driver = { .pm = &fsl_qspi_pm_ops, }, .probe = fsl_qspi_probe, - .remove_new = fsl_qspi_remove, };module_platform_driver (fsl_qspi_driver);
Signature · 2 lines
Regards, Pratyush Yadav
Greg Kroah-Hartman
maintainerRe: [PATCH 6.12 212/218] spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency
Quoted 12 lines · Pratyush Yadav
Quoted 10 lines · Greg Kroah-Hartman
Quoted 8 lines · Pratyush Yadav
Hi Greg,
Quoted 1 line · Greg Kroah-Hartman
6.12-stable review patch. If anyone has any objections, please let me know.
This and patches 213, 214, and 215 seem to be new features. So why are they being added to a stable release?
Quoted 6 lines
Quoted 3 lines
It was to get commit
40369bfe717e("spi: fsl-qspi: use devm function instead of driver remove") to apply cleanly. I'll try removing these to see if that commit can still apply somehow...The conflict resolution seems simple. Perhaps the patch below? (**not even compile tested**):
I dropped all but the relevant one now, thanks, and test-built it! :)
greg k-h
Greg Kroah-Hartman
maintainerPATCH 213/218 spi: spi-mem: Add a new controller capability
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miquel Raynal <[email protected]>
[ Upstream commit 1248c9b8d54120950fda10fbeb98fb8932b4d45c ]
There are spi devices with multiple frequency limitations depending on the invoked command. We probably do not want to afford running at the lowest supported frequency all the time, so if we want to get the most of our hardware, we need to allow per-operation frequency limitations.
Among all the SPI memory controllers, I believe all are capable of changing the spi frequency on the fly. Some of the drivers do not make any frequency setup though. And some others will derive a per chip prescaler value which will be used forever.
Actually changing the frequency on the fly is something new in Linux, so we need to carefully flag the drivers which do and do not support it. A controller capability is created for that, and the presence for this capability will always be checked before accepting such pattern.
--- drivers/spi/spi-mem.c | 6 ++++++ include/linux/spi/spi-mem.h | 2 ++ 2 files changed, 8 insertions(+)
drivers/spi/spi-mem.c +6 -0
@@ -188,6 +188,12 @@ bool spi_mem_default_supports_op(struct spi_mem *mem, op->max_freq < mem->spi->controller->min_speed_hz)return false; +if (op->max_freq && + op->max_freq < mem->spi->max_speed_hz) { +if (!spi_mem_controller_is_capable (ctlr, per_op_freq)) +return false; + } +return spi_mem_check_buswidth (mem, op); }EXPORT_SYMBOL_GPL (spi_mem_default_supports_op);
include/linux/spi/spi-mem.h +2 -0
@@ -306,10 +306,12 @@ struct spi_controller_mem_ops {* struct spi_controller_mem_caps - SPI memory controller capabilities * @dtr: Supports DTR operations * @ecc: Supports operations with error correction +* @per_op_freq: Supports per operation frequency switching */ struct spi_controller_mem_caps {bool dtr;bool ecc; +bool per_op_freq; };#define spi_mem_controller_is_capable (ctlr, cap) \
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 214/218 spi: fsl-qspi: Support per spi-mem operation frequency switches
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miquel Raynal <[email protected]>
[ Upstream commit 2438db5253eb17a7c0ccb15aea4252a150dda057 ]
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway.
The per-operation frequency capability is thus advertised to the spi-mem core.
--- drivers/spi/spi-fsl-qspi.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/spi/spi-fsl-qspi.c +9 -3
@@ -522,9 +522,10 @@ static void fsl_qspi_invalidate(struct fsl_qspi *q)qspi_writel (q, reg, q->iobase +QUADSPI_MCR ); } -static void fsl_qspi_select_mem (struct fsl_qspi *q,struct spi_device *spi) +static void fsl_qspi_select_mem (struct fsl_qspi *q,struct spi_device *spi, +const struct spi_mem_op *op) { -unsigned long rate = spi->max_speed_hz; +unsigned long rate = op->max_freq;int ret;if (q->selected ==spi_get_chipselect (spi,0 ))
@@ -652,7 +653,7 @@ static int fsl_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)fsl_qspi_readl_poll_tout (q, base +QUADSPI_SR , (QUADSPI_SR_IP_ACC_MASK |QUADSPI_SR_AHB_ACC_MASK ),10 ,1000 ); -fsl_qspi_select_mem (q, mem->spi); +fsl_qspi_select_mem (q, mem->spi, op);if (needs_amba_base_offset (q)) addr_offset = q->memmap_phy;
@@ -839,6 +840,10 @@ static const struct spi_controller_mem_ops fsl_qspi_mem_ops = { .get_name = fsl_qspi_get_name, }; +static const struct spi_controller_mem_caps fsl_qspi_mem_caps = { + .per_op_freq = true, +}; +static int fsl_qspi_probe (struct platform_device *pdev) {struct spi_controller *ctlr;
@@ -923,6 +928,7 @@ static int fsl_qspi_probe(struct platform_device *pdev) ctlr->bus_num =-1 ; ctlr->num_chipselect =4 ; ctlr->mem_ops = &fsl_qspi_mem_ops; + ctlr->mem_caps = &fsl_qspi_mem_caps;fsl_qspi_default_setup (q);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 215/218 spi: fsl-qspi: use devm function instead of driver remove
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Han Xu <[email protected]>
[ Upstream commit 40369bfe717e96e26650eeecfa5a6363563df6e4 ]
Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence.
Trigger kernel panic on i.MX8MQ by
echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind
--- drivers/spi/spi-fsl-qspi.c | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-)
drivers/spi/spi-fsl-qspi.c +17 -14
@@ -844,6 +844,19 @@ static const struct spi_controller_mem_caps fsl_qspi_mem_caps = { .per_op_freq = true, }; +static void fsl_qspi_cleanup (void *data) +{ +struct fsl_qspi *q = data; + +/* disable the hardware */ +qspi_writel (q,QUADSPI_MCR_MDIS_MASK , q->iobase +QUADSPI_MCR ); +qspi_writel (q,0x0 , q->iobase +QUADSPI_RSER ); + +fsl_qspi_clk_disable_unprep (q); + +mutex_destroy (&q->lock); +} +static int fsl_qspi_probe (struct platform_device *pdev) {struct spi_controller *ctlr;
@@ -934,6 +947,10 @@ static int fsl_qspi_probe(struct platform_device *pdev) ctlr->dev.of_node = np; + ret =devm_add_action_or_reset (dev, fsl_qspi_cleanup, q); +if (ret) + goto err_destroy_mutex; + ret =devm_spi_register_controller (dev, ctlr);if (ret) goto err_destroy_mutex;
@@ -953,19 +970,6 @@ static int fsl_qspi_probe(struct platform_device *pdev)return ret; } -static void fsl_qspi_remove (struct platform_device *pdev) -{ -struct fsl_qspi *q =platform_get_drvdata (pdev); - -/* disable the hardware */ -qspi_writel (q,QUADSPI_MCR_MDIS_MASK , q->iobase +QUADSPI_MCR ); -qspi_writel (q,0x0 , q->iobase +QUADSPI_RSER ); - -fsl_qspi_clk_disable_unprep (q); - -mutex_destroy (&q->lock); -} -static int fsl_qspi_suspend (struct device *dev) {return 0 ;
@@ -1003,7 +1007,6 @@ static struct platform_driver fsl_qspi_driver = { .pm = &fsl_qspi_pm_ops, }, .probe = fsl_qspi_probe, - .remove_new = fsl_qspi_remove, };module_platform_driver (fsl_qspi_driver);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 216/218 btrfs: zoned: fix extent range end unlock in cow_file_range()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Naohiro Aota <[email protected]>
[ Upstream commit 5a4041f2c47247575a6c2e53ce14f7b0ac946c33 ]
Running generic/751 on the for-next branch often results in a hang like below. They are both stack by locking an extent. This suggests someone forget to unlock an extent.
INFO: task kworker/u128:1:12 blocked for more than 323 seconds.
Not tainted 6.13.0-BTRFS-ZNS+ #503
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/u128:1 state:D stack:0 pid:12 tgid:12 ppid:2 flags:0x00004000
Workqueue: btrfs-fixup btrfs_work_helper [btrfs]
Call Trace:
<TASK>
__schedule+0x534/0xdd0
schedule+0x39/0x140
__lock_extent+0x31b/0x380 [btrfs]
? __pfx_autoremove_wake_function+0x10/0x10
btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs]
btrfs_work_helper+0xff/0x480 [btrfs]
? lock_release+0x178/0x2c0
process_one_work+0x1ee/0x570
? srso_return_thunk+0x5/0x5f
worker_thread+0x1d1/0x3b0
? __pfx_worker_thread+0x10/0x10
kthread+0x10b/0x230
? __pfx_kthread+0x10/0x10
ret_from_fork+0x30/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
INFO: task kworker/u134:0:184 blocked for more than 323 seconds.
Not tainted 6.13.0-BTRFS-ZNS+ #503
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/u134:0 state:D stack:0 pid:184 tgid:184 ppid:2 flags:0x00004000
Workqueue: writeback wb_workfn (flush-btrfs-4)
Call Trace:
<TASK>
__schedule+0x534/0xdd0
schedule+0x39/0x140
__lock_extent+0x31b/0x380 [btrfs]
? __pfx_autoremove_wake_function+0x10/0x10
find_lock_delalloc_range+0xdb/0x260 [btrfs]
writepage_delalloc+0x12f/0x500 [btrfs]
? srso_return_thunk+0x5/0x5f
extent_write_cache_pages+0x232/0x840 [btrfs]
btrfs_writepages+0x72/0x130 [btrfs]
do_writepages+0xe7/0x260
? srso_return_thunk+0x5/0x5f
? lock_acquire+0xd2/0x300
? srso_return_thunk+0x5/0x5f
? find_held_lock+0x2b/0x80
? wbc_attach_and_unlock_inode.part.0+0x102/0x250
? wbc_attach_and_unlock_inode.part.0+0x102/0x250
__writeback_single_inode+0x5c/0x4b0
writeback_sb_inodes+0x22d/0x550
__writeback_inodes_wb+0x4c/0xe0
wb_writeback+0x2f6/0x3f0
wb_workfn+0x32a/0x510
process_one_work+0x1ee/0x570
? srso_return_thunk+0x5/0x5f
worker_thread+0x1d1/0x3b0
? __pfx_worker_thread+0x10/0x10
kthread+0x10b/0x230
? __pfx_kthread+0x10/0x10
ret_from_fork+0x30/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>This happens because we have another success path for the zoned mode. When there is no active zone available, btrfs_reserve_extent() returns -EAGAIN. In this case, we have two reactions.
(1) If the given range is never allocated, we can only wait for someone to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry afterward.
(2) Or, if some allocations are already done, we must bail out and let the caller to send IOs for the allocation. This is because these IOs may be necessary to finish a zone.
The commit 06f364284794 ("btrfs: do proper folio cleanup when cow_file_range() failed") moved the unlock code from the inside of the loop to the outside. So, previously, the allocated extents are unlocked just after the allocation and so before returning from the function. However, they are no longer unlocked on the case (2) above. That caused the hang issue.
Fix the issue by modifying the 'end' to the end of the allocated range. Then, we can exit the loop and the same unlock code can properly handle the case.
--- fs/btrfs/inode.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
fs/btrfs/inode.c +7 -2
@@ -1463,8 +1463,13 @@ static noinline int cow_file_range(struct btrfs_inode *inode,continue ; }if (done_offset) { - *done_offset = start -1 ; -return 0 ; +/* +* Move @end to the end of the processed range, +* and exit the loop to unlock the processed extents. +*/ + end = start -1 ; + ret =0 ; +break ; } ret = -ENOSPC ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 217/218 btrfs: fix use-after-free on inode when scanning root during em shrinking
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit 59f37036bb7ab3d554c24abc856aabca01126414 ]
At btrfs_scan_root() we are accessing the inode's root (and fs_info) in a call to btrfs_fs_closing() after we have scheduled the inode for a delayed iput, and that can result in a use-after-free on the inode in case the cleaner kthread does the iput before we dereference the inode in the call to btrfs_fs_closing().
Fix this by using the fs_info stored already in a local variable instead of doing inode->root->fs_info.
--- fs/btrfs/extent_map.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/btrfs/extent_map.c +2 -1
@@ -1250,6 +1250,7 @@ static struct btrfs_inode *find_first_inode_to_shrink(struct btrfs_root *root,static long btrfs_scan_root (struct btrfs_root *root,struct btrfs_em_shrink_ctx *ctx) { +struct btrfs_fs_info *fs_info = root->fs_info;struct btrfs_inode *inode;long nr_dropped =0 ;u64 min_ino = ctx->last_ino +1 ;
@@ -1264,7 +1265,7 @@ static long btrfs_scan_root(struct btrfs_root *root, struct btrfs_em_shrink_ctxiput (&inode->vfs_inode);if (ctx->scanned >= ctx->nr_to_scan || -btrfs_fs_closing (inode->root->fs_info)) +btrfs_fs_closing (fs_info))break ;cond_resched ();
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 218/218 spi: fsl-qspi: Fix double cleanup in probe error path
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kevin Hao <[email protected]>
[ Upstream commit 5d07ab2a7fa1305e429d9221716582f290b58078 ]
Commit 40369bfe717e ("spi: fsl-qspi: use devm function instead of driver remove") introduced managed cleanup via fsl_qspi_cleanup(), but incorrectly retain manual cleanup in two scenarios:
- On devm_add_action_or_reset() failure, the function automatically call fsl_qspi_cleanup(). However, the current code still jumps to err_destroy_mutex, repeating cleanup.
- After the fsl_qspi_cleanup() action is added successfully, there is no need to manually perform the cleanup in the subsequent error path. However, the current code still jumps to err_destroy_mutex on spi controller failure, repeating cleanup.
Skip redundant manual cleanup calls to fix these issues.
--- drivers/spi/spi-fsl-qspi.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
drivers/spi/spi-fsl-qspi.c +2 -5
@@ -949,17 +949,14 @@ static int fsl_qspi_probe(struct platform_device *pdev) ret =devm_add_action_or_reset (dev, fsl_qspi_cleanup, q);if (ret) - goto err_destroy_mutex; + goto err_put_ctrl; ret =devm_spi_register_controller (dev, ctlr);if (ret) - goto err_destroy_mutex; + goto err_put_ctrl;return 0 ; -err_destroy_mutex: -mutex_destroy (&q->lock); - err_disable_clk:fsl_qspi_clk_disable_unprep (q);
Signature · 1 line
2.39.5
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 05 Jul 2025 14:39:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.36-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
The kernel, bpf tool, and perf tool builds fine for v6.12.36-rc1 on x86 and arm64 Azure VM.
Kernel binary size for x86 build:
text data bss dec hex filename 29861525 17728782 6385664 53975971 3379ba3 vmlinux
Kernel binary size for arm64 build:
text data bss dec hex filename 36438156 15006309 1052880 52497345 3210bc1 vmlinux
Thanks,
Hardik
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 05 Jul 2025 14:39:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.36-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 05 Jul 2025 14:39:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.36-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 05 Jul 2025 14:39:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.36-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.12:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
120 tests: 120 pass, 0 failLinux version: 6.12.36-rc1-g08de5e874160
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 05 Jul 2025 14:39:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.36-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.12.36-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 08de5e8741606608ca5489679ec1604bb7f3d777
* git describe: v6.12.35-219-g08de5e874160
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.35-219-g08de5e874160
## Test Regressions (compared to v6.12.34-414-g7ea56ae300ce)
## Metric Regressions (compared to v6.12.34-414-g7ea56ae300ce)
## Test Fixes (compared to v6.12.34-414-g7ea56ae300ce)
## Metric Fixes (compared to v6.12.34-414-g7ea56ae300ce)
## Test result summary
total: 254325, pass: 232385, fail: 5932, skip: 15566, xfail: 442
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 139 total, 137 passed, 2 failed
* arm64: 57 total, 55 passed, 0 failed, 2 skipped
* i386: 18 total, 18 passed, 0 failed
* mips: 34 total, 33 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 40 total, 40 passed, 0 failed
* riscv: 25 total, 23 passed, 2 failed
* s390: 22 total, 21 passed, 1 failed
* sh: 5 total, 5 passed, 0 failed
* sparc: 4 total, 3 passed, 1 failed
* x86_64: 49 total, 48 passed, 0 failed, 1 skipped
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mm
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* modules
* perf
* rcutorture
* rt-tests-cyclicdeadline
* rt-tests-pi-stress
* rt-tests-pmqtest
* rt-tests-rt-migrate-test
* rt-tests-signaltest
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · On Thu, 03 Jul 2025 16:39:08 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 05 Jul 2025 14:39:10 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64:
However, in my loongarch64 built-test, I am seeing:
arch/loongarch/mm/mmap.c:69:21: error: call to undeclared function 'huge_page_mask_align'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
69 | info.align_mask = huge_page_mask_align(filp);
| ^
Which makes sense since that function appeared first in v6.13 in:
7f24cbc9c4d4 ("mm/mmap: teach generic_get_unmapped_area{_topdown} to handle hugetlb mappings")
I hope that helps!
Cheers,
Miguel
Greg KH
maintainerQuoted 22 lines · Miguel Ojeda
Quoted 8 lines · On Thu, 03 Jul 2025 16:39:08 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 05 Jul 2025 14:39:10 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust
x86_64, arm64 and riscv64:Tested-by Miguel Ojeda <[email protected]>However, in my loongarch64 built-test, I am seeing:
arch/loongarch/mm/mmap.c:69:21: error: call to undeclared function 'huge_page_mask_align'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
69 | info.align_mask =huge_page_mask_align(filp);
| ^Which makes sense since that function appeared first in v6.13 in:
Quoted 8 lines
7f24cbc9c4d4("mm/mmap: teach generic_get_unmapped_area{_topdown} to handle hugetlb mappings")Cc Bibo Mao <[email protected]>Cc Huacai Chen <[email protected]>Cc Oscar Salvador <[email protected]>Cc Andrew Morton <[email protected]>I hope that helps!
It did, Sasha fixed this up now, thanks for reporting.
greg k-h
Am 03.07.2025 um 16:39 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
[2025-07-03 16:39] Greg Kroah-Hartman:
Quoted 5 lines
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 7 lines
Responses should be made by Sat, 05 Jul 2025 14:39:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.36-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
Hi Greg,
there seems to be a divergence between 6.12.36-rc1 and the current state of queue/6.12 or stable-queue/queue-6.12 (five patches dropped and two modified), but there doesn't seem to be an rc2 - is this intentional?
In any case, I've applied all patches from the current version of stable-queue/queue-6.12 (commit id c0bc2de2a5416da11ffadb0d10da975d1bdb1ada) applied on top of a 6.12.35 kernel, compiled the result with GCC 15.1.0 as part of OpenWRT images for various platforms, and I've booted and tested those images on the following platforms without noticing any issues:
- x86_64: Intel Haswell VM
- MIPS 4KEc V7.0: Netgear GS108T v3 (SoC: Realtek RTL8380M)
- MIPS 4KEc V7.0: Netgear GS310TP v1 (SoC: Realtek RTL8380M)
- MIPS 74Kc V5.0: TP-Link Archer C7 v4 (SoC: Qualcomm QCA956X)
Not sure it that qualifies for a "Tested-by" though because of the divergence to 6.12.36-rc1.
Regards
Pascal
Greg Kroah-Hartman
maintainerQuoted 15 lines · Pascal Ernster
[2025-07-03 16:39] Greg Kroah-Hartman:
Quoted 5 lines
This is the start of the stable review cycle for the 6.12.36 release. There are 218 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 7 lines
Responses should be made by Sat, 05 Jul 2025 14:39:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.36-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
Quoted 9 lines
Hi Greg,
there seems to be a divergence between 6.12.36-rc1 and the current state of queue/6.12 or stable-queue/queue-6.12 (five patches dropped and two modified), but there doesn't seem to be an rc2 - is this intentional?
Yes, intentional, I only do new -rcs if people are reporting build/run errors on -rcs, but we drop patches that people ask us to drop or fix in the queue without doing new -rc releases as that's not really needed.
Quoted 8 lines
In any case, I've applied all patches from the current version of stable-queue/queue-6.12 (commit id
c0bc2de2a5416da11ffadb0d10da975d1bdb1ada) applied on top of a 6.12.35 kernel, compiled the result with GCC 15.1.0 as part of OpenWRT images for various platforms, and I've booted and tested those images on the following platforms without noticing any issues:-
x86_64: Intel Haswell VM
- MIPS 4KEc V7.0: Netgear GS108T v3 (SoC: Realtek RTL8380M)
- MIPS 4KEc V7.0: Netgear GS310TP v1 (SoC: Realtek RTL8380M)
- MIPS 74Kc V5.0: TP-Link Archer C7 v4 (SoC: Qualcomm QCA956X)Not sure it that qualifies for a "Tested-by" though because of the divergence to 6.12.36-rc1.
A tested-by would be great if you want to provide it, thanks!
greg k-h
Pascal Ernster
Tested-by[2025-07-06 08:51] Greg Kroah-Hartman:
Quoted 3 lines
Yes, intentional, I only do new -rcs if people are reporting build/run errors on -rcs, but we drop patches that people ask us to drop or fix in the queue without doing new -rc releases as that's not really needed.
Ahh, makes sense, thanks for the explanation! :)
Quoted 1 line
A tested-by would be great if you want to provide it, thanks!
Boot-tested on the following platforms:
- x86_64: Intel Haswell VM
- MIPS 4KEc V7.0: Netgear GS108T v3 (SoC: Realtek RTL8380M)
- MIPS 4KEc V7.0: Netgear GS310TP v1 (SoC: Realtek RTL8380M)
- MIPS 74Kc V5.0: TP-Link Archer C7 v4 (SoC: Qualcomm QCA956X)
Regards
Pascal