James Carlson : > Colin Zou - Sun Microsystems writes: > >> Seems to me that there lack of some background introduction for WUSB. I >> just wrote a blog about WUSB association, it is offering the background >> info to this issue. Please take a look at: >> http://blogs.sun.com/colin/entry/association_the_difference_between_usb >> > > I see. Actually, it sounds to me like this new "CC" feature would be > useful for regular wired USB as well. > > For wired USB, a common problem is that the device is identified by > its attachment point on the system. If you plug the device into a > different port, it becomes a different device, and the system (as I > understand it) has to "guess" whether it's really the same one. That > works somewhat well for self-identifying things like disks that have > serial numbers and perhaps a saved mount point, but much less well > otherwise. > > I'd very much like to have device identity down below this level, and > the CC feature sounds ideal for doing that. Why is it designed to be > wireless only? > I agree that it will be good if wired USB also has a feature similar as CC. However, we are not in charge of USB standards. usb.org does not design such a feature for wired USB. If there is a chance, I would like to propose it to usb.org for its future spec releases. The CC feature is not something only on host software side, it also relies on device hardware. Therefore, it needs the industry standards' support and also device vendor's support.
> >> And, to be clear, the implementation for supporting WUSB on Solaris >> comform to the existing usba(7D) framework on Solaris and also devfsadm >> framework. WUSB device enumeration is the same as USB on Solaris. The >> difference is "Association" which is a new concept for wireless USB >> only. It is discussed in detail in the above link. >> > > It implies a bit of an oddity, though. In order for enumeration to > follow "assocation," this means that the association daemon (wusbd) > must somehow learn about and communicate with a device that has not > yet been enumerated. That itself sounds _like_ an enumeration, > identification, and attachment sequence. > The kind of "enumeration" you mentioned is actually done by the existing Solaris USB framework. Let me explain this in detail. Take Cable Association as an example, the whole association process is as following: 1. user plug the WUSB device to a usb port on the PC box. 2. the Soalris USB framework (usba(7D) and ehci(7D)) gets the device plug event and enumerates the device as a wired USB device. 3. usba attach the wusb_ca driver to the device. wusb_ca driver is a newly introduced driver for Cable Association only. It is a normal wired USB driver developed on wired USB driver API, fully compliant to Solaris USB framework. 4. User run wusbadm tool to specify with which WUSB host the device should be associated. 5. wusbadm tool sends a request to wusbd, who will then open the device node created by wusb_ca USB driver. 6. wusbd talk to the device via wusb_ca driver to create a CC. It then store the CC to CC database in file system, in the mean while, it loads the CC to the WUSB host driver. 7. wusbd then complete the association request from wusbadm tool. 8. Association is done. User then unplug the device. wusba_ca driver is then dettached. After the above is done, user can then turn on the device radio to connect the WUSB device with host over air. The subsequent wireless enumeration is the same as wired USB. A newly introduced WUSB host driver (e.g., whci) is developer on the existing Solaris USB framework (usba). whci driver gets the device radio signal and consider it as a device plug event. It passes the event to usba framework module, the latter then load an existing USB device driver (e.g. usbprn(7D) if the device is a WUSB printer) to attach to the WUSB device. If user reboot the system, wusbd daemon will load the CCs stored in the CC database to WUSB host driver instances. So that WUSB host can be ready to connect the associated devices. Please note that, it is necessary to have a daemon (wusbd) because the daemon can load CCs to WUSB host drivers automatically after system reboot. Users want the WUSB device just work after each reboot, instead of manually running a tool to load CCs. Thanks, Colin
