From: Gerd Knorr <kraxel@suse.de>
To: Johannes Stezenbach <js@linuxtv.org>, Gerd Knorr <kraxel@suse.de>,
Rusty Russell <rusty@rustcorp.com.au>,
Takashi Iwai <tiwai@suse.de>,
"Alexander E. Patrakov" <patrakov@ums.usu.ru>,
linux-kernel@vger.kernel.org
Subject: Re: modprobe + request_module() deadlock
Date: Mon, 22 Nov 2004 15:44:33 +0100 [thread overview]
Message-ID: <20041122144432.GB575@bytesex> (raw)
In-Reply-To: <20041122141607.GA21184@linuxtv.org>
> > They can't actually probe themself. It's _one_ PCI device (driven by
> > the saa7134 module) which can handle (among other v4l-related things)
> > the DMA transfer of mpeg streams. That can be used in different ways
> > (or not at all) and the different use cases are handled by the
> > sub-modules.
> >
> > So the way it is intended to work is that saa7134 has the pci table and
> > gets autoloaded by hotplug, it will have a look at the hardware and then
> > load either saa7134-empress or saa7134-dvb or none of them, so you'll
> > get everything nicely autoloaded.
>
> The saa7146 driver seems to have a working solution for this
> problem: The PCI ids are registered to the subdrivers (e.g. dvb-ttpci
> or mxb) so that these are loaded via hotplug. They then register to the
> saa7146 core as an "extension" module, and the core then does the probing.
> Grep for saa7146_register_extension().
That would be kida ugly because I'd need a dummy module then for the
cards which need neither saa7134-empress nor saa7134-dvb (which is true
for most of the existing cards btw).
I can fix that in the driver, by delaying the request_module() somehow
until the saa7134 module initialization is finished. I don't think that
this is a good idea through as it looks like I'm not the only one with
that problem ...
Gerd
next prev parent reply other threads:[~2004-11-22 15:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-17 22:29 modprobe + request_module() deadlock Johannes Stezenbach
2004-11-18 3:48 ` Rusty Russell
2004-11-18 13:55 ` Johannes Stezenbach
2004-11-18 19:05 ` Takashi Iwai
2004-11-19 4:04 ` Alexander E. Patrakov
2004-11-19 11:10 ` Takashi Iwai
2004-11-19 11:50 ` Gerd Knorr
2004-11-19 12:42 ` Alexander E. Patrakov
2004-11-21 8:39 ` Rusty Russell
2004-11-22 10:25 ` Gerd Knorr
2004-11-22 14:16 ` Johannes Stezenbach
2004-11-22 14:44 ` Gerd Knorr [this message]
2004-11-22 15:36 ` Johannes Stezenbach
2004-11-22 16:52 ` Gerd Knorr
2004-11-24 5:02 ` Rusty Russell
2004-11-24 12:11 ` Gerd Knorr
2004-11-25 16:03 ` Gerd Knorr
2004-11-26 0:34 ` Rusty Russell
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=20041122144432.GB575@bytesex \
--to=kraxel@suse.de \
--cc=js@linuxtv.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patrakov@ums.usu.ru \
--cc=rusty@rustcorp.com.au \
--cc=tiwai@suse.de \
/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.