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