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
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.