2.6.27- Sending uevent from a driver

2.6.27- Sending uevent from a driver

[Daniel Ng]

Hi,

I'm trying to send a uevent from my USB Gadget Serial driver using:

kobject_uevent(&cdev->gadget->dev.kobj, KOBJ_ONLINE);

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?

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.27- Sending uevent from a driver

[Alan Stern]

On Tue, 30 Jun 2009, 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);
> 
> 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?

Why do you want to use uevents?  How about using a sysfs attribute file 
instead?  It would be a lot easier.

> 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.

You can set the bus type to whatever you want, but various buses have
expectations about the structures registered under them.  For example,
anything registered on the platform bus has to be embedded in a struct
platform_device, and anything registered on the PCI bus has to be
embedded in a struct pci_dev.  I don't know what the OF platform bus
expects, but you can probably figure it out.

And instead of setting dev.bus directly, you have to call the 
appropriate registration function.

Alan Stern

Re: 2.6.27- Sending uevent from a driver

[Greg KH]

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

Re: 2.6.27- Sending uevent from a driver

[Daniel Ng]

Hi Greg,

On Wed, Jul 1, 2009 at 1:41 AM, Greg KH<greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> 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.

Does this mean the userspace program would have to continually poll
for the TTY line status?

Instead, I'd like the userspace program to listen (select) on a socket
and receive some sort of notification when the TTY is ready for I/O.

Or, maybe the userspace program can receive some sort of interrupt
from the TTY device when it is ready for I/O.

Perhaps there is another way to avoid continued polling?

Cheers,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.27- Sending uevent from a driver

[Alan Cox]

> Or, maybe the userspace program can receive some sort of interrupt
> from the TTY device when it is ready for I/O.
> 
> Perhaps there is another way to avoid continued polling?

TIOCMIWAIT ioctl for modem signals, and just using poll/select() on the
tty for I/O.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.27- Sending uevent from a driver

[Jamie Lokier]

Alan Cox wrote:
> > Or, maybe the userspace program can receive some sort of interrupt
> > from the TTY device when it is ready for I/O.
> > 
> > Perhaps there is another way to avoid continued polling?
> 
> TIOCMIWAIT ioctl for modem signals, and just using poll/select() on the
> tty for I/O.

Ah yes, the undocumented ioctl...  I knew there was one, just couldn't
find it in the man page just now.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html