Please tell your email client to wrap lines after 72 columns or so. Long lines are very awkward to deal with. On Thu, 24 Jan 2013, Carsten Neumann wrote: > Hi, > > I am planning to build a USB device based on an embedded controller board having a (High-Speed) USB peripheral port and an (Gbit) Ethernet port. > My goal is to "connect" arbitrary USB devices (e.g. physical mass storage / serial devices or gadgets like g_mass_storage, g_serial) attached to a host somewhere on the LAN to my device's USB peripheral port, Connect the arbitrary devices to two hosts, one directly (via a USB connection) and one via a LAN? > so that I can use them on a physical device (e.g. mediaplayer) w/ USB port. I don't see the point. Suppose you connect device A to a USB host and to another computer over a LAN. How does that help you to use device A on device B? > I am new to the linux USB stack, so before I waste days or weeks until I find out it's not possible this way, I decided to ask the specialists. ;-) You should go through the introductory chapters of the USB-2.0 specification (freely available from www.usb.org). They are very readable and will answer a lot of your questions. > Here are my questions: > > Is there a simple way to bind a USB device connected to a host port to a peripheral port (e.g. via an existing gadget)? (Couldn't find one so far.) Peripheral ports are part of USB devices. You can't connected two USB devices together unless they both support USB-OTG -- in which case one of them will be acting as a host, not as a device. > Does the current usbip protocol provide enough information to make this also work for usbip'd devices? (No clue.) To make what work? Usbip does what you described earlier: it allows a host to export its devices to other computers over a network. > If not, would it be (relatively easily) possible to extend the usbip protocol to accomplish this? > If I have to write my own gadget: > It would be more general to bind the usbip-vhci (or whatever HCI) device to a peripheral port. > On the other hand this means more overhead. > The data will go through two drivers (vhci-hcd and my gadget) and both have to run on an embedded controller where I only have limited CPU power. > Therefore it would be better to build one gadget that has the usbip protocol built-in. (The usbip protocol implementation could then possibly be placed into a separate kernel module.) I can't answer these questions because you haven't explained what you want to do sufficiently clearly. > Another question is: are there device controllers which can act as multiple (NOT multifunction composite) devices so that the attached host will see a hub? There are hub controller chips. But they don't act as multiple devices; they act as hubs. Of course, you can always put multiple devices into a single box along with a hub chip; the resulting box will then act as multiple devices. Such things are described as "compound" devices in the USB spec. > I did read something about hub controllers, but are these what I mean and are any supported by the linux USB stack? I don't know _what_ you mean. Yes, hub controllers are supported by Linux's USB stack. If they weren't, nobody would be able to use a USB hub on the Linux-based system. Alan Stern -- 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
