Re: Plug and play for a tty line disciple networking device

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

 



On Wed, Mar 20, 2013 at 9:33 PM, Alan Ott <alan@xxxxxxxxxxx> wrote:
> On 03/20/2013 09:28 PM, jonsmirl@xxxxxxxxx wrote:
>> On Wed, Mar 20, 2013 at 9:19 PM, Alan Ott <alan@xxxxxxxxxxx> wrote:
>>> On 03/20/2013 09:12 PM, jonsmirl@xxxxxxxxx wrote:
>>>> On Wed, Mar 20, 2013 at 8:56 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>> On Wed, Mar 20, 2013 at 08:49:50PM -0400, jonsmirl@xxxxxxxxx wrote:
>>>>>> On Wed, Mar 20, 2013 at 8:38 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>>>> On Wed, Mar 20, 2013 at 08:25:15PM -0400, jonsmirl@xxxxxxxxx wrote:
>>>>>>>> On Wed, Mar 20, 2013 at 8:14 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>>>>>> On Wed, Mar 20, 2013 at 08:04:29PM -0400, jonsmirl@xxxxxxxxx wrote:
>>>>>>>>>> On Wed, Mar 20, 2013 at 7:26 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>>>>>>>> On Tue, Mar 19, 2013 at 11:30:05AM -0400, jonsmirl@xxxxxxxxx wrote:
>>>>>>>>>>>> How can you achieve plug and play for a ft2232 based USB serial device
>>>>>>>>>>>> implementing 802.15.4 networking?
>>>>>>>>>>>>
>>>>>>>>>>>> The device has a 802.15.4 SOC with a UART attached to a ft2232. With
>>>>>>>>>>>> firmware loaded the only thing it can do is talk the 802.15.4 tty line
>>>>>>>>>>>> discipline, it is not a general purpose serial port.
>>>>>>>>>>>>
>>>>>>>>>>>> Right now the device works by plugging it in and it appears as a
>>>>>>>>>>>> generic USB serial device like ttyUSB0. You then run a user space app
>>>>>>>>>>>> which sets the line discipline, holds the port open and attaches it to
>>>>>>>>>>>> the 6lowpan implementation in the networking code. But doing that is
>>>>>>>>>>>> inconvenient and users needs to be trained to do it. Much simpler if
>>>>>>>>>>>> we could just plug the device in and it worked.
>>>>>>>>>>>>
>>>>>>>>>>>> We can add a EEPROM to the ft2232 to give it a unique USB ID.  Is it
>>>>>>>>>>>> possible to make a kernel driver that see this ID, sets the line
>>>>>>>>>>>> discipline and wires the serial port directly into the networking
>>>>>>>>>>>> code?
>>>>>>>>>>> Yes, you can do that.
>>>>>>>>>> Is there an existing driver in the kernel that does this?
>>>>>>>>>> So far all of the ones I've checked still need a user space app.
>>>>>>>>> Look at the bluetooth drivers, they have their own line dicipline I
>>>>>>>>> think.
>>>>>>>> Bluetooth drivers use line discipline on UARTs. On USB they have their
>>>>>>>> own set of Bluetooth descriptors.
>>>>>>>>
>>>>>>>> CAN over serial has a line discipline but it needs a user space app.
>>>>>>> In your driver, just attach the line discipline directly to the tty
>>>>>>> device you create.  You will not be using the "normal" usb-serial logic
>>>>>>> at all if you do this, but you should be fine, right?
>>>>>> USB serial port is based on the FT2232 so we've been using that driver.
>>>>>>
>>>>>> Modifying that driver was my plan for doing this. I was hoping that
>>>>>> there was a more generic way to achieve the same effect.
>>>>> No, sorry, stick with doing this from userspace, it's a simple one-line
>>>>> udev rule, right?
>>>> It is fairly simple to do from user space. But you have to find and
>>>> install the pointless user space app and then get it pointed at the
>>>> correct tty.
>>> The udev rule would handle calling izattach automatically.
>>>
>>>> That app is a hold over from the ancient days. When you killed it the
>>>> serial line would drop the line discipline and revert back to a
>>>> terminal session.
>>>>
>>>> What you really want is for devices in this class is to not create a
>>>> user space tty device at all. They should just make a net-device. But
>>>> there is no way to suppress the creation of the user space tty device.
>>>> So we get two both devices and the xx-attach app.
>>> The udev rule would run when the device gets attached and would call
>>> izattach without any need for user interaction. The user would never
>>> even need to know what /dev/ttyUSBx ever got assigned to it.
>> We can just leave everything the way it is, but I hit this same
>> problem on another project a few years ago.
>>
>> There's just no generic solution in the kernel for handling serially
>> connected networking hardware without having a pointless user space
>> app.
>>
>> Maybe we could make a generic pointless app and get rid of hciattach,
>> canattach, izattach, etc. The generic app would get the line
>> discipline as part of the udev rule.  Even better - put the generic
>> xx-attach code inside udev so we don't have pointless processes
>> hanging around.
>
> Actually, you could use stty for that in the udev rule. You'd have to
> use the line discipline number instead of the name, but those are part
> of the userspace ABI, so they won't change.

stty won't keep the port locked.  Just have to trust people not to mess with it.

>



--
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux