Re: Piping f_acm to real hardware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux