From Artem.Kachitchkin@sun.com Tue Jul 10 11:49:32 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l6AInW1s015897 for ; Tue, 10 Jul 2007 11:49:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6AIlbbG022039 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jul 2007 11:47:38 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKZ00G0787DSN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Jul 2007 11:47:37 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00D1R87CT540@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Jul 2007 11:47:36 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6AIlaXk019471 for ; Tue, 10 Jul 2007 11:47:36 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JKZ00E017P0C700@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Jul 2007 11:47:36 -0700 (PDT) Received: from [129.150.19.191] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKZ00391879O500@fe-sfbay-09.sun.com>; Tue, 10 Jul 2007 11:47:34 -0700 (PDT) Date: Tue, 10 Jul 2007 11:47:12 -0700 From: Artem Kachitchkine Subject: PSARC/2007/406 USB device reset Sender: Artem.Kachitchkin@sun.com To: PSARC-ext@sun.com Cc: Lin.Guo@sun.com Message-id: <4693D430.70008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 5209 I am sponsoring this case for Lin Guo. Requested binding is patch/micro, timeout 07/17/2007. -Artem. Template Version: @(#)sac_nextcase 1.63 06/14/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: USB device reset 1.2. Name of Document Author/Supplier: Author: Lin Guo 1.3 Date of This Document: 10 July, 2007 4. Technical Description 4.1. Problem The Solaris USB Architecture (USBA) does not provide a client driver to request hardware reset for a USB device, which may be required in some situations such as: - Some USB devices need the driver to upload firmware into devices' RAM and initiate a hardware reset in order to activate the new firmware. - Hardware reset may help drivers to recover devices from an error state caused by physical or firmware defects. Other major OSes, such as Microsoft Windows and Linux, provide such interface to device drivers. 4.2. Proposal We propose to introduce a new DDI function usb_reset_device(9F): int usb_reset_device(dev_info_t *dip, usb_dev_reset_lvl_t reset_level); 4.3. Details The Universal Serial Bus Specification Revision 2.0 defines a standard PORT RESET request which generates an electrical reset signaling on the requested hub port. Upon receipt of the reset signaling, the downstream device on the port will perform a hardware reset and return to the default state. So we can implement the device reset function based on the standard PORT RESET request. From a client driver's perspective, the effect of usb_reset_device(9F) is the same as that of physical hot-removal followed by immediate physical reinsersion. The same driver code that handles actual hotplugging will be activated. Some devices change their "identity" when firmware is uploaded and the device is reset - a change that is reflected via device's USB descriptors. In such event the related kernel data structures need to be updated and compatible names regenerated. Therefore, these devices need to be detached from the original driver and make a new driver binding according to the new compatible names. Drivers can indicate the need to reattach using the reset level parameter. int usb_reset_device(dev_info_t *dip, usb_dev_reset_lvl_t reset_level); The valid values for reset_level are: USB_RESET_LVL_DEFAULT Default reset level. The device is reset, all error status is cleared, the device state machines and registers are also cleared and need to be reinitialized in the driver. The current driver remains attached. This reset level applies to hardware error recovery, or firmware download without descriptors changing. USB_RESET_LVL_REATTACH The device is reset, the original driver is detached and a new driver attaching process is started according to the updated compatible name. This reset level applies to the firmware download with the descriptors changing, or other situations in which the device needs to be reenumerated. usb_reset_device(9F) creates a new helper thread for reattach. When called from attach(9E), the new thread sets a timer (1s) and waits until the driver's attach(9E) completes, after which the thread attempts to reattach the driver. When not called from attach(9E), the new thread will attempt the reattach the driver immediately. If driver reattach fails, an error message is printed in system log with the detailed reason and the driver will be recovered to a stable state which depends on where the failure happened. Return values: USB_SUCCESS With USB_RESET_LVL_DEFAULT: the device was reset successfully. With USB_RESET_LVL_REATTACH: reenumeration was started successfully or a previous reset is still in progress. USB_INVALID_ARGS Invalid arguments. USB_INVALID_CONTEXT Called from interrupt context with USB_RESET_LVL_DEFAULT specified. USB_INVALID_PERM The driver of the dip does not own the entire device. USB_BUSY One or more pipes other than the default control pipe are open on the device with USB_RESET_LVL_DEFAULT specified. USB_FAILURE The state of the device's parent hub is invalid (disconnected or suspended). Called when the driver is detached. The port associated with the device failed to be reset. Reenumeration fails to start with USB_RESET_LVL_REATTACH specified. The function can be called from user or kernel context. 4.4. Interfaces -----------------------+-----------+-------------------------------------- usb_device_reset | Committed | USB device reset function usb_dev_reset_lvl_t | Committed | reset level type USB_RESET_LVL_DEFAULT | Committed | reset level value USB_RESET_LVL_REATTACH | Committed | reset level value -----------------------+-----------+-------------------------------------- Binding: patch/micro 4.5. References Universal Serial Bus Specification Revision 2.0 http://www.usb.org/developers/docs/usb_20_040907.zip PSARC/1998/111 Universal Serial Bus Framework Support PSARC/2000/542 USB Architecture Update project PSARC/2003/207 USBA2.0: adding USBA interfaces to the DDI 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Neal.Pollack@sun.com Tue Jul 10 13:12:22 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l6AKCLmQ019834 for ; Tue, 10 Jul 2007 13:12:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6AKAG26026637 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jul 2007 04:10:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKZ00303C1B4600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Jul 2007 13:10:23 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00I0RC1BN4F0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Jul 2007 13:10:23 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6AKANnS028358 for ; Tue, 10 Jul 2007 13:10:23 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JKZ00501BYXDA00@fe-sfbay-10.sun.com> (original mail from Neal.Pollack@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Jul 2007 13:10:23 -0700 (PDT) Received: from [10.1.48.130] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKZ003VCC14Y2E0@fe-sfbay-10.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Jul 2007 13:10:16 -0700 (PDT) Date: Tue, 10 Jul 2007 13:10:15 -0700 From: Neal Pollack Subject: Re: PSARC/2007/406 USB device reset In-reply-to: <4693D430.70008@sun.com> Sender: Neal.Pollack@sun.com To: Artem Kachitchkine Cc: PSARC-ext@sun.com, Lin.Guo@sun.com Message-id: <4693E7A7.6030608@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4693D430.70008@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070521) Status: RO Content-Length: 5716 Artem Kachitchkine wrote: > I am sponsoring this case for Lin Guo. > Requested binding is patch/micro, timeout 07/17/2007. > > -Artem. > > Template Version: @(#)sac_nextcase 1.63 06/14/07 SMI > This information is Copyright 2007 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > USB device reset > 1.2. Name of Document Author/Supplier: > Author: Lin Guo > 1.3 Date of This Document: > 10 July, 2007 > 4. Technical Description > 4.1. Problem > > The Solaris USB Architecture (USBA) does not provide a client driver to > request hardware reset for a USB device, which may be required in some > situations such as: > > - Some USB devices need the driver to upload firmware into devices' RAM > and initiate a hardware reset in order to activate the new firmware. > > - Hardware reset may help drivers to recover devices from an error state > caused by physical or firmware defects. Will this functionality also assist in the upcoming attempts to get Suspend-Resume going on x86 systems? I know we (our team) need to add hooks in the other disk/net/display drivers, for example. Neal > > Other major OSes, such as Microsoft Windows and Linux, provide such > interface to device drivers. > > 4.2. Proposal > > We propose to introduce a new DDI function usb_reset_device(9F): > > int usb_reset_device(dev_info_t *dip, usb_dev_reset_lvl_t reset_level); > > 4.3. Details > > The Universal Serial Bus Specification Revision 2.0 defines a standard > PORT RESET request which generates an electrical reset signaling on the > requested hub port. Upon receipt of the reset signaling, the downstream > device on the port will perform a hardware reset and return to the > default state. So we can implement the device reset function based on > the standard PORT RESET request. > > From a client driver's perspective, the effect of usb_reset_device(9F) is > the same as that of physical hot-removal followed by immediate physical > reinsersion. The same driver code that handles actual hotplugging will be > activated. > > Some devices change their "identity" when firmware is uploaded and the > device is reset - a change that is reflected via device's USB > descriptors. In such event the related kernel data structures need to be > updated and compatible names regenerated. Therefore, these devices need > to be detached from the original driver and make a new driver binding > according to the new compatible names. Drivers can indicate the need to > reattach using the reset level parameter. > > int usb_reset_device(dev_info_t *dip, usb_dev_reset_lvl_t reset_level); > > The valid values for reset_level are: > > USB_RESET_LVL_DEFAULT > > Default reset level. The device is reset, all error status is cleared, > the device state machines and registers are also cleared and need to be > reinitialized in the driver. The current driver remains attached. This > reset level applies to hardware error recovery, or firmware download > without descriptors changing. > > USB_RESET_LVL_REATTACH > > The device is reset, the original driver is detached and a new driver > attaching process is started according to the updated compatible name. > This reset level applies to the firmware download with the descriptors > changing, or other situations in which the device needs to be > reenumerated. > > usb_reset_device(9F) creates a new helper thread for reattach. When > called from attach(9E), the new thread sets a timer (1s) and waits until > the driver's attach(9E) completes, after which the thread attempts to > reattach the driver. When not called from attach(9E), the new thread will > attempt the reattach the driver immediately. > > If driver reattach fails, an error message is printed in system log with > the detailed reason and the driver will be recovered to a stable state > which depends on where the failure happened. > > Return values: > > USB_SUCCESS > > With USB_RESET_LVL_DEFAULT: the device was reset successfully. > With USB_RESET_LVL_REATTACH: reenumeration was started successfully or a > previous reset is still in progress. > > USB_INVALID_ARGS > > Invalid arguments. > > USB_INVALID_CONTEXT > > Called from interrupt context with USB_RESET_LVL_DEFAULT specified. > > USB_INVALID_PERM > > The driver of the dip does not own the entire device. > > USB_BUSY > > One or more pipes other than the default control pipe are open on the > device with USB_RESET_LVL_DEFAULT specified. > > USB_FAILURE > > The state of the device's parent hub is invalid (disconnected or > suspended). > Called when the driver is detached. > The port associated with the device failed to be reset. > Reenumeration fails to start with USB_RESET_LVL_REATTACH specified. > > The function can be called from user or kernel context. > > 4.4. Interfaces > > -----------------------+-----------+-------------------------------------- > > usb_device_reset | Committed | USB device reset function > usb_dev_reset_lvl_t | Committed | reset level type > USB_RESET_LVL_DEFAULT | Committed | reset level value > USB_RESET_LVL_REATTACH | Committed | reset level value > -----------------------+-----------+-------------------------------------- > > > Binding: patch/micro > > 4.5. References > > Universal Serial Bus Specification Revision 2.0 > http://www.usb.org/developers/docs/usb_20_040907.zip > > PSARC/1998/111 Universal Serial Bus Framework Support > PSARC/2000/542 USB Architecture Update project > PSARC/2003/207 USBA2.0: adding USBA interfaces to the DDI > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > From Lin.Guo@sun.com Tue Jul 10 19:28:55 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l6B2St0i004240 for ; Tue, 10 Jul 2007 19:28:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6B2Qx6c004291 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jul 2007 19:27:00 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKZ00M0VTH0NL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Jul 2007 20:27:00 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00IKJTGTMOB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 10 Jul 2007 20:26:54 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6B2Qqvp018762 for ; Wed, 11 Jul 2007 02:26:52 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKZ00E01TB7KJ00@mail-apac.sun.com> (original mail from Lin.Guo@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 11 Jul 2007 10:26:52 +0800 (SGT) Received: from [129.158.218.96] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKZ0005STGO8IXT@mail-apac.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 11 Jul 2007 10:26:49 +0800 (SGT) Date: Wed, 11 Jul 2007 10:22:44 +0800 From: Lin Guo Subject: Re: PSARC/2007/406 USB device reset In-reply-to: <4693E7A7.6030608@Sun.Com> Sender: Lin.Guo@sun.com To: Neal Pollack Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <46943EF4.6000201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: zh-cn X-PMX-Version: 5.2.0.264296 References: <4693D430.70008@sun.com> <4693E7A7.6030608@Sun.Com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; zh-CN; rv:1.7) Gecko/20050614 Status: RO Content-Length: 6274 Neal Pollack wrote: > Artem Kachitchkine wrote: > >> I am sponsoring this case for Lin Guo. >> Requested binding is patch/micro, timeout 07/17/2007. >> >> -Artem. >> >> Template Version: @(#)sac_nextcase 1.63 06/14/07 SMI >> This information is Copyright 2007 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> USB device reset >> 1.2. Name of Document Author/Supplier: >> Author: Lin Guo >> 1.3 Date of This Document: >> 10 July, 2007 >> 4. Technical Description >> 4.1. Problem >> >> The Solaris USB Architecture (USBA) does not provide a client driver to >> request hardware reset for a USB device, which may be required in some >> situations such as: >> >> - Some USB devices need the driver to upload firmware into devices' RAM >> and initiate a hardware reset in order to activate the new firmware. >> >> - Hardware reset may help drivers to recover devices from an error state >> caused by physical or firmware defects. > > > Will this functionality also assist in the upcoming attempts to get > Suspend-Resume > going on x86 systems? > I know we (our team) need to add hooks in the other disk/net/display > drivers, for example. > > Neal No, it will not. The reset is hardware reset for a USB device. It is aimed to activate the new firmware in attach() or recover a usb device from a hardware error state. We made this function for requirements from Wireless USB dongle and USB wlan 802.11 device. Both of them need a haredware reset after uploading firmware into themselves. Lin > >> >> Other major OSes, such as Microsoft Windows and Linux, provide such >> interface to device drivers. >> >> 4.2. Proposal >> >> We propose to introduce a new DDI function usb_reset_device(9F): >> >> int usb_reset_device(dev_info_t *dip, usb_dev_reset_lvl_t reset_level); >> >> 4.3. Details >> >> The Universal Serial Bus Specification Revision 2.0 defines a standard >> PORT RESET request which generates an electrical reset signaling on the >> requested hub port. Upon receipt of the reset signaling, the downstream >> device on the port will perform a hardware reset and return to the >> default state. So we can implement the device reset function based on >> the standard PORT RESET request. >> >> From a client driver's perspective, the effect of >> usb_reset_device(9F) is >> the same as that of physical hot-removal followed by immediate physical >> reinsersion. The same driver code that handles actual hotplugging >> will be >> activated. >> >> Some devices change their "identity" when firmware is uploaded and the >> device is reset - a change that is reflected via device's USB >> descriptors. In such event the related kernel data structures need to be >> updated and compatible names regenerated. Therefore, these devices need >> to be detached from the original driver and make a new driver binding >> according to the new compatible names. Drivers can indicate the need to >> reattach using the reset level parameter. >> >> int usb_reset_device(dev_info_t *dip, usb_dev_reset_lvl_t reset_level); >> >> The valid values for reset_level are: >> >> USB_RESET_LVL_DEFAULT >> >> Default reset level. The device is reset, all error status is cleared, >> the device state machines and registers are also cleared and need to be >> reinitialized in the driver. The current driver remains attached. This >> reset level applies to hardware error recovery, or firmware download >> without descriptors changing. >> >> USB_RESET_LVL_REATTACH >> >> The device is reset, the original driver is detached and a new driver >> attaching process is started according to the updated compatible name. >> This reset level applies to the firmware download with the descriptors >> changing, or other situations in which the device needs to be >> reenumerated. >> >> usb_reset_device(9F) creates a new helper thread for reattach. When >> called from attach(9E), the new thread sets a timer (1s) and waits until >> the driver's attach(9E) completes, after which the thread attempts to >> reattach the driver. When not called from attach(9E), the new thread >> will >> attempt the reattach the driver immediately. >> >> If driver reattach fails, an error message is printed in system log with >> the detailed reason and the driver will be recovered to a stable state >> which depends on where the failure happened. >> >> Return values: >> >> USB_SUCCESS >> >> With USB_RESET_LVL_DEFAULT: the device was reset successfully. >> With USB_RESET_LVL_REATTACH: reenumeration was started successfully or a >> previous reset is still in progress. >> >> USB_INVALID_ARGS >> >> Invalid arguments. >> >> USB_INVALID_CONTEXT >> >> Called from interrupt context with USB_RESET_LVL_DEFAULT specified. >> >> USB_INVALID_PERM >> >> The driver of the dip does not own the entire device. >> >> USB_BUSY >> >> One or more pipes other than the default control pipe are open on the >> device with USB_RESET_LVL_DEFAULT specified. >> >> USB_FAILURE >> >> The state of the device's parent hub is invalid (disconnected or >> suspended). >> Called when the driver is detached. >> The port associated with the device failed to be reset. >> Reenumeration fails to start with USB_RESET_LVL_REATTACH specified. >> >> The function can be called from user or kernel context. >> >> 4.4. Interfaces >> >> -----------------------+-----------+-------------------------------------- >> >> usb_device_reset | Committed | USB device reset function >> usb_dev_reset_lvl_t | Committed | reset level type >> USB_RESET_LVL_DEFAULT | Committed | reset level value >> USB_RESET_LVL_REATTACH | Committed | reset level value >> -----------------------+-----------+-------------------------------------- >> >> >> Binding: patch/micro >> >> 4.5. References >> >> Universal Serial Bus Specification Revision 2.0 >> http://www.usb.org/developers/docs/usb_20_040907.zip >> >> PSARC/1998/111 Universal Serial Bus Framework Support >> PSARC/2000/542 USB Architecture Update project >> PSARC/2003/207 USBA2.0: adding USBA interfaces to the DDI >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> > From Artem.Kachitchkin@sun.com Tue Jul 17 14:29:56 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l6HLTuMT001625 for ; Tue, 17 Jul 2007 14:29:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6HLQxFw019444 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 17 Jul 2007 15:26:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JLC00M3NEAJD300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 17 Jul 2007 14:27:55 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLC00I9XEAF5280@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 17 Jul 2007 14:27:51 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6HLRpTP019279 for ; Tue, 17 Jul 2007 14:27:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JLC00D01E9KAO00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 17 Jul 2007 14:27:51 -0700 (PDT) Received: from [129.150.21.90] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JLC00G37EABKK50@fe-sfbay-10.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 17 Jul 2007 14:27:48 -0700 (PDT) Date: Tue, 17 Jul 2007 14:28:11 -0700 From: Artem Kachitchkine Subject: Re: PSARC/2007/406 USB device reset In-reply-to: <4693D430.70008@sun.com> Sender: Artem.Kachitchkin@sun.com To: PSARC-ext@sun.com Cc: Lin.Guo@sun.com Message-id: <469D346B.2010303@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4693D430.70008@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 116 With no outstanding issues, the case's sands of time have run out, thereby rendering it closed approved. -Artem.