Hi,
I’m working with Greybus and I’m wondering if there’s any support or code for virtual USB devices.
On one side of Greybus I have a small nuttX environment with a UART connected device which I can write modules for, and on the other side of Greybus I’d like to provide a network interface. I can’t modify that side, so I have to work with the kernel modules it has available. I thought it might be possible to present a virtual USB CDC-EVM to Greybus, and my guess (hope) is that cdc_ether would pick it up on the other side.
Is this possible? Has this sort of virtual USB device been created before?
-Greg
On Wed, Mar 22, 2017 at 02:26:52AM -0700, Greg Hazel wrote:
Hi,
I’m working with Greybus and I’m wondering if there’s any support or code for virtual USB devices.
Yes, the USB virtual controller driver is in the kernel, but you need to have it enabled in your firmware as well, as it passes USB commands from the kernel down to the firmware and then USB device directly.
Note, there are some limits on the size of a USB transaction at the moment, we never got the chance to fix them up, but small transactions (like a keyboard), should work fine. Once you start to get up to 4kb in a transaction, you might have firmware issues.
On one side of Greybus I have a small nuttX environment with a UART connected device which I can write modules for, and on the other side of Greybus I’d like to provide a network interface. I can’t modify that side, so I have to work with the kernel modules it has available. I thought it might be possible to present a virtual USB CDC-EVM to Greybus, and my guess (hope) is that cdc_ether would pick it up on the other side.
Ah, if this isn't really a network device, or modem, I wouldn't mess with cdc-evm. If it is a modem, then it should "just work" with the uart code today, just tell userspace this is a modem and all should be fine.
What exactly do you want userspace to see your device as?
hope this helps,
greg k-h
On Wed, Mar 22, 2017 at 11:19:10AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 22, 2017 at 02:26:52AM -0700, Greg Hazel wrote:
Hi,
I’m working with Greybus and I’m wondering if there’s any support or code for virtual USB devices.
Yes, the USB virtual controller driver is in the kernel, but you need to have it enabled in your firmware as well, as it passes USB commands from the kernel down to the firmware and then USB device directly.
The driver that's merged is far from complete I'm afraid. There was some development happening out of tree, but the effort was discontinued and the work in progress never merged back.
Note, there are some limits on the size of a USB transaction at the moment, we never got the chance to fix them up, but small transactions (like a keyboard), should work fine. Once you start to get up to 4kb in a transaction, you might have firmware issues.
That would even be 2k, and you'd still need the out-of-tree driver...
On one side of Greybus I have a small nuttX environment with a UART connected device which I can write modules for, and on the other side of Greybus I’d like to provide a network interface. I can’t modify that side, so I have to work with the kernel modules it has available. I thought it might be possible to present a virtual USB CDC-EVM to Greybus, and my guess (hope) is that cdc_ether would pick it up on the other side.
Ah, if this isn't really a network device, or modem, I wouldn't mess with cdc-evm. If it is a modem, then it should "just work" with the uart code today, just tell userspace this is a modem and all should be fine.
Indeed, that would be the way to go.
Johan
On Mar 22, 2017, at 3:34 AM, Johan Hovold johan@kernel.org wrote:
On Wed, Mar 22, 2017 at 11:19:10AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 22, 2017 at 02:26:52AM -0700, Greg Hazel wrote:
Hi,
I’m working with Greybus and I’m wondering if there’s any support or code for virtual USB devices.
Yes, the USB virtual controller driver is in the kernel, but you need to have it enabled in your firmware as well, as it passes USB commands from the kernel down to the firmware and then USB device directly.
The driver that's merged is far from complete I'm afraid. There was some development happening out of tree, but the effort was discontinued and the work in progress never merged back.
Which side is not likely to work well? I can control the virtual device side, but not the host side.
Note, there are some limits on the size of a USB transaction at the moment, we never got the chance to fix them up, but small transactions (like a keyboard), should work fine. Once you start to get up to 4kb in a transaction, you might have firmware issues.
That would even be 2k, and you'd still need the out-of-tree driver…
1500 bytes is the typical ethernet MTU, so even with overhead is 2k is reasonable?
On one side of Greybus I have a small nuttX environment with a UART connected device which I can write modules for, and on the other side of Greybus I’d like to provide a network interface. I can’t modify that side, so I have to work with the kernel modules it has available. I thought it might be possible to present a virtual USB CDC-EVM to Greybus, and my guess (hope) is that cdc_ether would pick it up on the other side.
Ah, if this isn't really a network device, or modem, I wouldn't mess with cdc-evm. If it is a modem, then it should "just work" with the uart code today, just tell userspace this is a modem and all should be fine.
Indeed, that would be the way to go.
This suggestion isn’t clear to me. The UART device is not a standard network device or modem; it needs some of my software to behave like one. I’d like to present it in a way that Greybus can provide to the host machine. cdc-evm was my first guess at that interface; but what do you think would be better?
-Greg
On Wed, Mar 22, 2017 at 03:50:11AM -0700, Greg Hazel wrote:
On Mar 22, 2017, at 3:34 AM, Johan Hovold johan@kernel.org wrote:
On Wed, Mar 22, 2017 at 11:19:10AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 22, 2017 at 02:26:52AM -0700, Greg Hazel wrote:
Hi,
I’m working with Greybus and I’m wondering if there’s any support or code for virtual USB devices.
Yes, the USB virtual controller driver is in the kernel, but you need to have it enabled in your firmware as well, as it passes USB commands from the kernel down to the firmware and then USB device directly.
The driver that's merged is far from complete I'm afraid. There was some development happening out of tree, but the effort was discontinued and the work in progress never merged back.
Which side is not likely to work well? I can control the virtual device side, but not the host side.
Neither. You'd basically need to implement Greybus USB briged-phy support for both sides (linux and nuttx).
Note, there are some limits on the size of a USB transaction at the moment, we never got the chance to fix them up, but small transactions (like a keyboard), should work fine. Once you start to get up to 4kb in a transaction, you might have firmware issues.
That would even be 2k, and you'd still need the out-of-tree driver…
1500 bytes is the typical ethernet MTU, so even with overhead is 2k is reasonable?
Yes.
On one side of Greybus I have a small nuttX environment with a UART connected device which I can write modules for, and on the other side of Greybus I’d like to provide a network interface. I can’t modify that side, so I have to work with the kernel modules it has available. I thought it might be possible to present a virtual USB CDC-EVM to Greybus, and my guess (hope) is that cdc_ether would pick it up on the other side.
Ah, if this isn't really a network device, or modem, I wouldn't mess with cdc-evm. If it is a modem, then it should "just work" with the uart code today, just tell userspace this is a modem and all should be fine.
Indeed, that would be the way to go.
This suggestion isn’t clear to me. The UART device is not a standard network device or modem; it needs some of my software to behave like one. I’d like to present it in a way that Greybus can provide to the host machine. cdc-evm was my first guess at that interface; but what do you think would be better?
You said you have a UART connected device on your module, so the easiest way to expose that is to use the Greybus bridged-phy class to expose it as a tty device to user space.
What exactly do you have connected on the other side of that module uart?
Johan
On Mar 22, 2017, at 4:07 AM, Johan Hovold johan@kernel.org wrote:
On Wed, Mar 22, 2017 at 03:50:11AM -0700, Greg Hazel wrote:
On one side of Greybus I have a small nuttX environment with a UART connected device which I can write modules for, and on the other side of Greybus I’d like to provide a network interface. I can’t modify that side, so I have to work with the kernel modules it has available. I thought it might be possible to present a virtual USB CDC-EVM to Greybus, and my guess (hope) is that cdc_ether would pick it up on the other side.
Ah, if this isn't really a network device, or modem, I wouldn't mess with cdc-evm. If it is a modem, then it should "just work" with the uart code today, just tell userspace this is a modem and all should be fine.
Indeed, that would be the way to go.
This suggestion isn’t clear to me. The UART device is not a standard network device or modem; it needs some of my software to behave like one. I’d like to present it in a way that Greybus can provide to the host machine. cdc-evm was my first guess at that interface; but what do you think would be better?
You said you have a UART connected device on your module, so the easiest way to expose that is to use the Greybus bridged-phy class to expose it as a tty device to user space.
What exactly do you have connected on the other side of that module uart?
That UART is currently a TI SimpleLink/EasyLink. I’m also considering a slip-radio. These are relatively simple wrappers from radio to ethernet. Most importantly, I can only control the software on my side of the Greybus, so using bridged-phy to expose the UART as a tty would not enable me to use the tty on the other side…
-Greg
On Wed, Mar 22, 2017 at 04:19:30AM -0700, Greg Hazel wrote:
What exactly do you have connected on the other side of that module uart?That UART is currently a TI SimpleLink/EasyLink. I’m also considering a slip-radio. These are relatively simple wrappers from radio to ethernet. Most importantly, I can only control the software on my side of the Greybus, so using bridged-phy to expose the UART as a tty would not enable me to use the tty on the other side…
Well, go yell at your system engineers then, you can't fix broken systems by working around it in the kernel :)
The greybus TTY interface should work just fine for you here, that's what it was designed for.
thanks,
greg k-h
On Mar 22, 2017, at 4:22 AM, Greg KH greg@kroah.com wrote:
On Wed, Mar 22, 2017 at 04:19:30AM -0700, Greg Hazel wrote:
What exactly do you have connected on the other side of that module uart?
That UART is currently a TI SimpleLink/EasyLink. I’m also considering a slip-radio. These are relatively simple wrappers from radio to ethernet. Most importantly, I can only control the software on my side of the Greybus, so using bridged-phy to expose the UART as a tty would not enable me to use the tty on the other side…
Well, go yell at your system engineers then, you can't fix broken systems by working around it in the kernel :)
The greybus TTY interface should work just fine for you here, that's what it was designed for.
I agree! However, yelling at large device manufacturers hasn’t proved fruitful for me.
So taking the scenic route; is there a better way than cdc-evm?
-Greg
On Wed, Mar 22, 2017 at 04:29:09AM -0700, Greg Hazel wrote:
On Mar 22, 2017, at 4:22 AM, Greg KH greg@kroah.com wrote:
On Wed, Mar 22, 2017 at 04:19:30AM -0700, Greg Hazel wrote:
What exactly do you have connected on the other side of that module uart?
That UART is currently a TI SimpleLink/EasyLink. I’m also considering a slip-radio. These are relatively simple wrappers from radio to ethernet. Most importantly, I can only control the software on my side of the Greybus, so using bridged-phy to expose the UART as a tty would not enable me to use the tty on the other side…
Well, go yell at your system engineers then, you can't fix broken systems by working around it in the kernel :)
The greybus TTY interface should work just fine for you here, that's what it was designed for.
I agree! However, yelling at large device manufacturers hasn’t proved fruitful for me.
Then provide a userspace application that interfaces with the tty device and creates the connection that way? There's no way that any random network device showing up is going to work properly without some system changes happening.
So taking the scenic route; is there a better way than cdc-evm?
It's a tty device, make it a tty device :)
good luck!
greg k-h
On Mar 22, 2017, at 4:33 AM, Greg KH greg@kroah.com wrote:
On Wed, Mar 22, 2017 at 04:29:09AM -0700, Greg Hazel wrote:
On Mar 22, 2017, at 4:22 AM, Greg KH greg@kroah.com wrote:
On Wed, Mar 22, 2017 at 04:19:30AM -0700, Greg Hazel wrote:
What exactly do you have connected on the other side of that module uart?
That UART is currently a TI SimpleLink/EasyLink. I’m also considering a slip-radio. These are relatively simple wrappers from radio to ethernet. Most importantly, I can only control the software on my side of the Greybus, so using bridged-phy to expose the UART as a tty would not enable me to use the tty on the other side…
Well, go yell at your system engineers then, you can't fix broken systems by working around it in the kernel :)
The greybus TTY interface should work just fine for you here, that's what it was designed for.
I agree! However, yelling at large device manufacturers hasn’t proved fruitful for me.
Then provide a userspace application that interfaces with the tty device and creates the connection that way? There's no way that any random network device showing up is going to work properly without some system changes happening.
A userspace application could only provide a connection through VPN, which is encumbered with authorization dialogs and UI complications.
The user-experience of a USB ethernet device connecting is much better (I’ve tried with a real adapter), so if that’s possible it does seem to be worth the effort.
So taking the scenic route; is there a better way than cdc-evm?
It's a tty device, make it a tty device :)
Unfortunately this would mean asking users on the host side to unlock and root their device, which is very difficult and often against their warranty agreement.
-Greg
On Wed, Mar 22, 2017 at 04:39:01AM -0700, Greg Hazel wrote:
On Mar 22, 2017, at 4:33 AM, Greg KH <greg@kroah.com> wrote: On Wed, Mar 22, 2017 at 04:29:09AM -0700, Greg Hazel wrote: On Mar 22, 2017, at 4:22 AM, Greg KH <greg@kroah.com> wrote: On Wed, Mar 22, 2017 at 04:19:30AM -0700, Greg Hazel wrote: What exactly do you have connected on the other side of that module uart? That UART is currently a TI SimpleLink/EasyLink. I’m also considering a slip-radio. These are relatively simple wrappers from radio to ethernet. Most importantly, I can only control the software on my side of the Greybus, so using bridged-phy to expose the UART as a tty would not enable me to use the tty on the other side… Well, go yell at your system engineers then, you can't fix broken systems by working around it in the kernel :) The greybus TTY interface should work just fine for you here, that's what it was designed for. I agree! However, yelling at large device manufacturers hasn’t proved fruitful for me. Then provide a userspace application that interfaces with the tty device and creates the connection that way? There's no way that any random network device showing up is going to work properly without some system changes happening.A userspace application could only provide a connection through VPN, which is encumbered with authorization dialogs and UI complications.
I agree.
The user-experience of a USB ethernet device connecting is much better (I’ve tried with a real adapter), so if that’s possible it does seem to be worth the effort.
Right now, no, there is no greybus network driver, sorry, so this isn't going to work, unless you get the USB host controller code to work, _AND_ have the correct USB networking driver loaded in the kernel.
That last point you might have a problem with on the system side as well.
So taking the scenic route; is there a better way than cdc-evm? It's a tty device, make it a tty device :)Unfortunately this would mean asking users on the host side to unlock and root their device, which is very difficult and often against their warranty agreement.
Again, this isn't a kernel issue, but rather an issue with the system you are working on. Not much the kernel can do here, sorry :(
good luck!
greg k-h
On Mar 22, 2017, at 4:58 AM, Greg KH greg@kroah.com wrote:
The user-experience of a USB ethernet device connecting is much better (I’ve tried with a real adapter), so if that’s possible it does seem to be worth the effort.
Right now, no, there is no greybus network driver, sorry, so this isn't going to work, unless you get the USB host controller code to work, _AND_ have the correct USB networking driver loaded in the kernel.
That last point you might have a problem with on the system side as well.
The cdc_ether driver does seem to pick up native USB devices on the system side correctly. Is that sufficient for the last point?
-Greg
On Wed, Mar 22, 2017 at 05:13:35AM -0700, Greg Hazel wrote:
On Mar 22, 2017, at 4:58 AM, Greg KH greg@kroah.com wrote:
The user-experience of a USB ethernet device connecting is much better (I’ve tried with a real adapter), so if that’s possible it does seem to be worth the effort. Right now, no, there is no greybus network driver, sorry, so this isn't going to work, unless you get the USB host controller code to work, _AND_ have the correct USB networking driver loaded in the kernel. That last point you might have a problem with on the system side as well.The cdc_ether driver does seem to pick up native USB devices on the system side correctly. Is that sufficient for the last point?
Are you sure that the systems you are using all have that driver already enabled? Good luck!
greg k-h
-
Greg Hazel -
Greg KH -
Johan Hovold