mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Paul Mackerras <paulus@samba.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	David Brownell <david-b@pacbell.net>,
	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 18:10:44 -0700	[thread overview]
Message-ID: <20061015181044.ec414e4f.akpm@osdl.org> (raw)
In-Reply-To: <17714.54766.390707.532248@cargo.ozlabs.ibm.com>

On Mon, 16 Oct 2006 10:44:30 +1000
Paul Mackerras <paulus@samba.org> wrote:

> Andrew Morton writes:
> 
> > Let me restore the words from my earlier email which you removed so that
> > you could say that:
> > 
> >   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.  
> 
> Maybe aliens are firing a ray-gun at the card.  I think it's
> fundamentally wrong for the driver to deny service completely because
> of a maybe.
> 
> Either there was a transient error that only affected the attempt to
> set MWI, in which case a printk (inside pci_set_mwi!) is appropriate,
> and we carry on.  Or there is a persistent error condition, in which
> case the driver will see something else fail soon enough - something
> that the driver actually needs to have working in order to operate -
> and fail at that point.
> 
> For the driver to stop and refuse to go any further because of an
> error in pci_set_mwi has far more disadvantages than advantages.
> 

Sure.

So I think what we're needing in this case is:

- A modified version of Willy's patch which returns 0 if MWI was enabled,
  1 if MWI isn't available.

- A printk if something went bad

  It appears that the various functions which try to match the line sizes
  already have printks if something went wrong, but they're using
  KERN_DEBUG facility level and that warning would dupliate the new one in
  pci_set_mwi().

  And although the various implementations of pci_read_config_foo() and
  pci_write_config_foo() can return error codes, we have so many instances
  where we're not checking it, I don't think it's practical to try to start
  doing that everywhere.

- drop the __must_check.

Question is, should pci_set_mwi() ever return -EFOO?  I guess it should, in
the case where setting the line size didn't work out.

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

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-06 19:05 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 [this message]
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
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=20061015181044.ec414e4f.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=david-b@pacbell.net \
    --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=paulus@samba.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

Powered by JetHome