On Fri, 2008-07-11 at 15:16 -0600, Matthew Wilcox wrote: > Here we go with take 4. Changes: > > - Check the requested number of interrupts against the maximum number > the device claims to support. Thanks to Hidetoshi Seto for pointing > out this oversight. > - Implemented Eric's suggestion of using a single IRQ and storing the > data with it. > - As a result, don't try to support the mode in the AHCI driver where > the excess ports all share the last interrupt. It could be done, but > it would be rather messy and I don't have hardware that supports that > mode anyway. > > I'm fairly comfortable with the subchannel notion we're introducing > here. It's more flexible than MSI and doesn't impose a penalty on > architectures which don't implement it. It makes some things more > complex, but it makes other things simpler, so I think it's a wash from > a cleanliness standpoint. I prefer you initial approach. If those are effectively one interrupt, you end up with the whole IRQ_INPROGRESS logic going bonkers trying to prevent them from occuring at the same time and possibly losing some. I think the masking "issue" is mostly a non-issue as I explained in other emails. Cheers, Ben. -- 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
