Re: 2.6.27- Sending uevent from a driver
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-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27- Sending uevent from a driver
> 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-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27- Sending uevent from a driver
Hi Greg, On Wed, Jul 1, 2009 at 1:41 AM, Greg KH 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-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27- Sending uevent from a driver
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-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27- Sending uevent from a driver
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 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
