On Mon, Jun 12, 2017 at 9:48 AM, Greg KH <gre...@linuxfoundation.org> 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. As to serdev, I looked into it and it really could do the job if we redesigned u_serial to be a serdev driver. I don't think we want that since sometimes the user might not want to use real hardware (obex comes to mind easily but it could be any of them really). I think this choice should be left to the user, but then the user needs a way to know they should update the hardware's line coding -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
