Hello, On Tue, Oct 01, 2013 at 05:35:48PM +1000, Michael Ellerman wrote: > > > Roughly third of the drivers just do not care and bail out once > > > pci_enable_msix() has not succeeded. Not sure how many of these are > > > mandated by the hardware. > > > > Yeah, I mean, this type of interface is a trap. People have to > > actively resist to avoid doing silly stuff which is a lot to ask. > > I really think you're overstating the complexity here. > > Functions typically return a boolean -> nothing to see here > This function returns a tristate value -> brain explosion! It is an interface which forces the driver writers to write complicated fallback code which won't usually be excercised. The same goes for the hardware. In isolation, it doesn't look like much but things like this are bound to lead to subtle bugs which are diffiuclt to trigger. > > * Determine the number of MSIs the controller wants. Don't worry > > about quotas or limits or anything. Just determine the number > > necessary to enable enhanced interrupt handling. > > > > * Try allocating that number of MSIs. If it fails, then just revert > > to single interrupt mode. It's not the end of the world and mostly > > guaranteed to work. Let's please not even try to do partial > > multiple interrupts. I really don't think it's worth the risk or > > complexity. > > It will potentially break existing setups on our hardware. I think it'd be much better to have a separate interface for the drivers which actually require it *in practice* rather than forcing everyone to go "oh this interface supports that, I don't know if I need it but let's implement fallback logic which I won't and have no means of testing". Are we talking about some limited number of device drivers here? Also, is the quota still necessary for machines in production today? Thanks. -- tejun -- 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
