On 12/24/25 04:10, Vivian Wang wrote: > The Sophgo SG2042 is a cursed machine in more ways than one. > > The one way relevant to this patch series is that its PCIe controller > has neither INTx nor a low-address MSI doorbell wired up. Instead, the > only usable MSI doorbell is a SoC one at 0x7030010300, which is above > 32-bit space.
Oh! That sounds like a really big show stopper for a lot of PCIe devices. Pretty much all 32bit devices are impossible to work with that. If I'm not completely mistaken that even makes the platform non-PCIe spec complaint. > Currently, the no_64bit_msi flag on a PCI device declares that a device > needs a 32-bit MSI address. Since no more precise indication is > possible, devices supporting less than 64 bits of MSI addresses are all > lumped into one "need 32-bit MSI address" bucket. This of course > prevents these devices from working with MSI enabled on SG2042 because a > 32-bit MSI doorbell address is not possible. Combined with a lack of > INTx, some of them have trouble working on SG2042 at all. > > There were previous dirtier attempts to allow overriding no_64bit_msi > for radeon [1] and hda/intel [2]. > > To fix this, generalize the single bit no_64bit_msi into a full address > mask msi_addr_mask to more precisely describe the restriction. The > existing DMA masks seems insufficient, as for e.g. radeon the > msi_addr_mask and coherent_dma_mask seems to be different on more recent > devices. > > The patches are structured as follows: > > - Patch 1 conservatively introduces msi_addr_mask, without introducing > any functional changes (hopefully, if I've done everything right), by > only using DMA_BIT_MASK(32) and DMA_BIT_MASK(64). > - The rest of the series actually make use of intermediate values of > msi_addr_mask, and should be independently appliable. Patch 2 relaxes > msi_verify_entries() to allow intermediate values of msi_addr_mask. > Patch 3 onwards raises msi_addr_mask in individual device drivers. > > Tested on SG2042 with a Radeon R5 220 which makes use of radeon and > hda/intel. PPC changes and pensanto/ionic changes are compile-tested > only, since I do not have the hardware. > > I would appreciate if driver maintainers can take a look and see whether > the masks I've set makes sense, although I believe they shouldn't cause > problems on existing platforms. I'm also not familiar with PPC enough to > touch the arch/powerpc firmware calls further - help would be > appreciated. Over all the approach looks sane to me, but the radeon patch needs some changes. Going to comment on the patch itself. Regards, Christian. > > My intention is that the first two patches are taken up by PCI > maintainers, and the rest go through the maintainers of individual > drivers since they could use more device-specific testing and review. If > this is not convenient I'll be happy to split it up or something. > > [1]: https://lore.kernel.org/all/[email protected]/ > [2]: https://lore.kernel.org/all/[email protected]/ > > --- > Vivian Wang (5): > PCI/MSI: Conservatively generalize no_64bit_msi into msi_addr_mask > PCI/MSI: Check msi_addr_mask in msi_verify_entries() > drm/radeon: Raise msi_addr_mask to 40 bits for pre-Bonaire > ALSA: hda/intel: Raise msi_addr_mask to dma_bits > [RFC net-next] net: ionic: Set msi_addr_mask to IONIC_ADDR_LEN-bit > everywhere > > arch/powerpc/platforms/powernv/pci-ioda.c | 2 +- > arch/powerpc/platforms/pseries/msi.c | 4 ++-- > drivers/gpu/drm/radeon/radeon_irq_kms.c | 4 ++-- > drivers/net/ethernet/pensando/ionic/ionic_bus_pci.c | 4 +--- > drivers/pci/msi/msi.c | 11 +++++++---- > drivers/pci/msi/pcidev_msi.c | 2 +- > drivers/pci/probe.c | 7 +++++++ > include/linux/pci.h | 8 +++++++- > sound/hda/controllers/intel.c | 10 +++++----- > 9 files changed, 33 insertions(+), 19 deletions(-) > --- > base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 > change-id: 20251223-pci-msi-addr-mask-2d765a7eb390 > > Best regards,
