Bug 157072 - binding driver to a device does not create an udev event
Summary: binding driver to a device does not create an udev event
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Beta 7
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Greg Kroah-Hartman
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-10 14:54 UTC by Joachim Gleissner
Modified: 2006-03-15 23:11 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joachim Gleissner 2006-03-10 14:54:09 UTC
Binding a driver to a device (e.g. via 'hwup') does not create an udev event. This is a bit annoying as this (missing) event would be ideal to start ipw3945d (and maybe do other useful thins). ipw3945d is an userspace daemon needed to run an ipw3945 device. The driver registers the interface after the daemon was started, so I can not use a net-event to start it. Currently I am using a driver-event, which is not optimal, as it does only work when the module is loaded, but not when the driver get re-bound to the device or when compiled into the kernel.
Comment 1 Greg Kroah-Hartman 2006-03-10 16:56:26 UTC
What does 'hwup' do to "bind" the device to the driver?

And no, creating a uevent for this would be crazy, what would userspace do with
this kind of information?
Comment 2 Christian Zoz 2006-03-10 17:14:02 UTC
hwup does:
echo -n $HWD_BUSID > $SYSFS_DRIVER_PATH/bind

This works, but prints an error message about "no such device".

IMHO the module and driver events are at least as crazy as an (un)bound event. This bound-event can be used to start a userspace daemon for a device. ipw3945 devices need this, because the daemon registers the network interface.
Comment 3 Greg Kroah-Hartman 2006-03-10 17:21:52 UTC
if you get an error, that means it didn't work :)

And, since you know you bound the device to the driver (which you should really
never have to do by hand, why are you doing this?), you can call whatever program
you want to after this if you want, why would you want the kernel to do something
instead?

As the ipw3945 driver is not in the kernel tree yet, let's take this to lkml in 
public for others to discuss please.

closing this.
Comment 4 Christian Zoz 2006-03-10 17:38:19 UTC
Greg, i get this error message, but nevertheless it works:

d147:~ # ls /sys/bus/pci/drivers/ipw2200/
0000:04:02.0  bind  debug_level  module  new_id  unbind
d147:~ # ls /sys/class/net/
eth0  eth1  lo  sit0
d147:~ # echo -n 0000:04:02.0 > /sys/bus/pci/drivers/ipw2200/unbind
d147:~ # ls /sys/bus/pci/drivers/ipw2200/
bind  debug_level  module  new_id  unbind
d147:~ # ls /sys/class/net/
eth0  lo  sit0
d147:~ # echo -n 0000:04:02.0 > /sys/bus/pci/drivers/ipw2200/bind
bash: echo: write error: No such device
d147:~ # ls /sys/bus/pci/drivers/ipw2200/
0000:04:02.0  bind  debug_level  module  new_id  unbind
d147:~ # ls /sys/class/net/
eth0  eth1  lo  sit0
d147:~ #

Please care about the error message:

About bind-events:
You have to bind the device after you released it. hwdown and hwup do that. These are used from YaST. If you change the driver module via YaST it calls hwdown which should release the device without unloading the module (because of other devices; we had bug reports because we unloaded modules in SLES9SP2).

hwup does only bind devices manually if not already bound automatically.

We wnated to make you aware about the need for bind-events. Of course we could add that also to hwup. But using udev via bind-events would be a better approach.
Comment 5 Greg Kroah-Hartman 2006-03-15 23:11:46 UTC
Yes, others have reported the same error from the bind sysfs file, sorry
about that, am looking into it.

As for the events, the kernel doesn't emit any events when things are "bound"
today, so that would have to be a totally new event.  Please propose a new
feature for that (preferably with patch...)  And again, it's a bit too late
in the SLES10 process for new events to be added...