[Cc-ing the USB mailing list as well.] On Mon, Jan 27, 2014 at 06:13:57PM +0200, Valentina Manea wrote: > Hi Sarah, Hi Valentina, > As you probably know, I am working on a set of drivers called USB/IP. > These drivers have some issues that I'm not sure how to approach and > since you are working with the USB subsystem, I figured you might be > willing to give me some suggestions about this. > > These are the issues I'm trying to solve at this point: > > 1. This [1] is the USB/IP architecture. One of the drivers is a HCD > and it is responsible for announcing when a new device is being shared > by pretending it is physically connected to the host. This works fine > but when I "detach" the device, its entry still remains in /dev. Do you mean it still remains in /dev on the client side? > Is there any mechanism a HCD uses to annouce that a device is no > longer available? I tried browsing HCDs in the kernel but didn't see > anything quite obvious. Let me describe how it works with a physical host controller, and maybe that will help you figure out how the virtual host controller should implement it. The basic concept you need to understand is that the USB core attempts to abstract the host controller, and treat it exactly like an external USB hub. This means the USB core does things like send control transfers to the "roothub", which are then intercepted and turned into calls into the host controller driver's hub_control and hub_status_data methods. It's convoluted, but it's how the USB core works. When a USB disconnect happens on a physical host controller, the host hardware detects the disconnect, and changes its port status registers to reflect the disconnect. You'll see those registers described for USB 3.0 hubs in section 10.14.2.6 Get Port Status of the USB 3.0 bus spec, in chapter 10 of the USB 2.0 bus spec. In this case, it would set the connect status change bit, and clear the connected status bit. When the connect status change bit is set, the host hardware will send an interrupt, which the host controller driver intercepts. In the xHCI driver specifically, xhci_irq() is called, we notice there's a port status change event on the event ring, and we deal with it in handle_port_status(). You'll notice that function calls usb_hcd_poll_rh_status(). This kicks khubd, telling it to go look at the ports on our roothub. This eventually causes hub_events() in drivers/usb/core/hub.c to be called. It will call into the hub_status_data() to see if any ports changed. The host driver will set a bit saying "this port has a change bit set". hub_events() will then call into the host controller's hub_control method, and get the port status for that particular port. Based on the port status, the USB core will notice the connect status is set to disconnected, and it will mark the USB device as disconnected, which will cause the /dev entry to disappear. I don't know the details of the stub driver on the server side, so I'm not sure how this translates into the virtual host controller architecture. > 2. This question somehow resembles the previous. When a device is > shared, I don't want it to be available on the host it is physically > attached to anymore. What do you mean by this? Do you mean that when the stub driver on the server starts sharing the device to the client, you don't want it to appear on the server side anymore? > Since the stub driver (in [1]) was converted by > me to a Core driver, is there any way I could tell udev that this > device is no longer available? I'm thinking that since it wouldn't > have a /dev entry anymore, it can't be used locally, only remotely. > I'm not sure this is "the way to go", it sounds a bit like a hack. Why exactly do you want the device to not show up in /dev? I would think what you really want is for the device drivers on the server side to not bind to the device, since the client side drivers should be bound to them instead. I believe there is a mechanism for usbfs drivers to mark a port as "claimed". Perhaps the stub driver could do the same? Alan Stern would have deals on that. Sarah Sharp > Any suggestions and pointers are welcome! > > Thank you, > Valentina > > [1] http://usbip.sourceforge.net/images/usbip-design.png -- 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
