From: Bernd Porr <berndporr@f2s.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: usb coldplug problem
Date: Wed, 03 Dec 2008 08:40:52 +0000 [thread overview]
Message-ID: <49364614.6080706@f2s.com> (raw)
In-Reply-To: <403A9FAC.2010904@free.fr>
> No.
>
> After the firmware is loaded into the device properly, you will then
> call comedi_config from the driver itself to initialize everything.
No. This needs to be done from userspace or in other words from a udev
script. ;) This has loads of practical reasons to have the final
association between the driver and the comedi device in userspace. For
example, in cases of multiple devices communicating with different
drivers. That's something for a udev rule. Sorry. But what you are
suggesting just now seems to me like a workaround for the coldplug
problem: the firmware is loaded via a firmware event (created by the
driver) and I should move comedi_config into my driver because there are
no udev events during coldplug.
> Yes it will as the startup scripts already know how to handle coldplug
> firmware events.
To give the "magic" a name: you mean udev adm trigger? Or a nice script
which writes "add" to all "uvents"? This is exactly what doesn't work.
There are absolutely no udev events generated for comedi during boot.
I've checked that now thoroughly and I think there's something wrong.
What could that be?
/Bernd
Greg KH wrote:
> On Mon, Dec 01, 2008 at 06:27:30PM +0000, Bernd Porr wrote:
>> Ok. I'll look into that. So, you mean that I create with the "request
>> firmware" a new udev event which then could also call "comedi_config"?
>
> No.
>
> After the firmware is loaded into the device properly, you will then
> call comedi_config from the driver itself to initialize everything.
>
>> The problem just now is that I don't get any udev events during
>> coldplug. Do you think this will also solve that issue?
>
>> One practical thing: it's probably a good idea to work on the driver
>> version which goes into the kernel and not the one in the comedi CVS. Where
>> can I check out my module just now?
>
> Grab the linux-next tree, your driver and cleanups, are in there.
>
> thanks,
>
> greg k-h
>
--
www: http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
http://www.myfriendhelen.org.uk/
Mobile: +44 (0)7840 340069
Work: +44 (0)141 330 5237
University of Glasgow
Department of Electronics & Electrical Engineering
72 Oakfield Avenue (Rankine Building for deliveries)
Glasgow, G12 8LT
next prev parent reply other threads:[~2008-12-03 8:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-24 0:49 USB coldplug problem Lionel VICTOR
2008-12-01 8:46 ` usb " Bernd Porr
2008-12-01 14:35 ` Greg KH
2008-12-01 15:21 ` Bernd Porr
2008-12-01 15:29 ` Greg KH
2008-12-01 18:27 ` Bernd Porr
2008-12-03 6:55 ` Greg KH
2008-12-03 8:40 ` Bernd Porr [this message]
2008-12-03 9:18 ` Kay Sievers
2008-12-03 10:28 ` Sujit Karataparambil
2008-12-03 11:13 ` Bernd Porr
2008-12-03 11:46 ` Sujit Karataparambil
2008-12-03 14:59 ` Greg KH
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=49364614.6080706@f2s.com \
--to=berndporr@f2s.com \
--cc=linux-hotplug@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;
as well as URLs for NNTP newsgroup(s).