On Mon, 16 Oct 2006 10:44:30 +1000
Paul Mackerras <[email protected]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
