From: Jeff Garzik <jgarzik@pobox.com>
To: Christoph Hellwig <hch@infradead.org>,
Dave Jones <davej@codemonkey.org.uk>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: propagating failures down to pci_module_init()
Date: Mon, 20 Jan 2003 11:52:36 -0500 [thread overview]
Message-ID: <20030120165236.GA27972@gtf.org> (raw)
In-Reply-To: <20030120163321.A32585@infradead.org>
On Mon, Jan 20, 2003 at 04:33:21PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 20, 2003 at 03:54:35PM +0000, Dave Jones wrote:
> > I've got a wierd situation with a certain chipset for agpgart.
> > There are a few cases where I want to be able to use the existing
> > pci_driver api to detect the right PCI device, and call
> > the relevant .probe routine. No problem there.
> >
> > The problem is that in these cases, I want to be able to read
> > a certain register in that device, and if a bit is 0, bail out
> > of the .probe function with -ENODEV, and make the loading of
> > the module fail.
> >
> > The problem is that the ENODEV in my .probe routine doesn't
> > propagate back down as far as pci_module_init().
> >
> > Ideas ?
>
> Just use pci_register_driver.
Nope. Look at pci_module_init code. It propagates pci_register_driver
return value.
The _real_ problem is that ->probe return value is not propagated back
to pci_register_driver return value. The reason for this is that you
may call ->probe many times, and nobody has written the code to collate
the error returns.
Since one can only sanely return an error code when there was _one_
device and it failed, you are rather limited in error propagation.
Jeff
next prev parent reply other threads:[~2003-01-20 16:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-20 15:54 propagating failures down to pci_module_init() Dave Jones
2003-01-20 16:33 ` Christoph Hellwig
2003-01-20 16:52 ` Jeff Garzik [this message]
2003-01-20 16:56 ` Dave Jones
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=20030120165236.GA27972@gtf.org \
--to=jgarzik@pobox.com \
--cc=davej@codemonkey.org.uk \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/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