July 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] serial: imx: only set receiver level if it is zero" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 9706fc87b4cff0ac4f5d5d62327be83fe72e3108 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024070350-dexterous-unfixable-1a2e@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9706fc87b4cff0ac4f5d5d62327be83fe72e3108 Mon Sep 17 00:00:00 2001 From: Stefan Eichenberger <stefan.eichenberger(a)toradex.com> Date: Wed, 3 Jul 2024 13:25:40 +0200 Subject: [PATCH] serial: imx: only set receiver level if it is zero With commit a81dbd0463ec ("serial: imx: set receiver level before starting uart") we set the receiver level to its default value. This caused a regression when using SDMA, where the receiver level is 9 instead of 8 (default). This change will first check if the receiver level is zero and only then set it to the default. This still avoids the interrupt storm when the receiver level is zero. Fixes: a81dbd0463ec ("serial: imx: set receiver level before starting uart") Cc: stable <stable(a)kernel.org> Signed-off-by: Stefan Eichenberger <stefan.eichenberger(a)toradex.com> Link: https://lore.kernel.org/r/20240703112543.148304-1-eichest@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index f4f40c9373c2..e22be8f45c93 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -120,6 +120,7 @@ #define UCR4_OREN (1<<1) /* Receiver overrun interrupt enable */ #define UCR4_DREN (1<<0) /* Recv data ready interrupt enable */ #define UFCR_RXTL_SHF 0 /* Receiver trigger level shift */ +#define UFCR_RXTL_MASK 0x3F /* Receiver trigger 6 bits wide */ #define UFCR_DCEDTE (1<<6) /* DCE/DTE mode select */ #define UFCR_RFDIV (7<<7) /* Reference freq divider mask */ #define UFCR_RFDIV_REG(x) (((x) < 7 ? 6 - (x) : 6) << 7) @@ -1933,7 +1934,7 @@ static int imx_uart_rs485_config(struct uart_port *port, struct ktermios *termio struct serial_rs485 *rs485conf) { struct imx_port *sport = (struct imx_port *)port; - u32 ucr2; + u32 ucr2, ufcr; if (rs485conf->flags & SER_RS485_ENABLED) { /* Enable receiver if low-active RTS signal is requested */ @@ -1953,7 +1954,10 @@ static int imx_uart_rs485_config(struct uart_port *port, struct ktermios *termio /* Make sure Rx is enabled in case Tx is active with Rx disabled */ if (!(rs485conf->flags & SER_RS485_ENABLED) || rs485conf->flags & SER_RS485_RX_DURING_TX) { - imx_uart_setup_ufcr(sport, TXTL_DEFAULT, RXTL_DEFAULT); + /* If the receiver trigger is 0, set it to a default value */ + ufcr = imx_uart_readl(sport, UFCR); + if ((ufcr & UFCR_RXTL_MASK) == 0) + imx_uart_setup_ufcr(sport, TXTL_DEFAULT, RXTL_DEFAULT); imx_uart_start_rx(port); }

8 months

1
0
0 0

[git:media_stage/master] media: stm32: dcmipp: correct error handling in dcmipp_create_subdevs

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: stm32: dcmipp: correct error handling in dcmipp_create_subdevs Author: Alain Volmat <alain.volmat(a)foss.st.com> Date: Wed Jul 3 13:59:16 2024 +0200 Correct error handling within the dcmipp_create_subdevs by properly decrementing the i counter when releasing the subdevs. Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver") Cc: stable(a)vger.kernel.org Signed-off-by: Alain Volmat <alain.volmat(a)foss.st.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> [hverkuil: correct the indices: it's [i], not [i - 1].] drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- diff --git a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-core.c b/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-core.c index 4acc3b90d03a..7f771ea49b78 100644 --- a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-core.c +++ b/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-core.c @@ -202,8 +202,8 @@ static int dcmipp_create_subdevs(struct dcmipp_device *dcmipp) return 0; err_init_entity: - while (i > 0) - dcmipp->pipe_cfg->ents[i - 1].release(dcmipp->entity[i - 1]); + while (i-- > 0) + dcmipp->pipe_cfg->ents[i].release(dcmipp->entity[i]); return ret; }

8 months

1
0
0 0

[PATCH 2/3] drm/dp_mst: Skip CSN if topology probing is not done yet

by Wayne Lin

