From owner-freebsd-usb@FreeBSD.ORG Mon Mar 30 09:32:28 2015 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0597DD46 for ; Mon, 30 Mar 2015 09:32:28 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7F22123 for ; Mon, 30 Mar 2015 09:32:27 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C96791FE023; Mon, 30 Mar 2015 11:32:25 +0200 (CEST) Message-ID: <55191859.5090209@selasky.org> Date: Mon, 30 Mar 2015 11:33:13 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kohji Okuno , freebsd-usb@freebsd.org Subject: Re: Why do we try to enter U1 mode in SuperSpeed? References: <20150330.135402.19625324788487516.okuno.kohji@jp.panasonic.com> <55190F3C.4070901@selasky.org> <55191530.3030804@selasky.org> In-Reply-To: <55191530.3030804@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 09:32:28 -0000 On 03/30/15 11:19, Hans Petter Selasky wrote: > On 03/30/15 10:54, Hans Petter Selasky wrote: >> On 03/30/15 06:54, Kohji Okuno wrote: >>> Hi HPS >>> >>> I have a question. >>> Why do we try to enter U1 mode in SuperSpeed? >>> This is the following codes(***) >>> >>> In our proprietary environmen(This has a xHCI controller), when a >>> device accept U1, the device may be strange status. Acutually, when I >>> tried to connect "Western Digital My Passport Essential 320GB >>> (P/N:WDBACY3200ABK-00)", this HDD was not recognized correctly. >>> But, in PC environment, this HDD was recognized correctly. >>> >>> Regards, >>> Kohji Okuno >>> >>> (***) >>> usb_hub.c: >>> 793 if (speed == USB_SPEED_SUPER) { >>> 794 err = usbd_req_set_hub_u1_timeout(udev, NULL, >>> 795 portno, 128 - (2 * udev->depth)); >>> 796 if (err) { >>> 797 DPRINTFN(0, "port %d U1 timeout " >>> 798 "failed, error=%s\n", >>> 799 portno, usbd_errstr(err)); >>> 800 } >>> 801 err = usbd_req_set_hub_u2_timeout(udev, NULL, >>> 802 portno, 128 - (2 * udev->depth)); >>> 803 if (err) { >>> 804 DPRINTFN(0, "port %d U2 timeout " >>> 805 "failed, error=%s\n", >>> 806 portno, usbd_errstr(err)); >>> 807 } >>> 808 } >> >> Hi, >> >> We are not trying to enter U1 mode, we only setup the U1 and U2 >> timeouts. Is there a flag in the USB descriptors that say this is not >> supported and that we need to set some other value? I thought all >> superspeed devices had to support these features and that switching in >> and out of the sleep modes was done by the XHCI hardware. >> >> --HPS >> > > Hi, > > Looking at the USB 3.0 specification, I think there might be a typo there: > > In table 10-13 - "U2 timeout value encoding", it says that 0xFE > corresponds to 65024 ms, but I think it should be 65024 _us_ ! > > Try programming values 0xFF for both U1 and U2. Does the device > enumerate then? > > Maybe it only doesn't support sleep modes during enumeration and that > after set configuration it works? > Hi, There is a super-speed device capability descriptor. What values does the WD HDD say it supports? Currently FreeBSD does not use these values and assume that all devices are working below the programmed defaults. Hence this descriptor is part of the configuration descriptor, maybe sleep modes are not supported until the configuration is set, or maybe some firmware devs think so? --HPS