From: Pierre Ossman <drzeus-list@drzeus.cx>
To: Greg KH <gregkh@suse.de>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: pci: add to global list before sysfs?
Date: Sat, 5 Apr 2008 18:55:01 +0200 [thread overview]
Message-ID: <20080405185501.41ec42a7@mjolnir.drzeus.cx> (raw)
In-Reply-To: <20080405155323.GA27252@suse.de>
On Sat, 5 Apr 2008 08:53:23 -0700
Greg KH <gregkh@suse.de> wrote:
> On Sat, Apr 05, 2008 at 11:57:27AM +0200, Pierre Ossman wrote:
> >
> > Yes. Things work fine when the driver is loaded after the entire PCI
> > bus has been scanned, but not when new cards are hotplugged with the
> > driver already present. I'd like the behaviour to be the same in both
> > cases.
>
> Why not just create a thread in your driver, or timer, and sleep until
> you see the other devices? If after a certian time you never do, then
> bail out.
>
> That should work properly for you for both cases (startup and loading
> later.)
>
I'm not sure how that could be done in a clean way. Right now I have
the following:
sd_dev = NULL;
while ((sd_dev = pci_get_device(PCI_VENDOR_ID_JMICRON,
PCI_DEVICE_ID_JMICRON_JMB38X_SD, sd_dev)) != NULL) {
if ((PCI_SLOT(chip->pdev->devfn) ==
PCI_SLOT(sd_dev->devfn)) &&
(chip->pdev->bus == sd_dev->bus))
break;
}
if (sd_dev) {
pci_dev_put(sd_dev);
dev_info(&chip->pdev->dev, "Refusing to bind to "
"secondary interface.\n");
return -ENODEV;
}
If I do this threaded, I'd have to return success to the driver core
and then act like a possum later. Doable, but not very clean. It could
be solved if it was possible to sleep in probe functions, but from what
I can tell that will stop the probing of subsequent devices.
Also, the timeout would introduce an inherent race. Which means either
putting a high timeout to make the race insignificant, or a low timeout
so users don't have to wait for their device to actually become usable.
Is it possible to write some routines that can walk the PCI device tree
without having any pci_dev structures to hang on to? To solve my basic
problem I just need to know how the tree looks like, not actually poke
any of the other devices.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
next prev parent reply other threads:[~2008-04-05 16:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-04 17:13 Pierre Ossman
2008-04-04 21:01 ` Greg KH
2008-04-05 9:57 ` Pierre Ossman
2008-04-05 15:53 ` Greg KH
2008-04-05 16:55 ` Pierre Ossman [this message]
2008-04-05 17:12 ` Greg KH
2008-04-05 18:27 ` Pierre Ossman
2008-04-08 3:41 ` Greg KH
2008-04-13 12:33 ` Pierre Ossman
2008-04-13 17:51 ` Greg KH
2008-04-13 21:37 ` Benjamin Herrenschmidt
2008-04-14 8:35 ` Pierre Ossman
2008-04-14 8:57 ` Benjamin Herrenschmidt
2008-04-14 8:58 ` Benjamin Herrenschmidt
2008-04-14 10:58 ` Pierre Ossman
2008-04-13 21:35 ` Benjamin Herrenschmidt
2008-04-15 19:13 ` Greg KH
2008-04-15 21:53 ` Benjamin Herrenschmidt
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=20080405185501.41ec42a7@mjolnir.drzeus.cx \
--to=drzeus-list@drzeus.cx \
--cc=gregkh@suse.de \
--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
all inboxes | Powered by JetHome®