[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb
Subject:    Re: 2.6.27- Sending uevent from a driver
From:       Greg KH <greg () kroah ! com>
Date:       2009-06-30 15:41:10
Message-ID: 20090630154110.GD16038 () kroah ! com
[Download RAW message or body]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]