Messages in this thread | | | From | Jesse Barnes <> | Subject | Re: [PATCH] pci: change msi-x vector to 32bit | Date | Thu, 21 Aug 2008 16:07:05 -0700 |
| |
On Thursday, August 21, 2008 1:47 pm Eric W. Biederman wrote: > Jesse Barnes <jbarnes@virtuousgeek.org> writes: > > On Friday, August 15, 2008 7:36 pm Yinghai Lu wrote: > >> we are using 28bit pci (bus/dev/fn + 12 bits) as irq number, so the > >> cache for irq number should be 32 bit too. > >> > >> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> > >> Cc: Andrew Vasquez <andrew.vasquez@qlogic.com> > >> > >> --- > >> drivers/scsi/qla2xxx/qla_def.h | 2 +- > >> include/linux/pci.h | 2 +- > >> 2 files changed, 2 insertions(+), 2 deletions(-) > >> > >> Index: linux-2.6/drivers/scsi/qla2xxx/qla_def.h > >> =================================================================== > >> --- linux-2.6.orig/drivers/scsi/qla2xxx/qla_def.h > >> +++ linux-2.6/drivers/scsi/qla2xxx/qla_def.h > >> @@ -2109,7 +2109,7 @@ struct scsi_qla_host; > >> > >> struct qla_msix_entry { > >> int have_irq; > >> - uint16_t msix_vector; > >> + uint32_t msix_vector; > >> uint16_t msix_entry; > >> }; > >> > >> Index: linux-2.6/include/linux/pci.h > >> =================================================================== > >> --- linux-2.6.orig/include/linux/pci.h > >> +++ linux-2.6/include/linux/pci.h > >> @@ -730,7 +730,7 @@ enum pci_dma_burst_strategy { > >> }; > >> > >> struct msix_entry { > >> - u16 vector; /* kernel uses to write allocated vector */ > >> + u32 vector; /* kernel uses to write allocated vector */ > >> u16 entry; /* driver uses to specify entry, OS writes */ > >> }; > > > > I see a lot of smoke about this, but not a clear consensus. It sounds > > like no one objects to making the MSI vector field 32 bits, but there > > were a lot of concerns about IRQ vector naming/numbering in general? And > > I assume this particular patch isn't 2.6.27 material... > > There is no need for this particular patch in 2.6.27. > It is a trivial bug fix so it can go in whenever. > > Mostly this is a discussion about code that should land in the 2.6.28 > timeframe assuming all is well.
Ok, thanks Eric. I'll queue it up for linux-next after the next 2.6.27 pull.
Thanks, -- Jesse Barnes, Intel Open Source Technology Center
| |