On Mon, Jun 12, 2017 at 4:34 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Jun 12, 2017 at 04:00:56PM +0300, Tal Shorer wrote: >> On Mon, Jun 12, 2017 at 2:42 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> > On Mon, Jun 12, 2017 at 01:17:18PM +0300, Tal Shorer wrote: >> >> On Mon, Jun 12, 2017 at 9:48 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> >> > On Sun, Jun 11, 2017 at 11:41:02PM +0300, Tal Shorer wrote: >> >> >> I'm currently working on a project where I'd like to have an omap board >> >> >> running linux be a usb-to-uart converter (using f_acm). I have an >> >> >> application that holds both the ttyGS* and the ttyO* port (the physical >> >> >> uart port) open, polls for readable data, and writes any incoming data >> >> >> to the other side. >> >> >> >> >> >> I'd also like the host to be able to configure baudrate, parity, etc. >> >> >> My thought on how to achieve this is to modify how the ttyGS* ports >> >> >> behave by adding a POLLPRI event when set_line_coding is received. In >> >> >> order to do that several steps will have to be taken: >> >> >> - one of: >> >> >> 1. add a poll() callback to struct tty_operations and call it in >> >> >> n_tty_poll(). u_serial and f_acm will implement required >> >> >> callbacks to allow returning POLLPRI when necessary. >> >> >> 2. add a flag to struct tty_struct that indicates an exceptional >> >> >> condition and make n_tty_poll() return POLLPRI if that flag is >> >> >> set. this will also require a new wait queue to allow us to wait >> >> >> for such an event. >> >> >> - after receiving SET_LINE_CODING (and verifying it), set whatever flag >> >> >> is necessary to wake the user with POLLPRI. >> >> >> - implement the ioctl() callback in u_serial and f_acm to allow the >> >> >> user to get the line coding set by the host, with which it can >> >> >> configure the hardware port accordingly. >> >> >> >> >> >> Does my approach make sense? Assuming I do that, which tree should such >> >> >> a series be sent to? usb-gadget? tty? >> >> > >> >> > Why not just do it all in userspace, a simple "loopback" program should >> >> > be able to handle this. If not, look into the 'serdev' interface now in >> >> > the kernel, that might help out a lot with what you want to do here. >> >> > >> >> > And I really doubt you need to touch the tty core or ldisc for this, >> >> > that seems a bit extreme. >> >> > >> >> > good luck! >> >> > >> >> > greg k-h >> >> >> >> I'm not sure what you mean by "loopback", but if you mean an >> >> application that poll()s the two sides, reads from one side and writes >> >> to the other, I'm already doing that. My issue is that: >> >> 1. f_acm doesn't do anything with set_line_coding. >> >> 2. even if it did, the tty core has no easy way to notify the user of that. >> > >> > Ah, I understand now, thanks. Yeah, that's a problem :) >> > >> > Good luck! >> > >> > greg k-h >> Which of the two approaches do you think is cleaner? I tend to favour >> the first. Should this be split into two series, one for tty core and >> one for the gadget stuff or should this be one long series? If one >> series, which tree should I submit this to? > > One long series is fine, post to both lists and let's see how it works > out... > > greg k-h Alright, so I'm about to add a new ioctl for ttyGS* devices when used with acm, which means I should it to a uapi header file somewhere. include/uapi/linux/usb/cdc.h makes the most sense from the existing ones, but it's currently only definitions and I see the value in keeping it that way. Should I create a new uapi file, maybe called include/uapi/linux/usb/f_acm.h or use the existing one? -- 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
