February 2025 - Linux-stable-mirror

stable-rc/linux-5.15.y: new build regression: expected ';' at end of declaration in drivers/soc/atmel/...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: expected ';' at end of declaration in drivers/soc/atmel/soc.o (drivers/soc/atmel/soc.c) [logspec:kbuild,kbuild.compiler.error] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:e215ae3b0e6270af8… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:e215ae3b0e6270af8… Log excerpt: drivers/soc/atmel/soc.c:367:24: error: expected ';' at end of declaration 367 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^ | ; 1 error generated. # Builds where the incident occurred: ## defconfig+allmodconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11aa4661a7bc87… #kernelci issue maestro:e215ae3b0e6270af8feaeba47353c1644d7527f8 -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

4 weeks

1
0
0 0

stable-rc/linux-5.15.y: new build regression: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ in drivers/soc/atmel/soc.o (drivers/soc/atmel/soc.c) [logspec:kbuild,kbuild.compiler.error] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:a7eccc80a8c5d40b2… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:a7eccc80a8c5d40b2… Log excerpt: drivers/soc/atmel/soc.c:367:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ 367 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ drivers/soc/atmel/soc.c:367:32: error: implicit declaration of function ‘__free’; did you mean ‘kfree’? [-Werror=implicit-function-declaration] 367 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ | kfree drivers/soc/atmel/soc.c:367:39: error: ‘device_node’ undeclared (first use in this function) 367 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~~~~~~ drivers/soc/atmel/soc.c:367:39: note: each undeclared identifier is reported only once for each function it appears in drivers/soc/atmel/soc.c:369:51: error: ‘np’ undeclared (first use in this function); did you mean ‘nop’? 369 | if (!of_match_node(at91_soc_allowed_list, np)) | ^~ | nop AR drivers/clk/mmp/built-in.a cc1: some warnings being treated as errors CC lib/fdt_strerror.o # Builds where the incident occurred: ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11ab8661a7bc87… ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11ac5661a7bc87… ## multi_v5_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11ac1661a7bc87… #kernelci issue maestro:a7eccc80a8c5d40b2934f6b5b061391e2da155c4 -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

4 weeks

1
0
0 0

stable-rc/linux-5.10.y: new build regression: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ in drivers/soc/atmel/soc.o (drivers/soc/atmel/soc.c) [logspec:kbuild,kbuild.compiler.error] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:066c374be95fc6671… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:066c374be95fc6671… Log excerpt: drivers/soc/atmel/soc.c:278:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ 278 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ drivers/soc/atmel/soc.c:278:32: error: implicit declaration of function ‘__free’; did you mean ‘kfree’? [-Werror=implicit-function-declaration] 278 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ | kfree drivers/soc/atmel/soc.c:278:39: error: ‘device_node’ undeclared (first use in this function) 278 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~~~~~~ drivers/soc/atmel/soc.c:278:39: note: each undeclared identifier is reported only once for each function it appears in drivers/soc/atmel/soc.c:280:51: error: ‘np’ undeclared (first use in this function); did you mean ‘nop’? 280 | if (!of_match_node(at91_soc_allowed_list, np)) | ^~ | nop cc1: some warnings being treated as errors CC drivers/virtio/virtio.o # Builds where the incident occurred: ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a51661a7bc87… ## multi_v5_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a4d661a7bc87… ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a45661a7bc87… #kernelci issue maestro:066c374be95fc6671e95a97b08ffc502a95454b6 -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

4 weeks

1
0
0 0

