Extend spi-nor and nvram support and dynamic size#179
Closed
jannau wants to merge 7 commits intoAsahiLinux:bits/000-devicetreefrom
Closed
Extend spi-nor and nvram support and dynamic size#179jannau wants to merge 7 commits intoAsahiLinux:bits/000-devicetreefrom
jannau wants to merge 7 commits intoAsahiLinux:bits/000-devicetreefrom
Conversation
marcan
force-pushed
the
bits/000-devicetree
branch
from
2cbea85 to
3b6f774
Compare
jannau
force-pushed
the
bits/000-devicetree_spi-nor
branch
from
5dd1974 to
1b2055f
Compare
jannau
force-pushed
the
bits/000-devicetree_spi-nor
branch
from
1b2055f to
7a703d6
Compare
jannau
changed the title
jannau
changed the title
All devices use an identical SPI nor/nvram setup so move that to dtsi file they all can include. Since the nvram partition size depends on the iboot version disable the nvram partition and have m1n1 enable it after it has filled the correct values from the ADT. Signed-off-by: Janne Grunau <j@jannau.net>
…tion Signed-off-by: Janne Grunau <j@jannau.net>
…tion Signed-off-by: Janne Grunau <j@jannau.net>
Should probably be squashed into the commit adding this in the first place. Signed-off-by: Janne Grunau <j@jannau.net>
Should probably be squashed into the commit adding this in the first place. Signed-off-by: Janne Grunau <j@jannau.net>
Should probably be squashed into the commit adding this in the first place. Signed-off-by: Janne Grunau <j@jannau.net>
The size depends on the macOS version of the stub partition do m1n1 has to fill in the size based on the ADT. So this override becomes unnecessary. should be squashed inot the commit adding this Signed-off-by: Janne Grunau <j@jannau.net>
jannau
force-pushed
the
bits/000-devicetree_spi-nor
branch
from
7a703d6 to
386b6f3
Compare
|
Manually rebased, thanks! |
asdfugil
pushed a commit
to HoolockLinux/linux
that referenced
this pull request
Jan 7, 2026
When smc91x.c is built with PREEMPT_RT, the following splat occurs in FVP_RevC: [ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000 [ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106] [ 13.062137] preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work [ 13.062266] C ** replaying previous printk message ** [ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty AsahiLinux#179 PREEMPT_{RT,(full)} [ 13.062353] Hardware name: , BIOS [ 13.062382] Workqueue: mld mld_ifc_work [ 13.062469] Call trace: [ 13.062494] show_stack+0x24/0x40 (C) [ 13.062602] __dump_stack+0x28/0x48 [ 13.062710] dump_stack_lvl+0x7c/0xb0 [ 13.062818] dump_stack+0x18/0x34 [ 13.062926] process_scheduled_works+0x294/0x450 [ 13.063043] worker_thread+0x260/0x3d8 [ 13.063124] kthread+0x1c4/0x228 [ 13.063235] ret_from_fork+0x10/0x20 This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT, but smc_special_unlock() does not restore IRQs on PREEMPT_RT. The reason is that smc_special_unlock() calls spin_unlock_irqrestore(), and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke rcu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero. To address this issue, replace smc_special_trylock() with spin_trylock_irqsave(). Fixes: 342a932 ("locking/spinlock: Provide RT variant header: <linux/spinlock_rt.h>") Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251217085115.1730036-1-yeoreum.yun@arm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
jannau
pushed a commit
that referenced
this pull request
Jan 9, 2026
[ Upstream commit 6402078 ] When smc91x.c is built with PREEMPT_RT, the following splat occurs in FVP_RevC: [ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000 [ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106] [ 13.062137] preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work [ 13.062266] C ** replaying previous printk message ** [ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)} [ 13.062353] Hardware name: , BIOS [ 13.062382] Workqueue: mld mld_ifc_work [ 13.062469] Call trace: [ 13.062494] show_stack+0x24/0x40 (C) [ 13.062602] __dump_stack+0x28/0x48 [ 13.062710] dump_stack_lvl+0x7c/0xb0 [ 13.062818] dump_stack+0x18/0x34 [ 13.062926] process_scheduled_works+0x294/0x450 [ 13.063043] worker_thread+0x260/0x3d8 [ 13.063124] kthread+0x1c4/0x228 [ 13.063235] ret_from_fork+0x10/0x20 This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT, but smc_special_unlock() does not restore IRQs on PREEMPT_RT. The reason is that smc_special_unlock() calls spin_unlock_irqrestore(), and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke rcu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero. To address this issue, replace smc_special_trylock() with spin_trylock_irqsave(). Fixes: 342a932 ("locking/spinlock: Provide RT variant header: <linux/spinlock_rt.h>") Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251217085115.1730036-1-yeoreum.yun@arm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The nvram size is dependent on the iboot version and thus has to be set dynamically by m1n1. Adapt the kernel dts for that and add spi-nor/nvram partition nodes to devices missing them.
Nove this to a dtsi since it is identical on all devices and the size is filled in by m1n1.
m1ni portion on this change is in AsahiLinux/m1n1#336. If this is merged before the m1n1 change devices will loose the nvram mtd partition.