On Sun, 15 Oct 2006 15:45:58 -0700 David Brownell <[EMAIL PROTECTED]> wrote:
> > In that case its interface is misdesigned, because it doesn't discriminate > > between "yes-it-does/no-it-doesn't" (which we don't want to report, because > > either is expected and legitimate) and "something screwed up", which we do > > want to report, because it is always unexpected. > > You mis-understand. It's completely legit for the driver not to care. > > I agree that set_mwo() should set MWI if possible, and fail cleanly > if it couldn't (for whatever reason). Thing is, choosing to treat > that as an error must be the _driver's_ choice ... it'd be wrong to force > that policy into the _interface_ by forcing must_check etc. No. If pci_set_mwi() detects an unexpected error then the driver should take some action: report it, recover from it, fail to load, etc. If the driver fails to do any of this then it's a buggy driver. You, the driver author _do not know_ what pci_set_mwi() does at present, on all platforms, nor do you know what it does in the future. For you the driver author to make assumptions about what's happening inside pci_set_mwi() is a layering violation. Maybe the bridge got hot-unplugged. Maybe the attempt to set MWI caused some synchronous PCI error. For example, take a look at the various implementations of pci_ops.read() around the place - various of them can fail for various reasons. Now it could be that an appropriate solution is to make pci_set_mwi() return only 0 or 1, and to generate a warning from within pci_set_mwi() if some unexpected error happens. In which case it is legitimate for callers to not check for errors. This is not a terribly important issue, and it is far from the worst case of missed error-checking which we have in there. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
