Messages in this thread | | | Date | Sun, 15 Oct 2006 16:18:34 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set |
| |
On Sun, 15 Oct 2006 15:45:58 -0700 David Brownell <david-b@pacbell.net> 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |