fix SG2042 using AMD R5 220/230 graphics cards #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
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>
…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) forces 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 to enabling MSI on those combinations of devices and platforms, 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. Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20260123-pci-msi-addr-mask-v3-1-9f9baa048524@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/20260123-pci-msi-addr-mask-v3-2-9f9baa048524@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/20260123-pci-msi-addr-mask-v3-3-9f9baa048524@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. Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20260123-pci-msi-addr-mask-v3-4-9f9baa048524@iscas.ac.cn Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
RevySR
force-pushed
the
aosc/rv/v6.18.y
branch
from
13b4028 to
a88d5d2
Compare
RevySR
changed the title
|
All picked to aosc/v6.18.7. Thanks. |
MingcongBai
added a commit
to AOSC-Dev/aosc-os-abbs
that referenced
this pull request
Jan 24, 2026
- Refresh 3B6000/3C6000 PCIe speed quirk to v7. [^1] - Backport a patch to fix core/socket display on Loongson 3B6000. [^2] - Backport a patch to attempt to fix boot on Loongson 2K2000 with older (pre-202411) firmware versions. [^3] - Backport PCIe and drivers fixes for SG2042/2044. [^4] - Track patches at AOSC-Tracking/linux @ aosc/v6.18.7 (HEAD: 7e5c80f189fc964f6c3dfb8881ee5eda1f3d581e). [^1]: https://lore.kernel.org/loongarch/20260121-loongson-pci1-v7-1-fc79c85a574d@uniontech.com/ [^2]: https://lore.kernel.org/loongarch/e18efdbb.AXMAAIuqLC8AAAAAAAAAA-ma1qEAAYKJPtkAAAAAADNVAQBpc5ot@mailjet.com/ [^3]: https://lore.kernel.org/linux-acpi/20240814-check_pci_probe_res-v3-1-b6eaa6f99032@gmail.com/ [^4]: AOSC-Tracking/linux#18
7 tasks
MingcongBai
added a commit
to AOSC-Dev/aosc-os-abbs
that referenced
this pull request
Jan 24, 2026
- Refresh 3B6000/3C6000 PCIe speed quirk to v7. [^1] - Backport a patch to fix core/socket display on Loongson 3B6000. [^2] - Backport a patch to attempt to fix boot on Loongson 2K2000 with older (pre-202411) firmware versions. [^3] - Backport PCIe and drivers fixes for SG2042/2044. [^4] - Refresh kernel configuration where needed. - Track patches at AOSC-Tracking/linux @ aosc/v6.18.7 (HEAD: 7e5c80f189fc964f6c3dfb8881ee5eda1f3d581e). [^1]: https://lore.kernel.org/loongarch/20260121-loongson-pci1-v7-1-fc79c85a574d@uniontech.com/ [^2]: https://lore.kernel.org/loongarch/e18efdbb.AXMAAIuqLC8AAAAAAAAAA-ma1qEAAYKJPtkAAAAAADNVAQBpc5ot@mailjet.com/ [^3]: https://lore.kernel.org/linux-acpi/20240814-check_pci_probe_res-v3-1-b6eaa6f99032@gmail.com/ [^4]: AOSC-Tracking/linux#18
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.