> From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Sent: Thursday, November 24, 2022 4:36 PM > > On Thu, Nov 24 2022 at 01:07, Kevin Tian wrote: > >> From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > I looked at it from the outmost invocation: > > > > @@ -436,6 +436,9 @@ int __pci_enable_msi_range(struct pci_de > > if (rc) > > return rc; > > > > + if (!pci_setup_msi_device_domain(dev)) > > + return -ENODEV; > > + > > > > the current style kind of converts meaningful -EINVAL/-ENOMEM/etc. > > into -ENODEV. > > But go to the call sites of the various places in drivers which set up > MSI or MSI-X and check whether anything evaluates those error codes in a > meaningful way. > > Some of them print the error code, but that does not help much because > the error code does not allow you to pin point the place which returns > that. If you just analyze the pci_alloc_irq_vectors_affinity() call then > you find at least 10 places, which can return -ENOMEM. So how is that > meaningful and helpful? > > All it tells you is that some memory allocation failed. In that case the > failure of the PCI/MSI[-X] setup is the least of the problems. > > Where error codes are mandatory are user space interfaces, but in the > kernel a simple fail/success like we have with many interfaces which > just return a NULL pointer on fail is sufficient. > > Just because the kernel historically propagated error codes all over the > place does not make them useful or meaningful. > Good learning. Thanks.