+ mmmadvisehugetlb-check-for-0-length-range-after-end-address-adjustment.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm,madvise,hugetlb: check for 0-length range after end address adjustment has been added to the -mm mm-hotfixes-unstable branch. Its filename is mmmadvisehugetlb-check-for-0-length-range-after-end-address-adjustment.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: Ricardo Ca��uelo Navarro <rcn(a)igalia.com> Subject: mm,madvise,hugetlb: check for 0-length range after end address adjustment Date: Mon, 3 Feb 2025 08:52:06 +0100 Add a sanity check to madvise_dontneed_free() to address a corner case in madvise where a race condition causes the current vma being processed to be backed by a different page size. During a madvise(MADV_DONTNEED) call on a memory region registered with a userfaultfd, there's a period of time where the process mm lock is temporarily released in order to send a UFFD_EVENT_REMOVE and let userspace handle the event. During this time, the vma covering the current address range may change due to an explicit mmap done concurrently by another thread. If, after that change, the memory region, which was originally backed by 4KB pages, is now backed by hugepages, the end address is rounded down to a hugepage boundary to avoid data loss (see "Fixes" below). This rounding may cause the end address to be truncated to the same address as the start. Make this corner case follow the same semantics as in other similar cases where the requested region has zero length (ie. return 0). This will make madvise_walk_vmas() continue to the next vma in the range (this time holding the process mm lock) which, due to the prev pointer becoming stale because of the vma change, will be the same hugepage-backed vma that was just checked before. The next time madvise_dontneed_free() runs for this vma, if the start address isn't aligned to a hugepage boundary, it'll return -EINVAL, which is also in line with the madvise api. From userspace perspective, madvise() will return EINVAL because the start address isn't aligned according to the new vma alignment requirements (hugepage), even though it was correctly page-aligned when the call was issued. Link: https://lkml.kernel.org/r/20250203075206.1452208-1-rcn@igalia.com Fixes: 8ebe0a5eaaeb ("mm,madvise,hugetlb: fix unexpected data loss with MADV_DONTNEED on hugetlbfs") Signed-off-by: Ricardo Ca��uelo Navarro <rcn(a)igalia.com> Cc: Florent Revest <revest(a)google.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/madvise.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/mm/madvise.c~mmmadvisehugetlb-check-for-0-length-range-after-end-address-adjustment +++ a/mm/madvise.c @@ -933,7 +933,16 @@ static long madvise_dontneed_free(struct */ end = vma->vm_end; } - VM_WARN_ON(start >= end); + /* + * If the memory region between start and end was + * originally backed by 4kB pages and then remapped to + * be backed by hugepages while mmap_lock was dropped, + * the adjustment for hugetlb vma above may have rounded + * end down to the start address. + */ + if (start == end) + return 0; + VM_WARN_ON(start > end); } if (behavior == MADV_DONTNEED || behavior == MADV_DONTNEED_LOCKED) _ Patches currently in -mm which might be from rcn(a)igalia.com are mmmadvisehugetlb-check-for-0-length-range-after-end-address-adjustment.patch

4 weeks

1
0
0 0

[PATCH] usb: dwc3: Fix timeout issue during controller enter/exit from halt state

by Selvarasu Ganesan

There is a frequent timeout during controller enter/exit from halt state after toggling the run_stop bit by SW. This timeout occurs when performing frequent role switches between host and device, causing device enumeration issues due to the timeout. This issue was not present when USB2 suspend PHY was disabled by passing the SNPS quirks (snps,dis_u2_susphy_quirk and snps,dis_enblslpm_quirk) from the DTS. However, there is a requirement to enable USB2 suspend PHY by setting of GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY bits when controller starts in gadget or host mode results in the timeout issue. This commit addresses this timeout issue by ensuring that the bits GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY are cleared before starting the dwc3_gadget_run_stop sequence and restoring them after the dwc3_gadget_run_stop sequence is completed. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- drivers/usb/dwc3/gadget.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index d27af65eb08a..4a158f703d64 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2629,10 +2629,25 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on) { u32 reg; u32 timeout = 2000; + u32 saved_config = 0; if (pm_runtime_suspended(dwc->dev)) return 0; + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); + if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) { + saved_config |= DWC3_GUSB2PHYCFG_SUSPHY; + reg &= ~DWC3_GUSB2PHYCFG_SUSPHY; + } + + if (reg & DWC3_GUSB2PHYCFG_ENBLSLPM) { + saved_config |= DWC3_GUSB2PHYCFG_ENBLSLPM; + reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM; + } + + if (saved_config) + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); if (is_on) { if (DWC3_VER_IS_WITHIN(DWC3, ANY, 187A)) { @@ -2660,6 +2675,12 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on) reg &= DWC3_DSTS_DEVCTRLHLT; } while (--timeout && !(!is_on ^ !reg)); + if (saved_config) { + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); + reg |= saved_config; + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + } + if (!timeout) return -ETIMEDOUT; -- 2.17.1