[Why] During resume, observe that we receive CSN event before we start topology probing. Handling CSN at this moment based on uncertain topology is unnecessary. [How] Add checking condition in drm_dp_mst_handle_up_req() to skip handling CSN if the topology is yet to be probed. Cc: Lyude Paul <lyude(a)redhat.com> Cc: Harry Wentland <hwentlan(a)amd.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: Imre Deak <imre.deak(a)intel.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: stable(a)vger.kernel.org Signed-off-by: Wayne Lin <Wayne.Lin(a)amd.com> --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index 68831f4e502a..fc2ceae61db2 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -4069,6 +4069,7 @@ static int drm_dp_mst_handle_up_req(struct drm_dp_mst_topology_mgr *mgr) if (up_req->msg.req_type == DP_CONNECTION_STATUS_NOTIFY) { const struct drm_dp_connection_status_notify *conn_stat = &up_req->msg.u.conn_stat; + bool handle_csn; drm_dbg_kms(mgr->dev, "Got CSN: pn: %d ldps:%d ddps: %d mcs: %d ip: %d pdt: %d\n", conn_stat->port_number, @@ -4077,6 +4078,16 @@ static int drm_dp_mst_handle_up_req(struct drm_dp_mst_topology_mgr *mgr) conn_stat->message_capability_status, conn_stat->input_port, conn_stat->peer_device_type); + + mutex_lock(&mgr->probe_lock); + handle_csn = mgr->mst_primary->link_address_sent; + mutex_unlock(&mgr->probe_lock); + + if (!handle_csn) { + drm_dbg_kms(mgr->dev, "Got CSN before finish topology probing. Skip it."); + kfree(up_req); + goto out; + } } else if (up_req->msg.req_type == DP_RESOURCE_STATUS_NOTIFY) { const struct drm_dp_resource_status_notify *res_stat = &up_req->msg.u.resource_stat; -- 2.37.3

8 months

3
5
0 0

[PATCH v2 0/6] clk: qcom: sm8150: Add camera clock controller support for SM8150

by Satya Priya Kakitapalli

Add camcc support and Regera PLL ops. Also, fix the pll post div mask. Signed-off-by: Satya Priya Kakitapalli <quic_skakitap(a)quicinc.com> --- Changes in v2: - As per Konrad's comments, re-use the zonda pll code for regera, as both are mostly same. - Fix the zonda_set_rate API and also the pll_post_div shift used in trion pll post div set rate API - Link to v1: https://lore.kernel.org/r/20240229-camcc-support-sm8150-v1-0-8c28c6c87990@q… --- Satya Priya Kakitapalli (5): clk: qcom: alpha-pll: Fix the pll post div mask and shift clk: qcom: clk-alpha-pll: Update set_rate for Zonda PLL dt-bindings: clock: qcom: Add SM8150 camera clock controller clk: qcom: Add camera clock controller driver for SM8150 arm64: dts: qcom: Add camera clock controller for sm8150 Taniya Das (1): clk: qcom: clk-alpha-pll: Add support for Regera PLL ops .../bindings/clock/qcom,sm8150-camcc.yaml | 77 + arch/arm64/boot/dts/qcom/sa8155p.dtsi | 4 + arch/arm64/boot/dts/qcom/sm8150.dtsi | 13 + drivers/clk/qcom/Kconfig | 9 + drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/camcc-sm8150.c | 2159 ++++++++++++++++++++ drivers/clk/qcom/clk-alpha-pll.c | 56 +- drivers/clk/qcom/clk-alpha-pll.h | 5 + include/dt-bindings/clock/qcom,sm8150-camcc.h | 135 ++ 9 files changed, 2455 insertions(+), 4 deletions(-) --- base-commit: 20af1ca418d2c0b11bc2a1fe8c0c88f67bcc2a7e change-id: 20240229-camcc-support-sm8150-d3f72a4a1a2b Best regards, -- Satya Priya Kakitapalli <quic_skakitap(a)quicinc.com>

8 months

2
3
0 0

[PATCH 5.15 0/3] ipv6/v4: Fix data races around sk->sk_prot and icsk->icsk_af_ops

by Kazunori Kobayashi

For 5.15 kernel, this series includes backports of CVE-2022-3566 and CVE-2022-3567 fixes. Eric Dumazet (1): ipv6: annotate some data-races around sk->sk_prot Kuniyuki Iwashima (2): ipv6: Fix data races around sk->sk_prot. tcp: Fix data races around icsk->icsk_af_ops. net/core/sock.c | 6 ++++-- net/ipv4/af_inet.c | 23 ++++++++++++++++------- net/ipv4/tcp.c | 10 ++++++---- net/ipv6/af_inet6.c | 24 ++++++++++++++++++------ net/ipv6/ipv6_sockglue.c | 9 ++++++--- net/ipv6/tcp_ipv6.c | 6 ++++-- 6 files changed, 54 insertions(+), 24 deletions(-) -- 2.39.2

8 months

2
5
0 0

INQUIRY 2024-SP0006-B(01) INQ24-012209033

by CEO

Good day, We here attached our inquiry for your reference, Could you help quote it? Hope can get your rapid reply. Thank you very much. Ella Liu Thanks & Best regards, Hassei Trading (Shanghai) Co., Ltd. 八星贸易株式会社上海办事处 (日本原厂件一级代理商) Add : Room 1809, No. 38, Lane 2626, Gongji Road, Pudong New Area, Shanghai MP : +86-16601820827 TEL : 021-50673627 Email :h assei_shanghai(a)163.com http: www.hastratok.com Head Office: 7F. Shibadaimon-Yamato Building, 1-6-6 Shibadaimon, Minato Ku, Tokyo 105-0012 Japan

8 months

1
0
0 0

INQUIRY 2024-SP0006-B(01) INQ24-012209033

by CEO

8 months

1
0
0 0

+ mm-fix-crashes-from-deferred-split-racing-folio-migration.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix crashes from deferred split racing folio migration has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-fix-crashes-from-deferred-split-racing-folio-migration.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: mm: fix crashes from deferred split racing folio migration Date: Tue, 2 Jul 2024 00:40:55 -0700 (PDT) Even on 6.10-rc6, I've been seeing elusive "Bad page state"s (often on flags when freeing, yet the flags shown are not bad: PG_locked had been set and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from deferred_split_scan()'s folio_put(), and a variety of other BUG and WARN symptoms implying double free by deferred split and large folio migration. 6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large folio migration") was right to fix the memcg-dependent locking broken in 85ce2c517ade ("memcontrol: only transfer the memcg data for migration"), but missed a subtlety of deferred_split_scan(): it moves folios to its own local list to work on them without split_queue_lock, during which time folio->_deferred_list is not empty, but even the "right" lock does nothing to secure the folio and the list it is on. Fortunately, deferred_split_scan() is careful to use folio_try_get(): so folio_migrate_mapping() can avoid the race by folio_undo_large_rmappable() while the old folio's reference count is temporarily frozen to 0 - adding such a freeze in the !mapping case too (originally, folio lock and unmapping and no swap cache left an anon folio unreachable, so no freezing was needed there: but the deferred split queue offers a way to reach it). Link: https://lkml.kernel.org/r/29c83d1a-11ca-b6c9-f92e-6ccb322af510@google.com Fixes: 9bcef5973e31 ("mm: memcg: fix split queue list crash when large folio migration") Signed-off-by: Hugh Dickins <hughd(a)google.com> Reviewed-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Barry Song <baohua(a)kernel.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Yang Shi <shy828301(a)gmail.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memcontrol.c | 11 ----------- mm/migrate.c | 13 +++++++++++++ 2 files changed, 13 insertions(+), 11 deletions(-) --- a/mm/memcontrol.c~mm-fix-crashes-from-deferred-split-racing-folio-migration +++ a/mm/memcontrol.c @@ -7823,17 +7823,6 @@ void mem_cgroup_migrate(struct folio *ol /* Transfer the charge and the css ref */ commit_charge(new, memcg); - /* - * If the old folio is a large folio and is in the split queue, it needs - * to be removed from the split queue now, in case getting an incorrect - * split queue in destroy_large_folio() after the memcg of the old folio - * is cleared. - * - * In addition, the old folio is about to be freed after migration, so - * removing from the split queue a bit earlier seems reasonable. - */ - if (folio_test_large(old) && folio_test_large_rmappable(old)) - folio_undo_large_rmappable(old); old->memcg_data = 0; } --- a/mm/migrate.c~mm-fix-crashes-from-deferred-split-racing-folio-migration +++ a/mm/migrate.c @@ -415,6 +415,15 @@ int folio_migrate_mapping(struct address if (folio_ref_count(folio) != expected_count) return -EAGAIN; + /* Take off deferred split queue while frozen and memcg set */ + if (folio_test_large(folio) && + folio_test_large_rmappable(folio)) { + if (!folio_ref_freeze(folio, expected_count)) + return -EAGAIN; + folio_undo_large_rmappable(folio); + folio_ref_unfreeze(folio, expected_count); + } + /* No turning back from here */ newfolio->index = folio->index; newfolio->mapping = folio->mapping; @@ -433,6 +442,10 @@ int folio_migrate_mapping(struct address return -EAGAIN; } + /* Take off deferred split queue while frozen and memcg set */ + if (folio_test_large(folio) && folio_test_large_rmappable(folio)) + folio_undo_large_rmappable(folio); + /* * Now we know that no one else is looking at the folio: * no turning back from here. _ Patches currently in -mm which might be from hughd(a)google.com are mm-fix-crashes-from-deferred-split-racing-folio-migration.patch

8 months

1
0
0 0

[PATCH v1] mm: Fix khugepaged activation policy

by Ryan Roberts

Since the introduction of mTHP, the docuementation has stated that khugepaged would be enabled when any mTHP size is enabled, and disabled when all mTHP sizes are disabled. There are 2 problems with this; 1. this is not what was implemented by the code and 2. this is not the desirable behavior. Desirable behavior is for khugepaged to be enabled when any PMD-sized THP is enabled, anon or file. (Note that file THP is still controlled by the top-level control so we must always consider that, as well as the PMD-size mTHP control for anon). khugepaged only supports collapsing to PMD-sized THP so there is no value in enabling it when PMD-sized THP is disabled. So let's change the code and documentation to reflect this policy. Further, per-size enabled control modification events were not previously forwarded to khugepaged to give it an opportunity to start or stop. Consequently the following was resulting in khugepaged eroneously not being activated: echo never > /sys/kernel/mm/transparent_hugepage/enabled echo always > /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Fixes: 3485b88390b0 ("mm: thp: introduce multi-size THP sysfs interface") Closes: https://lore.kernel.org/linux-mm/7a0bbe69-1e3d-4263-b206-da007791a5c4@redha… Cc: stable(a)vger.kernel.org --- Hi All, Applies on top of today's mm-unstable (9bb8753acdd8). No regressions observed in mm selftests. When fixing this I also noticed that khugepaged doesn't get (and never has been) activated/deactivated by `shmem_enabled=`. I'm not sure if khugepaged knows how to collapse shmem - perhaps it should be activated in this case? Thanks, Ryan Documentation/admin-guide/mm/transhuge.rst | 11 +++++------ include/linux/huge_mm.h | 13 +++++++------ mm/huge_memory.c | 7 +++++++ mm/khugepaged.c | 13 ++++++------- 4 files changed, 25 insertions(+), 19 deletions(-) diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index 709fe10b60f4..fc321d40b8ac 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -202,12 +202,11 @@ PMD-mappable transparent hugepage:: cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size -khugepaged will be automatically started when one or more hugepage -sizes are enabled (either by directly setting "always" or "madvise", -or by setting "inherit" while the top-level enabled is set to "always" -or "madvise"), and it'll be automatically shutdown when the last -hugepage size is disabled (either by directly setting "never", or by -setting "inherit" while the top-level enabled is set to "never"). +khugepaged will be automatically started when PMD-sized THP is enabled +(either of the per-size anon control or the top-level control are set +to "always" or "madvise"), and it'll be automatically shutdown when +PMD-sized THP is disabled (when both the per-size anon control and the +top-level control are "never") Khugepaged controls ------------------- diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index 4d155c7a4792..ce1b47b49cc3 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -128,16 +128,17 @@ static inline bool hugepage_global_always(void) (1<<TRANSPARENT_HUGEPAGE_FLAG); } -static inline bool hugepage_flags_enabled(void) +static inline bool hugepage_pmd_enabled(void) { /* - * We cover both the anon and the file-backed case here; we must return - * true if globally enabled, even when all anon sizes are set to never. - * So we don't need to look at huge_anon_orders_inherit. + * We cover both the anon and the file-backed case here; for + * file-backed, we must return true if globally enabled, regardless of + * the anon pmd size control status. So we don't need to look at + * huge_anon_orders_inherit. */ return hugepage_global_enabled() || - READ_ONCE(huge_anon_orders_always) || - READ_ONCE(huge_anon_orders_madvise); + test_bit(PMD_ORDER, &huge_anon_orders_always) || + test_bit(PMD_ORDER, &huge_anon_orders_madvise); } static inline int highest_order(unsigned long orders) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 251d6932130f..085f5e973231 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -502,6 +502,13 @@ static ssize_t thpsize_enabled_store(struct kobject *kobj, } else ret = -EINVAL; + if (ret > 0) { + int err; + + err = start_stop_khugepaged(); + if (err) + ret = err; + } return ret; } diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 409f67a817f1..708d0e74b61f 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -449,7 +449,7 @@ void khugepaged_enter_vma(struct vm_area_struct *vma, unsigned long vm_flags) { if (!test_bit(MMF_VM_HUGEPAGE, &vma->vm_mm->flags) && - hugepage_flags_enabled()) { + hugepage_pmd_enabled()) { if (thp_vma_allowable_order(vma, vm_flags, TVA_ENFORCE_SYSFS, PMD_ORDER)) __khugepaged_enter(vma->vm_mm); @@ -2462,8 +2462,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result, static int khugepaged_has_work(void) { - return !list_empty(&khugepaged_scan.mm_head) && - hugepage_flags_enabled(); + return !list_empty(&khugepaged_scan.mm_head) && hugepage_pmd_enabled(); } static int khugepaged_wait_event(void) @@ -2536,7 +2535,7 @@ static void khugepaged_wait_work(void) return; } - if (hugepage_flags_enabled()) + if (hugepage_pmd_enabled()) wait_event_freezable(khugepaged_wait, khugepaged_wait_event()); } @@ -2567,7 +2566,7 @@ static void set_recommended_min_free_kbytes(void) int nr_zones = 0; unsigned long recommended_min; - if (!hugepage_flags_enabled()) { + if (!hugepage_pmd_enabled()) { calculate_min_free_kbytes(); goto update_wmarks; } @@ -2617,7 +2616,7 @@ int start_stop_khugepaged(void) int err = 0; mutex_lock(&khugepaged_mutex); - if (hugepage_flags_enabled()) { + if (hugepage_pmd_enabled()) { if (!khugepaged_thread) khugepaged_thread = kthread_run(khugepaged, NULL, "khugepaged"); @@ -2643,7 +2642,7 @@ int start_stop_khugepaged(void) void khugepaged_min_free_kbytes_update(void) { mutex_lock(&khugepaged_mutex); - if (hugepage_flags_enabled() && khugepaged_thread) + if (hugepage_pmd_enabled() && khugepaged_thread) set_recommended_min_free_kbytes(); mutex_unlock(&khugepaged_mutex); } -- 2.43.0

8 months

2
5
0 0

[PATCH v1] arm64: dts: imx8mp: Fix VPU PGC power-domain parents

by Vitor Soares

From: Vitor Soares <vitor.soares(a)toradex.com> On iMX8M Plus QuadLite (VPU-less SoC), the dependency between VPU power domains lead to a deferred probe error during boot: [ 17.140195] imx-pgc imx-pgc-domain.8: failed to command PGC [ 17.147183] platform imx-pgc-domain.11: deferred probe pending: (reason unknown) [ 17.147200] platform imx-pgc-domain.12: deferred probe pending: (reason unknown) [ 17.147207] platform imx-pgc-domain.13: deferred probe pending: (reason unknown) This is incorrect and should be the VPU blk-ctrl controlling these power domains, which is already doing it. After removing the `power-domain` property from the VPU PGC nodes, both iMX8M Plus w/ and w/out VPU boot correctly. However, it breaks the suspend/resume functionality. A fix for this is pending, see Links. Cc: <stable(a)vger.kernel.org> Fixes: df680992dd62 ("arm64: dts: imx8mp: add vpu pgc nodes") Link: https://lore.kernel.org/all/fcd6acc268b8642371cf289149b2b1c3e90c7f45.camel@… Link: https://lore.kernel.org/all/20240418155151.355133-1-ivitro@gmail.com/ Suggested-by: Lucas Stach <l.stach(a)pengutronix.de> Signed-off-by: Vitor Soares <vitor.soares(a)toradex.com> --- arch/arm64/boot/dts/freescale/imx8mp.dtsi | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi index b92abb5a5c53..12548336b736 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi @@ -882,21 +882,18 @@ pgc_vpumix: power-domain@19 { pgc_vpu_g1: power-domain@20 { #power-domain-cells = <0>; - power-domains = <&pgc_vpumix>; reg = <IMX8MP_POWER_DOMAIN_VPU_G1>; clocks = <&clk IMX8MP_CLK_VPU_G1_ROOT>; }; pgc_vpu_g2: power-domain@21 { #power-domain-cells = <0>; - power-domains = <&pgc_vpumix>; reg = <IMX8MP_POWER_DOMAIN_VPU_G2>; clocks = <&clk IMX8MP_CLK_VPU_G2_ROOT>; }; pgc_vpu_vc8000e: power-domain@22 { #power-domain-cells = <0>; - power-domains = <&pgc_vpumix>; reg = <IMX8MP_POWER_DOMAIN_VPU_VC8000E>; clocks = <&clk IMX8MP_CLK_VPU_VC8KE_ROOT>; }; -- 2.34.1

8 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2024