On Thu, Jun 06, 2013 at 10:30:20AM +0200, Alexander Gordeev wrote: > Sebastian, Hi Alexander, > I re-read my comment few times and I admit it might be confusing. You are > right - 'multiple' is set by rounding up only. The part '...not necessarily > the closest power-of-two value...' implied an abstract PCI device rather than > the described code, but the wording is less than perfect, indeed. Good, so it is not just me :) > In fact, at the moment of writing I kept in mind a follow-up patch that could > help with aforementioned devices. That would be a new interface: > > int pci_enable_msi_block_partial(struct pci_dev *dev, > unsigned int nvec_use, > unsigned int nvec_init); > > In this case 'nvec_use' would go to 'msi_desc::nvec_used' and 'nvec_init' > would translate to 'msi_desc::multiple' in case 'nvec_init' is not zero. > In case 'nvec_init' is zero, 'msi_desc::multiple' would be initialized > with the maximum possible value for the device (the way it is done now for > pci_enable_msi_block_auto() interface). So, for the AHCI device (Bjorn > mentioned) such a call would conserve on 10 of 16 vectors: > > pci_enable_msi_block_partial(pdev, 6, 0); Ah okay. that makes sense. > > What I am not sure is whether we need to read out the maximum possible > number of vectors like pci_enable_msi_block_auto() does: > > int pci_enable_msi_block_partial(struct pci_dev *dev, > unsigned int nvec_use, > unsigned int nvec_init, > unsigned int *maxvec); > > I can not think of any use of 'maxvec' with this interface, but the second > variant completes the whole picture about a device... The user of pci_enable_msi_block_auto() does not know how many it will get so argument seems essential. Your new function on the other hand says exactly how many it requires. Anything less should be an error. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