4 weeks

3
4
0 0

[PATCH v2] usb: dwc3: Fix timeout issue during controller enter/exit from halt state

by Selvarasu Ganesan

There is a frequent timeout during controller enter/exit from halt state after toggling the run_stop bit by SW. This timeout occurs when performing frequent role switches between host and device, causing device enumeration issues due to the timeout. This issue was not present when USB2 suspend PHY was disabled by passing the SNPS quirks (snps,dis_u2_susphy_quirk and snps,dis_enblslpm_quirk) from the DTS. However, there is a requirement to enable USB2 suspend PHY by setting of GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY bits when controller starts in gadget or host mode results in the timeout issue. This commit addresses this timeout issue by ensuring that the bits GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY are cleared before starting the dwc3_gadget_run_stop sequence and restoring them after the dwc3_gadget_run_stop sequence is completed. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- Changes in v2: - Added some comments before the changes. - And removed "unlikely" in the condition check. - Link to v1: https://lore.kernel.org/linux-usb/20250131110832.438-1-selvarasu.g@samsung.… --- drivers/usb/dwc3/gadget.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index d27af65eb08a..ddd6b2ce5710 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2629,10 +2629,38 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on) { u32 reg; u32 timeout = 2000; + u32 saved_config = 0; if (pm_runtime_suspended(dwc->dev)) return 0; + /* + * When operating in USB 2.0 speeds (HS/FS), ensure that + * GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY are cleared before starting + * or stopping the controller. This resolves timeout issues that occur + * during frequent role switches between host and device modes. + * + * Save and clear these settings, then restore them after completing the + * controller start or stop sequence. + * + * This solution was discovered through experimentation as it is not + * mentioned in the dwc3 programming guide. It has been tested on an + * Exynos platforms. + */ + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); + if (reg & DWC3_GUSB2PHYCFG_SUSPHY) { + saved_config |= DWC3_GUSB2PHYCFG_SUSPHY; + reg &= ~DWC3_GUSB2PHYCFG_SUSPHY; + } + + if (reg & DWC3_GUSB2PHYCFG_ENBLSLPM) { + saved_config |= DWC3_GUSB2PHYCFG_ENBLSLPM; + reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM; + } + + if (saved_config) + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); if (is_on) { if (DWC3_VER_IS_WITHIN(DWC3, ANY, 187A)) { @@ -2660,6 +2688,12 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on) reg &= DWC3_DSTS_DEVCTRLHLT; } while (--timeout && !(!is_on ^ !reg)); + if (saved_config) { + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); + reg |= saved_config; + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + } + if (!timeout) return -ETIMEDOUT; -- 2.17.1

4 weeks

2
1
0 0

[PATCH] jiffies: Cast to unsigned long for secs_to_jiffies() conversion

by Easwar Hariharan

While converting users of msecs_to_jiffies(), lkp reported that some range checks would always be true because of the mismatch between the implied int value of secs_to_jiffies() vs the unsigned long return value of the msecs_to_jiffies() calls it was replacing. Fix this by casting secs_to_jiffies() values as unsigned long. Fixes: b35108a51cf7ba ("jiffies: Define secs_to_jiffies()") CC: stable(a)vger.kernel.org # 6.12+ CC: Andrew Morton <akpm(a)linux-foundation.org> Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501301334.NB6NszQR-lkp@intel.com/ Signed-off-by: Easwar Hariharan <eahariha(a)linux.microsoft.com> --- include/linux/jiffies.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h index ed945f42e064..0ea8c9887429 100644 --- a/include/linux/jiffies.h +++ b/include/linux/jiffies.h @@ -537,7 +537,7 @@ static __always_inline unsigned long msecs_to_jiffies(const unsigned int m) * * Return: jiffies value */ -#define secs_to_jiffies(_secs) ((_secs) * HZ) +#define secs_to_jiffies(_secs) (unsigned long)((_secs) * HZ) extern unsigned long __usecs_to_jiffies(const unsigned int u); #if !(USEC_PER_SEC % HZ) -- 2.43.0

