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.
next prev parent 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