December 2024 - Linux-stable-mirror

[PATCH] drm/komeda: Add check for komeda_get_layer_fourcc_list()

by Haoxiang Li

Add check for the return value of komeda_get_layer_fourcc_list() to catch the potential exception. Fixes: 5d51f6c0da1b ("drm/komeda: Add writeback support") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c index ebccb74306a7..f30b3d5eeca5 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c @@ -160,6 +160,10 @@ static int komeda_wb_connector_add(struct komeda_kms_dev *kms, formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl, kwb_conn->wb_layer->layer_type, &n_formats); + if (!formats) { + kfree(kwb_conn); + return -ENOMEM; + } err = drm_writeback_connector_init(&kms->base, wb_conn, &komeda_wb_connector_funcs, -- 2.25.1

10 months, 3 weeks

1
0
0 0

[PATCH] drm/komeda: Add check for komeda_get_layer_fourcc_list()

by Haoxiang Li

Add check for the return value of komeda_get_layer_fourcc_list() to catch the potential exception. Fixes: 5d51f6c0da1b ("drm/komeda: Add writeback support") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c index ebccb74306a7..f30b3d5eeca5 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c @@ -160,6 +160,10 @@ static int komeda_wb_connector_add(struct komeda_kms_dev *kms, formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl, kwb_conn->wb_layer->layer_type, &n_formats); + if (!formats) { + kfree(kwb_conn); + return -ENOMEM; + } err = drm_writeback_connector_init(&kms->base, wb_conn, &komeda_wb_connector_funcs, -- 2.25.1

10 months, 3 weeks

1
0
0 0

[PATCH net] tcp: check space before adding MPTCP SYN options

by Matthieu Baerts (NGI0)

From: MoYuanhao <moyuanhao3676(a)163.com> Ensure there is enough space before adding MPTCP options in tcp_syn_options(). Without this check, 'remaining' could underflow, and causes issues. If there is not enough space, MPTCP should not be used. Signed-off-by: MoYuanhao <moyuanhao3676(a)163.com> Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connections") Cc: stable(a)vger.kernel.org Acked-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> [ Matt: Add Fixes, cc Stable, update Description ] Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- net/ipv4/tcp_output.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 5485a70b5fe5a6039d19f4321c3c2ec8ecc6ffea..0e5b9a654254b32907ee9739f3443791104bd611 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -883,8 +883,10 @@ static unsigned int tcp_syn_options(struct sock *sk, struct sk_buff *skb, unsigned int size; if (mptcp_syn_options(sk, skb, &size, &opts->mptcp)) { - opts->options |= OPTION_MPTCP; - remaining -= size; + if (remaining >= size) { + opts->options |= OPTION_MPTCP; + remaining -= size; + } } } --- base-commit: 09310cfd4ea5c3ab2c7a610420205e0a1660bf7e change-id: 20241209-net-mptcp-check-space-syn-5694196ffb5f Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

10 months, 3 weeks

3
2
0 0

[PATCH] usb: dwc3-am62: Disable autosuspend during remove

by Prashanth K

Runtime PM documentation (Section 5) mentions, during remove() callbacks, drivers should undo the runtime PM changes done in probe(). Usually this means calling pm_runtime_disable(), pm_runtime_dont_use_autosuspend() etc. Hence add missing function to disable autosuspend on dwc3-am62 driver unbind. Fixes: e8784c0aec03 ("drivers: usb: dwc3: Add AM62 USB wrapper driver") Cc: stable(a)vger.kernel.org Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com> --- drivers/usb/dwc3/dwc3-am62.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc3/dwc3-am62.c b/drivers/usb/dwc3/dwc3-am62.c index 5e3d1741701f..7d43da5f2897 100644 --- a/drivers/usb/dwc3/dwc3-am62.c +++ b/drivers/usb/dwc3/dwc3-am62.c @@ -309,6 +309,7 @@ static void dwc3_ti_remove(struct platform_device *pdev) pm_runtime_put_sync(dev); pm_runtime_disable(dev); + pm_runtime_dont_use_autosuspend(dev); pm_runtime_set_suspended(dev); } -- 2.25.1

10 months, 3 weeks

2
1
0 0

+ mm-page_alloc-dont-call-pfn_to_page-on-possibly-non-existent-pfn-in-split_large_buddy.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy() has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-page_alloc-dont-call-pfn_to_page-on-possibly-non-existent-pfn-in-split_large_buddy.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: David Hildenbrand <david(a)redhat.com> Subject: mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy() Date: Tue, 10 Dec 2024 10:34:37 +0100 In split_large_buddy(), we might call pfn_to_page() on a PFN that might not exist. In corner cases, such as when freeing the highest pageblock in the last memory section, this could result with CONFIG_SPARSEMEM && !CONFIG_SPARSEMEM_EXTREME in __pfn_to_section() returning NULL and and __section_mem_map_addr() dereferencing that NULL pointer. Let's fix it, and avoid doing a pfn_to_page() call for the first iteration, where we already have the page. So far this was found by code inspection, but let's just CC stable as the fix is easy. Link: https://lkml.kernel.org/r/20241210093437.174413-1-david@redhat.com Fixes: fd919a85cd55 ("mm: page_isolation: prepare for hygienic freelists") Signed-off-by: David Hildenbrand <david(a)redhat.com> Reported-by: Vlastimil Babka <vbabka(a)suse.cz> Closes: https://lkml.kernel.org/r/e1a898ba-a717-4d20-9144-29df1a6c8813@suse.cz Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> Reviewed-by: Zi Yan <ziy(a)nvidia.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Yu Zhao <yuzhao(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/mm/page_alloc.c~mm-page_alloc-dont-call-pfn_to_page-on-possibly-non-existent-pfn-in-split_large_buddy +++ a/mm/page_alloc.c @@ -1238,13 +1238,15 @@ static void split_large_buddy(struct zon if (order > pageblock_order) order = pageblock_order; - while (pfn != end) { + do { int mt = get_pfnblock_migratetype(page, pfn); __free_one_page(page, pfn, zone, order, mt, fpi); pfn += 1 << order; + if (pfn == end) + break; page = pfn_to_page(pfn); - } + } while (1); } static void free_one_page(struct zone *zone, struct page *page, _ Patches currently in -mm which might be from david(a)redhat.com are mm-page_alloc-dont-call-pfn_to_page-on-possibly-non-existent-pfn-in-split_large_buddy.patch docs-tmpfs-update-the-large-folios-policy-for-tmpfs-and-shmem.patch mm-memory_hotplug-move-debug_pagealloc_map_pages-into-online_pages_range.patch mm-page_isolation-dont-pass-gfp-flags-to-isolate_single_pageblock.patch mm-page_isolation-dont-pass-gfp-flags-to-start_isolate_page_range.patch mm-page_alloc-make-__alloc_contig_migrate_range-static.patch mm-page_alloc-sort-out-the-alloc_contig_range-gfp-flags-mess.patch mm-page_alloc-forward-the-gfp-flags-from-alloc_contig_range-to-post_alloc_hook.patch powernv-memtrace-use-__gfp_zero-with-alloc_contig_pages.patch mm-hugetlb-dont-map-folios-writable-without-vm_write-when-copying-during-fork.patch fs-proc-vmcore-convert-vmcore_cb_lock-into-vmcore_mutex.patch fs-proc-vmcore-replace-vmcoredd_mutex-by-vmcore_mutex.patch fs-proc-vmcore-disallow-vmcore-modifications-while-the-vmcore-is-open.patch fs-proc-vmcore-prefix-all-pr_-with-vmcore.patch fs-proc-vmcore-move-vmcore-definitions-out-of-kcoreh.patch fs-proc-vmcore-factor-out-allocating-a-vmcore-range-and-adding-it-to-a-list.patch fs-proc-vmcore-factor-out-freeing-a-list-of-vmcore-ranges.patch fs-proc-vmcore-introduce-proc_vmcore_device_ram-to-detect-device-ram-ranges-in-2nd-kernel.patch virtio-mem-mark-device-ready-before-registering-callbacks-in-kdump-mode.patch virtio-mem-remember-usable-region-size.patch virtio-mem-support-config_proc_vmcore_device_ram.patch s390-kdump-virtio-mem-kdump-support-config_proc_vmcore_device_ram.patch mm-page_alloc-conditionally-split-pageblock_order-pages-in-free_one_page-and-move_freepages_block_isolate.patch mm-page_isolation-fixup-isolate_single_pageblock-comment-regarding-splitting-free-pages.patch mm-page_alloc-dont-use-__gfp_hardwall-when-migrating-pages-via-alloc_contig.patch mm-memory_hotplug-dont-use-__gfp_hardwall-when-migrating-pages-via-memory-offlining.patch

10 months, 3 weeks

1
0
0 0

[PATCH v7 0/3] clk: qcom: Add support for multiple power-domains for a clock controller.

by Bryan O'Donoghue

Changes in v7: - Expand commit log in patch #3 I've discussed with Bjorn on IRC and video what to put into the log here and captured most of what we discussed. Mostly the point here is voting for voltages in the power-domain list is up to the drivers to do with performance states/opp-tables not for the GDSC code. - Bjorn/Bryan - Link to v6: https://lore.kernel.org/r/20241129-b4-linux-next-24-11-18-clock-multiple-po… Changes in v6: - Passes NULL to second parameter of devm_pm_domain_attach_list - Vlad - Link to v5: https://lore.kernel.org/r/20241128-b4-linux-next-24-11-18-clock-multiple-po… Changes in v5: - In-lines devm_pm_domain_attach_list() in probe() directly - Vlad - Link to v4: https://lore.kernel.org/r/20241127-b4-linux-next-24-11-18-clock-multiple-po… v4: - Adds Bjorn's RB to first patch - Bjorn - Drops the 'd' in "and int" - Bjorn - Amends commit log of patch 3 to capture a number of open questions - Bjorn - Link to v3: https://lore.kernel.org/r/20241126-b4-linux-next-24-11-18-clock-multiple-po… v3: - Fixes commit log "per which" - Bryan - Link to v2: https://lore.kernel.org/r/20241125-b4-linux-next-24-11-18-clock-multiple-po… v2: The main change in this version is Bjorn's pointing out that pm_runtime_* inside of the gdsc_enable/gdsc_disable path would be recursive and cause a lockdep splat. Dmitry alluded to this too. Bjorn pointed to stuff being done lower in the gdsc_register() routine that might be a starting point. I iterated around that idea and came up with patch #3. When a gdsc has no parent and the pd_list is non-NULL then attach that orphan GDSC to the clock controller power-domain list. Existing subdomain code in gdsc_register() will connect the parent GDSCs in the clock-controller to the clock-controller subdomain, the new code here does that same job for a list of power-domains the clock controller depends on. To Dmitry's point about MMCX and MCX dependencies for the registers inside of the clock controller, I have switched off all references in a test dtsi and confirmed that accessing the clock-controller regs themselves isn't required. On the second point I also verified my test branch with lockdep on which was a concern with the pm_domain version of this solution but I wanted to cover it anyway with the new approach for completeness sake. Here's the item-by-item list of changes: - Adds a patch to capture pm_genpd_add_subdomain() result code - Bryan - Changes changelog of second patch to remove singleton and generally to make the commit log easier to understand - Bjorn - Uses demv_pm_domain_attach_list - Vlad - Changes error check to if (ret < 0 && ret != -EEXIST) - Vlad - Retains passing &pd_data instead of NULL - because NULL doesn't do the same thing - Bryan/Vlad - Retains standalone function qcom_cc_pds_attach() because the pd_data enumeration looks neater in a standalone function - Bryan/Vlad - Drops pm_runtime in favour of gdsc_add_subdomain_list() for each power-domain in the pd_list. The pd_list will be whatever is pointed to by power-domains = <> in the dtsi - Bjorn - Link to v1: https://lore.kernel.org/r/20241118-b4-linux-next-24-11-18-clock-multiple-po… v1: On x1e80100 and it's SKUs the Camera Clock Controller - CAMCC has multiple power-domains which power it. Usually with a single power-domain the core platform code will automatically switch on the singleton power-domain for you. If you have multiple power-domains for a device, in this case the clock controller, you need to switch those power-domains on/off yourself. The clock controllers can also contain Global Distributed Switch Controllers - GDSCs which themselves can be referenced from dtsi nodes ultimately triggering a gdsc_en() in drivers/clk/qcom/gdsc.c. As an example: cci0: cci@ac4a000 { power-domains = <&camcc TITAN_TOP_GDSC>; }; This series adds the support to attach a power-domain list to the clock-controllers and the GDSCs those controllers provide so that in the case of the above example gdsc_toggle_logic() will trigger the power-domain list with pm_runtime_resume_and_get() and pm_runtime_put_sync() respectively. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org> --- Bryan O'Donoghue (3): clk: qcom: gdsc: Capture pm_genpd_add_subdomain result code clk: qcom: common: Add support for power-domain attachment clk: qcom: Support attaching GDSCs to multiple parents drivers/clk/qcom/common.c | 10 ++++++++++ drivers/clk/qcom/gdsc.c | 41 +++++++++++++++++++++++++++++++++++++++-- drivers/clk/qcom/gdsc.h | 1 + 3 files changed, 50 insertions(+), 2 deletions(-) --- base-commit: 744cf71b8bdfcdd77aaf58395e068b7457634b2c change-id: 20241118-b4-linux-next-24-11-18-clock-multiple-power-domains-a5f994dc452a Best regards, -- Bryan O'Donoghue <bryan.odonoghue(a)linaro.org>

10 months, 3 weeks

1
1
0 0

[PATCH v2] usb: dwc3: gadget: fix writing NYET threshold

by André Draszik

Before writing a new value to the register, the old value needs to be masked out for the new value to be programmed as intended, because at least in some cases the reset value of that field is 0xf (max value). At the moment, the dwc3 core initialises the threshold to the maximum value (0xf), with the option to override it via a DT. No upstream DTs seem to override it, therefore this commit doesn't change behaviour for any upstream platform. Nevertheless, the code should be fixed to have the desired outcome. Do so. Fixes: 80caf7d21adc ("usb: dwc3: add lpm erratum support") Cc: stable(a)vger.kernel.org # 5.10+ (needs adjustment for 5.4) Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- Changes in v2: - change mask definitions to be consistent with other masks (Thinh) - udpate commit message to clarify that in some cases the reset value is != 0 - Link to v1: https://lore.kernel.org/r/20241206-dwc3-nyet-fix-v1-1-293bc74f644f@linaro.o… --- For stable-5.4, the if() test is slightly different, so a separate patch will be sent for it for the patch to apply. --- drivers/usb/dwc3/core.h | 1 + drivers/usb/dwc3/gadget.c | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index ee73789326bc..f11570c8ffd0 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -464,6 +464,7 @@ #define DWC3_DCTL_TRGTULST_SS_INACT (DWC3_DCTL_TRGTULST(6)) /* These apply for core versions 1.94a and later */ +#define DWC3_DCTL_NYET_THRES_MASK (0xf << 20) #define DWC3_DCTL_NYET_THRES(n) (((n) & 0xf) << 20) #define DWC3_DCTL_KEEP_CONNECT BIT(19) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 83dc7304d701..31a654c6f15b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -4195,8 +4195,10 @@ static void dwc3_gadget_conndone_interrupt(struct dwc3 *dwc) WARN_ONCE(DWC3_VER_IS_PRIOR(DWC3, 240A) && dwc->has_lpm_erratum, "LPM Erratum not available on dwc3 revisions < 2.40a\n"); - if (dwc->has_lpm_erratum && !DWC3_VER_IS_PRIOR(DWC3, 240A)) + if (dwc->has_lpm_erratum && !DWC3_VER_IS_PRIOR(DWC3, 240A)) { + reg &= ~DWC3_DCTL_NYET_THRES_MASK; reg |= DWC3_DCTL_NYET_THRES(dwc->lpm_nyet_threshold); + } dwc3_gadget_dctl_write_safe(dwc, reg); } else { --- base-commit: c245a7a79602ccbee780c004c1e4abcda66aec32 change-id: 20241206-dwc3-nyet-fix-7085f6d71d04 Best regards, -- André Draszik <andre.draszik(a)linaro.org>

10 months, 3 weeks

2
1
0 0

[PATCH v2] EDAC/amd64: Fix possible module load failure on some UMC usage combinations

by Avadhut Naik

Starting Zen4, AMD SOCs have 12 Unified Memory Controllers (UMCs) per socket. When the amd64_edac module is being loaded, these UMCs are traversed to determine if they have SdpInit (SdpCtrl[31]) and EccEnabled (UmcCapHi[30]) bits set and create masks in umc_en_mask and ecc_en_mask respectively. However, the current data type of these variables is u8. As a result, if only the last 4 UMCs (UMC8 - UMC11) of the system have been utilized, umc_ecc_enabled() will return false. Consequently, the module may fail to load on these systems. Fixes: e2be5955a886 ("EDAC/amd64: Add support for AMD Family 19h Models 10h-1Fh and A0h-AFh") Signed-off-by: Avadhut Naik <avadhut.naik(a)amd.com> Cc: stable(a)vger.kernel.org --- Changes in v2: 1. Change data type of variables from u16 to int. (Boris) 2. Modify commit message per feedback. (Boris) 3. Add Fixes: and CC:stable tags. (Boris) --- drivers/edac/amd64_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c index ddfbdb66b794..b1c034214a8d 100644 --- a/drivers/edac/amd64_edac.c +++ b/drivers/edac/amd64_edac.c @@ -3362,7 +3362,7 @@ static bool dct_ecc_enabled(struct amd64_pvt *pvt) static bool umc_ecc_enabled(struct amd64_pvt *pvt) { - u8 umc_en_mask = 0, ecc_en_mask = 0; + int umc_en_mask = 0, ecc_en_mask = 0; u16 nid = pvt->mc_node_id; struct amd64_umc *umc; u8 ecc_en = 0, i; base-commit: f84722cbed6c2b2094ad8bbe48be2c5900752935 -- 2.43.0

10 months, 3 weeks

1
0
0 0

[PATCH v1] mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()

by David Hildenbrand

In split_large_buddy(), we might call pfn_to_page() on a PFN that might not exist. In corner cases, such as when freeing the highest pageblock in the last memory section, this could result with CONFIG_SPARSEMEM && !CONFIG_SPARSEMEM_EXTREME in __pfn_to_section() returning NULL and and __section_mem_map_addr() dereferencing that NULL pointer. Let's fix it, and avoid doing a pfn_to_page() call for the first iteration, where we already have the page. So far this was found by code inspection, but let's just CC stable as the fix is easy. Fixes: fd919a85cd55 ("mm: page_isolation: prepare for hygienic freelists") Reported-by: Vlastimil Babka <vbabka(a)suse.cz> Closes: https://lkml.kernel.org/r/e1a898ba-a717-4d20-9144-29df1a6c8813@suse.cz Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Zi Yan <ziy(a)nvidia.com> Cc: Yu Zhao <yuzhao(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- mm/page_alloc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 48a291c485df4..a52c6022c65cb 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1238,13 +1238,15 @@ static void split_large_buddy(struct zone *zone, struct page *page, if (order > pageblock_order) order = pageblock_order; - while (pfn != end) { + do { int mt = get_pfnblock_migratetype(page, pfn); __free_one_page(page, pfn, zone, order, mt, fpi); pfn += 1 << order; + if (pfn == end) + break; page = pfn_to_page(pfn); - } + } while (1); } static void free_one_page(struct zone *zone, struct page *page, -- 2.47.1

10 months, 3 weeks

4
4
0 0

[stble-kernel][5.15.y][5.10.y][PATCH v2] serial: sc16is7xx: the reg needs to shift in regmap_noinc

by Hui Wang

Recently we found the fifo_read() and fifo_write() are broken in our 5.15 and 5.4 kernels after cherry-pick the commit e635f652696e ("serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO"), that is because the reg needs to shift if we don't cherry-pick a prerequisite commit 3837a0379533 ("serial: sc16is7xx: improve regmap debugfs by using one regmap per port"). It is hard to backport the prerequisite commit to 5.15.y and 5.10.y due to the significant conflict. To be safe, here fix it by shifting the reg as regmap_volatile() does. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- in the V2: add Cc: fix a typo on prerequisite add explanation for not backporting the prerequisite patch to 5.15.y and 5.10.y drivers/tty/serial/sc16is7xx.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index d274a847c6ab..87e34099f369 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -487,7 +487,14 @@ static bool sc16is7xx_regmap_precious(struct device *dev, unsigned int reg) static bool sc16is7xx_regmap_noinc(struct device *dev, unsigned int reg) { - return reg == SC16IS7XX_RHR_REG; + switch (reg >> SC16IS7XX_REG_SHIFT) { + case SC16IS7XX_RHR_REG: + return true; + default: + break; + } + + return false; } /* -- 2.34.1

10 months, 3 weeks

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024