4 weeks

4
7
0 0

[PATCH v1] pwm: microchip-core: fix incorrect comparison with max period

by Conor Dooley

From: Conor Dooley <conor.dooley(a)microchip.com> In mchp_core_pwm_apply_locked(), if hw_period_steps is equal to its max, an error is reported and .apply fails. The max value is actually a permitted value however, and so this check can fail where multiple channels are enabled. For example, the first channel to be configured requests a period that sets hw_period_steps to the maximum value, and when a second channel is enabled the driver reads hw_period_steps back from the hardware and finds it to be the maximum possible value, triggering the warning on a permitted value. The value to be avoided is 255 (PERIOD_STEPS_MAX + 1), as that will produce undesired behaviour, so test for greater than, rather than equal to. Fixes: 2bf7ecf7b4ff ("pwm: add microchip soft ip corePWM driver") CC: stable(a)vger.kernel.org Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> --- CC: Conor Dooley <conor.dooley(a)microchip.com> CC: Daire McNamara <daire.mcnamara(a)microchip.com> CC: Uwe Kleine-König <ukleinek(a)kernel.org> CC: Thierry Reding <thierry.reding(a)gmail.com> CC: linux-riscv(a)lists.infradead.org CC: linux-pwm(a)vger.kernel.org CC: linux-kernel(a)vger.kernel.org --- drivers/pwm/pwm-microchip-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/pwm-microchip-core.c b/drivers/pwm/pwm-microchip-core.c index c1f2287b8e97..12821b4bbf97 100644 --- a/drivers/pwm/pwm-microchip-core.c +++ b/drivers/pwm/pwm-microchip-core.c @@ -327,7 +327,7 @@ static int mchp_core_pwm_apply_locked(struct pwm_chip *chip, struct pwm_device * * mchp_core_pwm_calc_period(). * The period is locked and we cannot change this, so we abort. */ - if (hw_period_steps == MCHPCOREPWM_PERIOD_STEPS_MAX) + if (hw_period_steps > MCHPCOREPWM_PERIOD_STEPS_MAX) return -EINVAL; prescale = hw_prescale; -- 2.45.2

4 weeks

3
2
0 0

Re: [Fix CVE-2024-50217 in v6.6.y] [PATCH] btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()

by Greg KH

On Mon, Feb 03, 2025 at 06:45:55PM +0000, Shubham Pushpkar -X (spushpka - E INFOCHIPS PRIVATE LIMITED at Cisco) wrote: > Thank you, Greg, for your feedback and for highlighting the importance > of thorough testing. I apologize for any oversight in my previous > submission. I will ensure that all future patches are rigorously > tested before submission. Again, they must be tested AND have a second signed-off-by from someone else in your company when you resend them as proof of this testing by both of you. thanks, greg k-h

4 weeks

1
0
0 0

stable/linux-6.13.y: new boot regression: WARNING at lib/refcount.c:25 refcount_warn_saturate+0xc8...

by KernelCI bot

Hello, New boot regression found on stable/linux-6.13.y: WARNING at lib/refcount.c:25 refcount_warn_saturate+0xc8/0x148 [logspec:generic_linux_boot,linux.kernel.warning] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:9027cb3b2181d813a… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:9027cb3b2181d813a… Log excerpt: [ 4.653252] refcount_t: addition on 0; use-after-free. [ 4.653261] WARNING: CPU: 5 PID: 187 at lib/refcount.c:25 refcount_warn_saturate+0xc8/0x148 [ 4.653271] Modules linked in: v4l2_mem2mem pcie_mediatek_gen3(+) mt6359_auxadc mtk_rpmsg joydev videobuf2_dma_contig rpmsg_core elan_i2c lvts_thermal(+) mt6577_auxadc snd_soc_mt8195_afe(+) mtk_svs mtk_scp_ipi snd_sof_utils mtk_wdt btusb btintel btbcm btmtk btrtl uvcvideo videobuf2_vmalloc uvc videobuf2_v4l2 mt8195_mt6359 bluetooth ecdh_generic videobuf2_memops ecc videobuf2_common [ 4.653293] CPU: 5 UID: 0 PID: 187 Comm: (udev-worker) Not tainted 6.13.0 #1 c0bd9fe43a50105c5d4fe2d8da4d493a3771f650 [ 4.653296] Hardware name: Acer Tomato (rev2) board (DT) [ 4.653297] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.653298] pc : refcount_warn_saturate+0xc8/0x148 [ 4.653301] lr : refcount_warn_saturate+0xc8/0x148 [ 4.653303] sp : ffff800080c23620 [ 4.653304] x29: ffff800080c23620 x28: ffffda629c274b18 x27: 0000000000000001 [ 4.653306] x26: ffff800080c23930 x25: ffffda62d3588f10 x24: ffff07808558e7f8 [ 4.653308] x23: 0000000000000000 x22: ffff078081075478 x21: ffff800080c236a8 [ 4.653309] x20: 0000000000000000 x19: ffff078081074078 x18: 00000000ffffffff [ 4.653311] x17: 00000000ffffb060 x16: ffffda62d111f5f8 x15: 612d35393138746d [ 4.653313] x14: ffffda62d37fd750 x13: 0a2e656572662d72 x12: ffffda62d3551950 [ 4.653315] x11: 0000000000000001 x10: 0000000000000001 x9 : ffffda62d0943280 [ 4.653316] x8 : c0000000ffffdfff x7 : ffffda62d34a18b0 x6 : 00000000000affa8 [ 4.653318] x5 : ffffda62d35518f8 x4 : 0000000000000000 x3 : 00000000ffffffff [ 4.653320] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff078088140000 [ 4.653322] Call trace: [ 4.653323] refcount_warn_saturate+0xc8/0x148 (P) [ 4.653326] klist_next+0x180/0x1a8 [ 4.653329] bus_for_each_dev+0x6c/0xe8 [ 4.653334] driver_attach+0x2c/0x40 [ 4.653336] bus_add_driver+0xec/0x218 [ 4.653337] driver_register+0x68/0x138 [ 4.653339] __platform_driver_register+0x2c/0x40 [ 4.653341] mt8195_afe_pcm_driver_init+0x28/0xff8 [snd_soc_mt8195_afe 41f903257dcc6a1560bfbd0ddb4cf7a5b6deb9f1] [ 4.653350] do_one_initcall+0x60/0x320 [ 4.653354] do_init_module+0x68/0x258 [ 4.653357] load_module+0x1cf8/0x1de8 [ 4.653359] init_module_from_file+0x8c/0xd8 [ 4.653361] __arm64_sys_finit_module+0x150/0x338 [ 4.653363] invoke_syscall+0x70/0x100 [ 4.653367] el0_svc_common.constprop.0+0x48/0xf0 [ 4.653370] do_el0_svc+0x24/0x38 [ 4.653372] el0_svc+0x34/0xf0 [ 4.653375] el0t_64_sync_handler+0x10c/0x138 [ 4.653377] el0t_64_sync+0x1b0/0x1b8 # Hardware platforms affected: ## mt8195-cherry-tomato-r2 - Compatibles: google,tomato-rev2 | google,tomato | mediatek,mt8195 - Dashboard: https://staging.dashboard.kernelci.org:9000/test/maestro:67a0b86a661a7bc874… #kernelci issue maestro:9027cb3b2181d813ac566c16982a6748748d7ae7 -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025