On Tue, Jun 30, 2009 at 06:30:43PM +1000, Daniel Ng wrote: > Hi, > > I'm trying to send a uevent from my USB Gadget Serial driver using: > > kobject_uevent(&cdev->gadget->dev.kobj, KOBJ_ONLINE); Is your device one of the ones that "ONLINE" messages are expected to emit? If not, it's not going to matter much, right? :) > However, the uevent gets filtered out with the error message: > > "filter function caused the event to drop!" > > -from kobject_uevent.c line 124 > > The filter function used is dev_uevent_filter() from core.c. > > The dev_uevent_filter() filters out the uevent because the following test fails: > > if (ktype == &device_ktype) > > This is because my driver's (struct bus_type *) gadget.dev.bus is NULL. > > So I tried the following in my driver's probe() function: > > the_controller->gadget.dev.bus = &of_platform_bus_type; > > But this results in a crash. > > Here are my questions: > > 1) I am trying to communicate to a Userspace prgoram that the Gadget > Serial driver has connected to a TTY device, so the Userspace program > can know when to start I/O with the TTY device. > To achieve this, I want to send a uevent from for example f_acm.c, > just after it calls gserial_connect() in acm_set_alt(). I'm hoping > that I can use libudev (via netlink sockets) to catch this uevent, and > hence send a notification to a socket that the Userspace program is > listening on. Does this all look like a sensible thing to do? Shouldn't the userspace just be monitoring the tty line settings (like CTS) to know when to start sending data? I wouldn't recommend adding a new interface to a very old, and standardized, interface. > 2) Is there a 'proper' way to assign the bus type as above? Perhaps I > need to call some sort of init function instead, so that the crash can > be avoided. There is a way, but assigning it directly like you did above, is not the correct one. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
