- Linux-stable-mirror - lists.linaro.org

[PATCH] powerpc/pseries/cmm: fix the error handling in cmm_sysfs_register()

by Haoxiang Li

If device_register() fails, put_device() should be called to drop the device reference. Thus add put_device() after subsys_unregister label and change device_unregister() to device_del() in fail label. Found by code review. Fixes: 6c9d29095264 ("power: cmm - convert sysdev_class to a regular subsystem") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- arch/powerpc/platforms/pseries/cmm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c index 4cbbe2ee58ab..0666d3300bdb 100644 --- a/arch/powerpc/platforms/pseries/cmm.c +++ b/arch/powerpc/platforms/pseries/cmm.c @@ -419,8 +419,9 @@ static int cmm_sysfs_register(struct device *dev) fail: while (--i >= 0) device_remove_file(dev, cmm_attrs[i]); - device_unregister(dev); + device_del(dev); subsys_unregister: + put_device(dev); bus_unregister(&cmm_subsys); return rc; } -- 2.25.1

1 day, 19 hours

2
1
0 0

[PATCH] dmaengine: fix a reference leak in __dma_async_device_channel_register()

by Haoxiang Li

After device_register() is called, put_device() is required to drop the device reference. In this case, put_device() -> chan_dev_release() will finally release chan->dev. Thus there is no need to call kfree again to release the chan->dev. Found by code review. Fixes: d2fb0a043838 ("dmaengine: break out channel registration") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/dma/dmaengine.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c index ca13cd39330b..9d7cea1d6e91 100644 --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -1071,6 +1071,7 @@ static int __dma_async_device_channel_register(struct dma_device *device, const char *name) { int rc; + bool dev_registered = false; chan->local = alloc_percpu(typeof(*chan->local)); if (!chan->local) @@ -1102,6 +1103,7 @@ static int __dma_async_device_channel_register(struct dma_device *device, else dev_set_name(&chan->dev->device, "%s", name); rc = device_register(&chan->dev->device); + dev_registered = true; if (rc) goto err_out_ida; chan->client_count = 0; @@ -1112,7 +1114,10 @@ static int __dma_async_device_channel_register(struct dma_device *device, err_out_ida: ida_free(&device->chan_ida, chan->chan_id); err_free_dev: - kfree(chan->dev); + if (dev_registered) + put_device(&chan->dev->device); + else + kfree(chan->dev); err_free_local: free_percpu(chan->local); chan->local = NULL; -- 2.25.1

1 day, 21 hours

1
0
0 0

[PATCH 0/2] LoongArch: KVM: fix "unreliable stack" issue

by Xianglai Li

When starting multi-core loongarch virtualization on loongarch physical machine, loading livepatch on the physical machine will cause an error similar to the following: [ 411.686289] livepatch: klp_try_switch_task: CPU 31/KVM:3116 has an unreliable stack The specific test steps are as follows: 1.Start a multi-core virtual machine on a physical machine 2.Enter the following command on the physical machine to turn on the debug switch: echo "file kernel/livepatch/transition.c +p" > /sys/kernel/debug/\ dynamic_debug/control 3.Load livepatch: modprobe livepatch-sample Through the above steps, similar prints can be viewed in dmesg. The reason for this issue is that the code of the kvm_exc_entry function was copied in the function kvm_loongarch_env_init. When the cpu needs to execute kvm_exc_entry, it will switch to the copied address for execution. The new address of the kvm_exc_entry function cannot be recognized in ORC, which eventually leads to the arch_stack_walk_reliable function returning an error and printing an exception message. To solve the above problems, we directly compile the switch.S file into the kernel instead of the module. In this way, the function kvm_exc_entry will no longer need to be copied. Cc: Huacai Chen <chenhuacai(a)kernel.org> Cc: WANG Xuerui <kernel(a)xen0n.name> Cc: Tianrui Zhao <zhaotianrui(a)loongson.cn> Cc: Bibo Mao <maobibo(a)loongson.cn> Cc: Charlie Jenkins <charlie(a)rivosinc.com> Cc: Xianglai Li <lixianglai(a)loongson.cn> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Xianglai Li (2): LoongArch: KVM: Compile the switch.S file directly into the kernel LoongArch: KVM: fix "unreliable stack" issue arch/loongarch/Kbuild | 2 +- arch/loongarch/include/asm/asm-prototypes.h | 16 ++++++++++ arch/loongarch/include/asm/kvm_host.h | 5 +-- arch/loongarch/include/asm/kvm_vcpu.h | 20 ++++++------ arch/loongarch/kvm/Makefile | 2 +- arch/loongarch/kvm/main.c | 35 ++------------------- arch/loongarch/kvm/switch.S | 24 +++++++++++--- 7 files changed, 51 insertions(+), 53 deletions(-) base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 -- 2.39.1

1 day, 22 hours

3
6
0 0

[PATCH 6.1.y] spi: cadence-qspi: fix pointer reference in runtime PM hooks

by Zhaoyang Li

From: Théo Lebrun <theo.lebrun(a)bootlin.com> [ Upstream commit 32ce3bb57b6b402de2aec1012511e7ac4e7449dc ] dev_get_drvdata() gets used to acquire the pointer to cqspi and the SPI controller. Neither embed the other; this lead to memory corruption. On a given platform (Mobileye EyeQ5) the memory corruption is hidden inside cqspi->f_pdata. Also, this uninitialised memory is used as a mutex (ctlr->bus_lock_mutex) by spi_controller_suspend(). Fixes: 2087e85bb66e ("spi: cadence-quadspi: fix suspend-resume implementations") Reviewed-by: Dhruva Gole <d-gole(a)ti.com> Signed-off-by: Théo Lebrun <theo.lebrun(a)bootlin.com> Link: https://msgid.link/r/20240222-cdns-qspi-pm-fix-v4-1-6b6af8bcbf59@bootlin.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Zhaoyang Li <lizy04(a)hust.edu.cn> --- drivers/spi/spi-cadence-quadspi.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c index 42861bc45073..02c5f00c8a57 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -1775,10 +1775,9 @@ static int cqspi_remove(struct platform_device *pdev) static int cqspi_suspend(struct device *dev) { struct cqspi_st *cqspi = dev_get_drvdata(dev); - struct spi_master *master = dev_get_drvdata(dev); int ret; - ret = spi_master_suspend(master); + ret = spi_master_suspend(cqspi->master); cqspi_controller_enable(cqspi, 0); clk_disable_unprepare(cqspi->clk); @@ -1789,7 +1788,6 @@ static int cqspi_suspend(struct device *dev) static int cqspi_resume(struct device *dev) { struct cqspi_st *cqspi = dev_get_drvdata(dev); - struct spi_master *master = dev_get_drvdata(dev); clk_prepare_enable(cqspi->clk); cqspi_wait_idle(cqspi); @@ -1798,7 +1796,7 @@ static int cqspi_resume(struct device *dev) cqspi->current_cs = -1; cqspi->sclk = 0; - return spi_master_resume(master); + return spi_master_resume(cqspi->master); } static DEFINE_SIMPLE_DEV_PM_OPS(cqspi_dev_pm_ops, cqspi_suspend, cqspi_resume); -- 2.25.1

1 day, 22 hours

3
3
0 0

[PATCHv3 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

by Pingfan Liu

The kexec segment index will be required to extract the corresponding information for that segment in kimage_map_segment(). Additionally, kexec_segment already holds the kexec relocation destination address and size. Therefore, the prototype of kimage_map_segment() can be changed. Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") Signed-off-by: Pingfan Liu <piliu(a)redhat.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Baoquan He <bhe(a)redhat.com> Cc: Mimi Zohar <zohar(a)linux.ibm.com> Cc: Roberto Sassu <roberto.sassu(a)huawei.com> Cc: Alexander Graf <graf(a)amazon.com> Cc: Steven Chen <chenste(a)linux.microsoft.com> Cc: linux-kernel(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> To: kexec(a)lists.infradead.org To: linux-integrity(a)vger.kernel.org --- include/linux/kexec.h | 4 ++-- kernel/kexec_core.c | 9 ++++++--- security/integrity/ima/ima_kexec.c | 4 +--- 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/include/linux/kexec.h b/include/linux/kexec.h index ff7e231b0485..8a22bc9b8c6c 100644 --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print; #define kexec_dprintk(fmt, arg...) \ do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0) -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size); +extern void *kimage_map_segment(struct kimage *image, int idx); extern void kimage_unmap_segment(void *buffer); #else /* !CONFIG_KEXEC_CORE */ struct pt_regs; @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { } static inline void crash_kexec(struct pt_regs *regs) { } static inline int kexec_should_crash(struct task_struct *p) { return 0; } static inline int kexec_crash_loaded(void) { return 0; } -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size) +static inline void *kimage_map_segment(struct kimage *image, int idx) { return NULL; } static inline void kimage_unmap_segment(void *buffer) { } #define kexec_in_progress false diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index 0f92acdd354d..1a79c5b18d8f 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -953,17 +953,20 @@ int kimage_load_segment(struct kimage *image, int idx) return result; } -void *kimage_map_segment(struct kimage *image, - unsigned long addr, unsigned long size) +void *kimage_map_segment(struct kimage *image, int idx) { + unsigned long addr, size, eaddr; unsigned long src_page_addr, dest_page_addr = 0; - unsigned long eaddr = addr + size; kimage_entry_t *ptr, entry; struct page **src_pages; unsigned int npages; void *vaddr = NULL; int i; + addr = image->segment[idx].mem; + size = image->segment[idx].memsz; + eaddr = addr + size; + /* * Collect the source pages and map them in a contiguous VA range. */ diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c index 7362f68f2d8b..5beb69edd12f 100644 --- a/security/integrity/ima/ima_kexec.c +++ b/security/integrity/ima/ima_kexec.c @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image) if (!image->ima_buffer_addr) return; - ima_kexec_buffer = kimage_map_segment(image, - image->ima_buffer_addr, - image->ima_buffer_size); + ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index); if (!ima_kexec_buffer) { pr_err("Could not map measurements buffer.\n"); return; -- 2.49.0

1 day, 23 hours

2
2
0 0

RE: Patch "cpufreq: dt-platdev: Add JH7110S SOC to the allowlist" has been added to the 6.6-stable tree

by Hal Feng

> On 19.12.25 20:34, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable- > queue.git;a=summary > > The filename of the patch is: > cpufreq-dt-platdev-add-jh7110s-soc-to-the-allowlist.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, please let > <stable(a)vger.kernel.org> know about it. As series [1] is accepted, this patch will be not needed and will be reverted in the mainline. [1] https://lore.kernel.org/all/20251212211934.135602-1-e@freeshell.de/ So we should not add it to the stable tree. Thanks. Best regards, Hal > > > > commit 62295dd3b326acf42f033124c4a48278b71b53a4 > Author: Hal Feng <hal.feng(a)starfivetech.com> > Date: Thu Oct 16 16:00:48 2025 +0800 > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > [ Upstream commit 6e7970cab51d01b8f7c56f120486c571c22e1b80 ] > > Add the compatible strings for supporting the generic > cpufreq driver on the StarFive JH7110S SoC. > > Signed-off-by: Hal Feng <hal.feng(a)starfivetech.com> > Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> > Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq- > dt-platdev.c > index c58c1defd7458..8b53388280d73 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -87,6 +87,7 @@ static const struct of_device_id allowlist[] __initconst = { > { .compatible = "st-ericsson,u9540", }, > > { .compatible = "starfive,jh7110", }, > + { .compatible = "starfive,jh7110s", }, > > { .compatible = "ti,omap2", }, > { .compatible = "ti,omap4", },

1 day, 23 hours

1
0
0 0

[PATCH net v3] net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()

by Xiaolei Wang

In the non-RT kernel, local_bh_disable() merely disables preemption, whereas it maps to an actual spin lock in the RT kernel. Consequently, when attempting to refill RX buffers via netdev_alloc_skb() in macb_mac_link_up(), a deadlock scenario arises as follows: WARNING: possible circular locking dependency detected 6.18.0-08691-g2061f18ad76e #39 Not tainted ------------------------------------------------------ kworker/0:0/8 is trying to acquire lock: ffff00080369bbe0 (&bp->lock){+.+.}-{3:3}, at: macb_start_xmit+0x808/0xb7c but task is already holding lock: ffff000803698e58 (&queue->tx_ptr_lock){+...}-{3:3}, at: macb_start_xmit +0x148/0xb7c which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&queue->tx_ptr_lock){+...}-{3:3}: rt_spin_lock+0x50/0x1f0 macb_start_xmit+0x148/0xb7c dev_hard_start_xmit+0x94/0x284 sch_direct_xmit+0x8c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 -> #2 (_xmit_ETHER#2){+...}-{3:3}: rt_spin_lock+0x50/0x1f0 sch_direct_xmit+0x11c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 -> #1 ((softirq_ctrl.lock)){+.+.}-{3:3}: lock_release+0x250/0x348 __local_bh_enable_ip+0x7c/0x240 __netdev_alloc_skb+0x1b4/0x1d8 gem_rx_refill+0xdc/0x240 gem_init_rings+0xb4/0x108 macb_mac_link_up+0x9c/0x2b4 phylink_resolve+0x170/0x614 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 -> #0 (&bp->lock){+.+.}-{3:3}: __lock_acquire+0x15a8/0x2084 lock_acquire+0x1cc/0x350 rt_spin_lock+0x50/0x1f0 macb_start_xmit+0x808/0xb7c dev_hard_start_xmit+0x94/0x284 sch_direct_xmit+0x8c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 other info that might help us debug this: Chain exists of: &bp->lock --> _xmit_ETHER#2 --> &queue->tx_ptr_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&queue->tx_ptr_lock); lock(_xmit_ETHER#2); lock(&queue->tx_ptr_lock); lock(&bp->lock); *** DEADLOCK *** Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0xa0/0xf0 dump_stack+0x18/0x24 print_circular_bug+0x28c/0x370 check_noncircular+0x198/0x1ac __lock_acquire+0x15a8/0x2084 lock_acquire+0x1cc/0x350 rt_spin_lock+0x50/0x1f0 macb_start_xmit+0x808/0xb7c dev_hard_start_xmit+0x94/0x284 sch_direct_xmit+0x8c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 Notably, invoking the mog_init_rings() callback upon link establishment is unnecessary. Instead, we can exclusively call mog_init_rings() within the ndo_open() callback. This adjustment resolves the deadlock issue. Furthermore, since MACB_CAPS_MACB_IS_EMAC cases do not use mog_init_rings() when opening the network interface via at91ether_open(), moving mog_init_rings() to macb_open() also eliminates the MACB_CAPS_MACB_IS_EMAC check. Fixes: 633e98a711ac ("net: macb: use resolved link config in mac_link_up()") Cc: stable(a)vger.kernel.org Suggested-by: Kevin Hao <kexin.hao(a)windriver.com> Signed-off-by: Xiaolei Wang <xiaolei.wang(a)windriver.com> --- V1: https://patchwork.kernel.org/project/netdevbpf/patch/20251128103647.351259-… V2: Update the correct lock dependency chain and add the Fix tag. V3: update commit log, Add full deadlock log added explanations: because MACB_CAPS_MACB_IS_EMAC cases do not use mog_init_rings(), we don't need the MACB_CAPS_MACB_IS_EMAC check when moving mog_init_rings() to macb_open(). drivers/net/ethernet/cadence/macb_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index ca2386b83473..064fccdcf699 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -744,7 +744,6 @@ static void macb_mac_link_up(struct phylink_config *config, /* Initialize rings & buffers as clearing MACB_BIT(TE) in link down * cleared the pipeline and control registers. */ - bp->macbgem_ops.mog_init_rings(bp); macb_init_buffers(bp); for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) @@ -2991,6 +2990,8 @@ static int macb_open(struct net_device *dev) goto pm_exit; } + bp->macbgem_ops.mog_init_rings(bp); + for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) { napi_enable(&queue->napi_rx); napi_enable(&queue->napi_tx); -- 2.43.0

1 day, 23 hours

1
0
0 0

RE: Patch "cpufreq: dt-platdev: Add JH7110S SOC to the allowlist" has been added to the 6.12-stable tree

by Hal Feng

> On 19.12.25 20:33, Sasha Levin wrote: > > This is a note to let you know that I've just added the patch titled > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable- > queue.git;a=summary > > The filename of the patch is: > cpufreq-dt-platdev-add-jh7110s-soc-to-the-allowlist.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, please let > <stable(a)vger.kernel.org> know about it. As series [1] is accepted, this patch will be not needed and will be reverted in the mainline. [1] https://lore.kernel.org/all/20251212211934.135602-1-e@freeshell.de/ So we should not add it to the stable tree. Thanks. Best regards, Hal > > > > commit fb0dfa5be2ce8716ed8a7a6c8ffb8d36f5e03541 > Author: Hal Feng <hal.feng(a)starfivetech.com> > Date: Thu Oct 16 16:00:48 2025 +0800 > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > [ Upstream commit 6e7970cab51d01b8f7c56f120486c571c22e1b80 ] > > Add the compatible strings for supporting the generic > cpufreq driver on the StarFive JH7110S SoC. > > Signed-off-by: Hal Feng <hal.feng(a)starfivetech.com> > Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> > Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq- > dt-platdev.c > index 67bac12d4d55b..dbd73cd0cf535 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -87,6 +87,7 @@ static const struct of_device_id allowlist[] __initconst = { > { .compatible = "st-ericsson,u9540", }, > > { .compatible = "starfive,jh7110", }, > + { .compatible = "starfive,jh7110s", }, > > { .compatible = "ti,omap2", }, > { .compatible = "ti,omap4", },

1 day, 23 hours

1
0
0 0

RE: Patch "cpufreq: dt-platdev: Add JH7110S SOC to the allowlist" has been added to the 6.18-stable tree

by Hal Feng

> On 19.12.25 20:31, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > to the 6.18-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable- > queue.git;a=summary > > The filename of the patch is: > cpufreq-dt-platdev-add-jh7110s-soc-to-the-allowlist.patch > and it can be found in the queue-6.18 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, please let > <stable(a)vger.kernel.org> know about it. As series [1] is accepted, this patch will be not needed and will be reverted in the mainline. [1] https://lore.kernel.org/all/20251212211934.135602-1-e@freeshell.de/ So we should not add it to the stable tree. Thanks. Best regards, Hal > > > > commit f922a9b37397e7db449e3fa61c33c542ad783f87 > Author: Hal Feng <hal.feng(a)starfivetech.com> > Date: Thu Oct 16 16:00:48 2025 +0800 > > cpufreq: dt-platdev: Add JH7110S SOC to the allowlist > > [ Upstream commit 6e7970cab51d01b8f7c56f120486c571c22e1b80 ] > > Add the compatible strings for supporting the generic > cpufreq driver on the StarFive JH7110S SoC. > > Signed-off-by: Hal Feng <hal.feng(a)starfivetech.com> > Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> > Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq- > dt-platdev.c > index cd1816a12bb99..dc11b62399ad5 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -87,6 +87,7 @@ static const struct of_device_id allowlist[] __initconst = { > { .compatible = "st-ericsson,u9540", }, > > { .compatible = "starfive,jh7110", }, > + { .compatible = "starfive,jh7110s", }, > > { .compatible = "ti,omap2", }, > { .compatible = "ti,omap4", },

1 day, 23 hours

1
0
0 0

ARMv7 Linux + Rust doesn't boot when compiling with only LLVM=1

by Rudraksha Gupta

Hello all, I have the following problem: https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/issues/2635 In short, what is happening is the following: - The kernel boots and outputs via UART when I build the kernel with the following: make LLVM=1 ARCH="$arm" CC="${CC:-gcc}" - The kernel doesn't boot and there is no output via UART when I build the kernel with the following: make LLVM=1 ARCH="$arm" The only difference being: CC="${CC:-gcc}". Is this expected? I think this was present in the Linux kernel ever since Rust was enabled for ARMv7, and I never encountered it because postmarketOS was originally building the first way. Thanks, Rudraksha

2 days, 1 hour

5
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror