public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Andrew Morton <akpm@osdl.org>
Cc: alan@lxorguk.ukuu.org.uk, matthew@wil.cx,
	val_henson@linux.intel.com, netdev@vger.kernel.org,
	linux-pci@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org,
	gregkh@suse.de
Subject: Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set
Date: Sun, 15 Oct 2006 17:16:35 -0700	[thread overview]
Message-ID: <200610151716.36337.david-b@pacbell.net> (raw)
In-Reply-To: <20061015161834.f96a0761.akpm@osdl.org>


> > 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.

But what is an "unexpected" "error"?  Not every fault that's unexpected
is an error; consider a page fault.

Consider also kfree(NULL).  The same motivation for drivers not needing
to validate that parameter is behind arguing that device drivers should
not need to poke around in PCI config space to verify that the device
supports MWI; and should have the flexibility to ignore the return code,
just like kfree() returns no value.


> 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. 

I know that it enables MWI accesses ... or fails.  Beyond that, there
should be no reason to care.  If the hardware can use a lower-overhead
type of PCI bus cycle, I want it to do so.  If not, no sweat.


> This is not a terribly important issue, and it is far from the worst case
> of missed error-checking which we have in there. 

The reason I think it's important enough to continue this discussion is
that as it currently stands, it's a good example of a **BAD** interface
design ... since it's pointlessly marked as must_check.  (See appended
patch to fix that issue.)

If you wouldn't want all callers of kfree() to say "if (ptr) kfree(ptr);";
why then would anyone want to demand

	... read the pci config space byte (and cleanly handle errors) ...
	... check for the MWI bit ...
	... if it's set (so we "expect" this next call to succeed) then:
		... call pci_set_mwi() ...
		... test set_mwi() value ...
		... ignore that value ...

where the first three lines duplicate code _inside_ pci_set_mwi(), and the
last two lines are obviously a pure waste of code and effort.  I'd want to
know the criteria by which "if(ptr)" is judged a waste of effort in all
callers, but that more extensive PCI configspace logic was not...

- Dave

-------------------- CUT HERE

Remove bogus annotation of pci_set_mwi() as __must_check.  It's completely
reasonable for drivers to not care about the return code, when all they're
doing is enabling an optional performance-improving mechanism that's often
not even available.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -499,7 +499,7 @@ int __must_check pci_enable_device_bars(
 void pci_disable_device(struct pci_dev *dev);
 void pci_set_master(struct pci_dev *dev);
 #define HAVE_PCI_SET_MWI
-int __must_check pci_set_mwi(struct pci_dev *dev);
+int pci_set_mwi(struct pci_dev *dev);
 void pci_clear_mwi(struct pci_dev *dev);
 void pci_intx(struct pci_dev *dev, int enable);
 int pci_set_dma_mask(struct pci_dev *dev, u64 mask);


  parent reply	other threads:[~2006-10-16  0:16 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-06 19:05 [PATCH 1/2] [PCI] Check that MWI bit really did get set Matthew Wilcox
2006-10-06 19:05 ` [PATCH 2/2] [TULIP] Check the return value from pci_set_mwi() Matthew Wilcox
2006-10-06 19:15   ` Jeff Garzik
2006-10-06 19:28     ` Matthew Wilcox
2006-10-06 19:59       ` Jeff Garzik
2006-10-07  5:34         ` Grant Grundler
2006-10-07 14:44           ` Jeff Garzik
2006-10-06 19:16 ` [PATCH 1/2] [PCI] Check that MWI bit really did get set Jeff Garzik
2006-10-14  4:41 ` Andrew Morton
2006-10-14  5:21   ` Greg KH
2006-10-14 14:02   ` Matthew Wilcox
2006-10-14 20:48     ` Andrew Morton
2006-10-15  3:20       ` Matthew Wilcox
2006-10-15  6:53         ` Andrew Morton
2006-10-15 13:54           ` Matthew Wilcox
2006-10-15 17:47             ` Andrew Morton
2006-10-15  7:08         ` [Bulk] " David Brownell
2006-10-15 13:52           ` Matthew Wilcox
2006-10-15 14:21           ` Alan Cox
2006-10-15 13:57             ` Matthew Wilcox
2006-10-15 17:45               ` Andrew Morton
2006-10-15 19:16                 ` David Brownell
2006-10-15 19:34                   ` Andrew Morton
2006-10-15 22:45                     ` David Brownell
2006-10-15 23:18                       ` Andrew Morton
2006-10-16  0:02                         ` Alan Cox
2006-10-15 23:44                           ` Andrew Morton
2006-10-16  0:44                             ` Paul Mackerras
2006-10-16  1:10                               ` Andrew Morton
2006-10-16  2:07                                 ` David Brownell
2006-10-16 10:58                                 ` Alan Cox
2006-10-16 11:02                             ` Alan Cox
2006-10-16  0:16                         ` David Brownell [this message]
2006-10-16  0:31                           ` Andrew Morton
2006-10-16 10:59                           ` Alan Cox
2006-10-15 21:52                 ` [Bulk] " Alan Cox
2006-10-16  0:00                 ` Paul Mackerras
2006-10-16  0:15                   ` Andrew Morton
2006-10-16  0:21                   ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200610151716.36337.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=matthew@wil.cx \
    --cc=netdev@vger.kernel.org \
    --cc=val_henson@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox