All of lore.kernel.org
 help / color / mirror / Atom feed
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




  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.