fix SG2042 using AMD R5 220/230 graphics cards & PCI/ASPM: Avoid L0s and L1 on Sophgo 2042/4 PCIe & fix riscv64 kexec #18
Conversation
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
RevySR
changed the title
RevySR
force-pushed
the
aosc/rv/v6.18.y
branch
from
3682631 to
23ef9b5
Compare
RevySR
changed the title
MingcongBai
force-pushed
the
aosc/v6.18.2
branch
2 times, most recently
from
cbe8777 to
44f4027
Compare
…dr_mask Some PCI devices have PCI_MSI_FLAGS_64BIT in the MSI capability, but implement less than 64 address bits. This breaks on platforms where such a device is assigned an MSI address higher than what's reachable. Currently, we deal with this with a single no_64bit_msi flag, and (notably on powerpc) use 32-bit MSI address for these devices. However, on some platforms the MSI doorbell address is above 32-bit but within device ability. As a first step, conservatively generalize the single-bit flag no_64bit_msi into msi_addr_mask. (The name msi_addr_mask is chosen to avoid confusion with msi_mask.) The translation is essentially: - no_64bit_msi = 1 -> msi_addr_mask = DMA_BIT_MASK(32) - no_64bit_msi = 0 -> msi_addr_mask = DMA_BIT_MASK(64) - if (no_64bit_msi) -> if (msi_addr_mask < DMA_BIT_MASK(64)) Since no values other than DMA_BIT_MASK(32) and DMA_BIT_MASK(64) is used, no functional change is intended. Future patches that make use of intermediate values of msi_addr_mask will follow, allowing devices that cannot use full 64-bit addresses for MSI to work on platforms with MSI doorbell above 32-bit address space. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20251224-pci-msi-addr-mask-v1-1-05a6fcb4b4c0@iscas.ac.cn Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Instead of a 32-bit/64-bit dichotomy, check the MSI address against msi_addr_mask. This allows platforms with MSI doorbell above 32-bit address space to work with devices without full 64-bit MSI address support, as long as the doorbell is within addressable range of MSI of the device. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20251224-pci-msi-addr-mask-v1-2-05a6fcb4b4c0@iscas.ac.cn Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
The code was originally written using no_64bit_msi, which restricts the device to 32-bit MSI addresses. Since msi_addr_mask is introduced, use DMA_BIT_MASK(40) instead of DMA_BIT_MASK(32) here for msi_addr_mask, describing the restriction more precisely and allowing these devices to work on platforms with MSI doorbell address above 32-bit space, as long as it is within the hardware restriction of 40-bit space. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20251224-pci-msi-addr-mask-v1-3-05a6fcb4b4c0@iscas.ac.cn Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
The code was originally written using no_64bit_msi, which restricts the device to 32-bit MSI addresses. Since msi_addr_mask is introduced, use DMA_BIT_MASK(dma_bits) instead of DMA_BIT_MASK(32) here for msi_addr_mask, describing the restriction more precisely and allowing these devices to work on platforms with MSI doorbell address above 32-bit space, as long as it is within the hardware's addressable space. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20251224-pci-msi-addr-mask-v1-4-05a6fcb4b4c0@iscas.ac.cn Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
…Root Ports Since commit f3ac2ff ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") force enable ASPM on all device tree platform, the SG2042 root port breaks as it advertises L0s and L1 capabilities without supporting it. Override the L0s and L1 Support advertised in Link Capabilities by the SG2042 Root Ports ([1f1c:2042]), so we don't try to enable those states. Fixes: 4e27aca ("riscv: sophgo: dts: add PCIe controllers for SG2042") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Tested-by: Han Gao <gaohan@iscas.ac.cn> Link: https://lore.kernel.org/r/20251225100530.1301625-2-inochiama@gmail.com Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
…Root Ports Since commit f3ac2ff ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") force enable ASPM on all device tree platform, the SG2044 root port breaks as it advertises L0s and L1 capabilities without supporting it. Override the L0s and L1 Support advertised in Link Capabilities by the SG2044 Root Ports ([1f1c:2044]), so we don't try to enable those states. Fixes: 3309df4 ("riscv: dts: sophgo: sg2044: add PCIe device support for SG2044") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Tested-by: Han Gao <gaohan@iscas.ac.cn> Link: https://lore.kernel.org/r/20251225100530.1301625-3-inochiama@gmail.com Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
…stripped Since commit 4b47a3a ("kbuild: Restore pattern to avoid stripping .rela.dyn from vmlinux") vmlinux has .rel*.dyn preserved. Therefore, use vmlinux to produce Image, not vmlinux.unstripped. Doing so fixes booting a RELOCATABLE=y Image with kexec. The problem is caused by this chain of events: - Since commit 3e86e4d ("kbuild: keep .modinfo section in vmlinux.unstripped"), vmlinux.unstripped gets a .modinfo section. - The .modinfo section has SHF_ALLOC, so it ends up in Image, at the end of it. - The Image header's image_size field does not expect to include .modinfo and does not account for it, since it should not be in Image. - If .modinfo is large enough, the file size of Image ends up larger than image_size, which eventually leads to it failing sanity_check_segment_list(). Using vmlinux instead of vmlinux.unstripped means that the unexpected .modinfo section is gone from Image, fixing the file size problem. Cc: stable@vger.kernel.org Fixes: 3e86e4d ("kbuild: keep .modinfo section in vmlinux.unstripped") Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20251230-riscv-vmlinux-not-unstripped-v1-1-15f49df880df@iscas.ac.cn Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
RevySR
force-pushed
the
aosc/rv/v6.18.y
branch
from
23ef9b5 to
13b4028
Compare
RevySR
changed the title
Fearyncess
pushed a commit
that referenced
this pull request
Jan 9, 2026
commit 44bf661 upstream. Commit 1d2da79 ("pinctrl: renesas: rzg2l: Avoid configuring ISEL in gpio_irq_{en,dis}able*()") dropped the configuration of ISEL from struct irq_chip::{irq_enable, irq_disable} APIs and moved it to struct gpio_chip::irq::{child_to_parent_hwirq, child_irq_domain_ops::free} APIs to fix spurious IRQs. After commit 1d2da79 ("pinctrl: renesas: rzg2l: Avoid configuring ISEL in gpio_irq_{en,dis}able*()"), ISEL was no longer configured properly on resume. This is because the pinctrl resume code used struct irq_chip::irq_enable (called from rzg2l_gpio_irq_restore()) to reconfigure the wakeup interrupts. Some drivers (e.g. Ethernet) may also reconfigure non-wakeup interrupts on resume through their own code, eventually calling struct irq_chip::irq_enable. Fix this by adding ISEL configuration back into the struct irq_chip::irq_enable API and on resume path for wakeup interrupts. As struct irq_chip::irq_enable needs now to lock to update the ISEL, convert the struct rzg2l_pinctrl::lock to a raw spinlock and replace the locking API calls with the raw variants. Otherwise the lockdep reports invalid wait context when probing the adv7511 module on RZ/G2L: [ BUG: Invalid wait context ] 6.17.0-rc5-next-20250911-00001-gfcfac22533c9 #18 Not tainted ----------------------------- (udev-worker)/165 is trying to lock: ffff00000e3664a8 (&pctrl->lock){....}-{3:3}, at: rzg2l_gpio_irq_enable+0x38/0x78 other info that might help us debug this: context-{5:5} 3 locks held by (udev-worker)/165: #0: ffff00000e890108 (&dev->mutex){....}-{4:4}, at: __driver_attach+0x90/0x1ac #1: ffff000011c07240 (request_class){+.+.}-{4:4}, at: __setup_irq+0xb4/0x6dc #2: ffff000011c070c8 (lock_class){....}-{2:2}, at: __setup_irq+0xdc/0x6dc stack backtrace: CPU: 1 UID: 0 PID: 165 Comm: (udev-worker) Not tainted 6.17.0-rc5-next-20250911-00001-gfcfac22533c9 #18 PREEMPT Hardware name: Renesas SMARC EVK based on r9a07g044l2 (DT) Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x24 __lock_acquire+0xa14/0x20b4 lock_acquire+0x1c8/0x354 _raw_spin_lock_irqsave+0x60/0x88 rzg2l_gpio_irq_enable+0x38/0x78 irq_enable+0x40/0x8c __irq_startup+0x78/0xa4 irq_startup+0x108/0x16c __setup_irq+0x3c0/0x6dc request_threaded_irq+0xec/0x1ac devm_request_threaded_irq+0x80/0x134 adv7511_probe+0x928/0x9a4 [adv7511] i2c_device_probe+0x22c/0x3dc really_probe+0xbc/0x2a0 __driver_probe_device+0x78/0x12c driver_probe_device+0x40/0x164 __driver_attach+0x9c/0x1ac bus_for_each_dev+0x74/0xd0 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x60/0x128 i2c_register_driver+0x48/0xd0 adv7511_init+0x5c/0x1000 [adv7511] do_one_initcall+0x64/0x30c do_init_module+0x58/0x23c load_module+0x1bcc/0x1d40 init_module_from_file+0x88/0xc4 idempotent_init_module+0x188/0x27c __arm64_sys_finit_module+0x68/0xac invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x160 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Having ISEL configuration back into the struct irq_chip::irq_enable API should be safe with respect to spurious IRQs, as in the probe case IRQs are enabled anyway in struct gpio_chip::irq::child_to_parent_hwirq. No spurious IRQs were detected on suspend/resume, boot, ethernet link insert/remove tests (executed on RZ/G3S). Boot, ethernet link insert/remove tests were also executed successfully on RZ/G2L. Fixes: 1d2da79 ("pinctrl: renesas: rzg2l: Avoid configuring ISEL in gpio_irq_{en,dis}able*(") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250912095308.3603704-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
No description provided.