On Fri, Dec 04, 2020 at 12:33:45AM +0530, Vidya Sagar wrote: > On 12/3/2020 11:54 PM, Bjorn Helgaas wrote: > > On Tue, Nov 24, 2020 at 04:20:35PM +0530, Vidya Sagar wrote: > > > There are devices (Ex:- Marvell SATA controller) that don't support > > > 64-bit MSIs and the same is advertised through their MSI capability > > > register. Set no_64bit_msi flag explicitly for such devices in the > > > MSI setup code so that the msi_verify_entries() API would catch > > > if the MSI arch code tries to use 64-bit MSI. > > > > This seems good to me. I'll post a possible revision to set > > dev->no_64bit_msi in the device enumeration path instead of in the IRQ > > allocation path, since it's really a property of the device, not of > > the msi_desc. > > > > I like the extra checking this gives us. Was this prompted by > > tripping over something, or is it something you noticed by code > > reading? If the former, a hint about what was wrong and how it's > > being fixed would be useful. > I observed functionality issue with Marvell SATA controller (1b4b:9171) when > the allocated MSI target address was a 64-bit address. I mentioned the > Marvell SATA controller as an example in the commit message. I know you mentioned the Marvell controller, but apparently that device is working perfectly correctly: it does not support 64-bit MSI, and it does not advertise support for 64-bit MSI. So if there's a functionality issue, that means something is wrong in Linux that caused us to assign a 64-bit MSI address to it. *That* issue is what I want to know about. Your patch only warns about the issue; it doesn't fix it. I don't think there's any point in specifically mentioning the Marvell device if it is working correctly, because the same issue should affect *any* device that doesn't support 64-bit MSI. But if there's some arch code that incorrectly assigns a 64-bit address, it would definitely be useful to specify the arch. And hopefully there's a fix for that arch code, too. > > > Signed-off-by: Vidya Sagar <vidyas@xxxxxxxxxx> > > > --- > > > V2: > > > * Addressed Bjorn's comment and changed the error message > > > > > > drivers/pci/msi.c | 11 +++++++---- > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c > > > index d52d118979a6..8de5ba6b4a59 100644 > > > --- a/drivers/pci/msi.c > > > +++ b/drivers/pci/msi.c > > > @@ -581,10 +581,12 @@ msi_setup_entry(struct pci_dev *dev, int nvec, struct irq_affinity *affd) > > > entry->msi_attrib.multi_cap = (control & PCI_MSI_FLAGS_QMASK) >> 1; > > > entry->msi_attrib.multiple = ilog2(__roundup_pow_of_two(nvec)); > > > > > > - if (control & PCI_MSI_FLAGS_64BIT) > > > + if (control & PCI_MSI_FLAGS_64BIT) { > > > entry->mask_pos = dev->msi_cap + PCI_MSI_MASK_64; > > > - else > > > + } else { > > > entry->mask_pos = dev->msi_cap + PCI_MSI_MASK_32; > > > + dev->no_64bit_msi = 1; > > > + } > > > > > > /* Save the initial mask status */ > > > if (entry->msi_attrib.maskbit) > > > @@ -602,8 +604,9 @@ static int msi_verify_entries(struct pci_dev *dev) > > > for_each_pci_msi_entry(entry, dev) { > > > if (!dev->no_64bit_msi || !entry->msg.address_hi) > > > continue; > > > - pci_err(dev, "Device has broken 64-bit MSI but arch" > > > - " tried to assign one above 4G\n"); > > > + pci_err(dev, "Device has either broken 64-bit MSI or " > > > + "only 32-bit MSI support but " > > > + "arch tried to assign one above 4G\n"); > > > return -EIO; > > > } > > > return 0; > > > -- > > > 2.17.1 > > >