On Fri, Dec 13, 2013 at 10:00:28AM -0800, David Cohen wrote:
> Hi Sarah,
>
> On Fri, Dec 13, 2013 at 09:48:15AM -0800, Sarah Sharp wrote:
> > On Thu, Dec 12, 2013 at 11:05:04AM -0500, Alan Stern wrote:
> > > On Wed, 11 Dec 2013, Julius Werner wrote:
> > >
> > > > >> ...although, the spec says tha
On Fri, Dec 13, 2013 at 10:15 AM, Alan Stern wrote:
> On Fri, 13 Dec 2013, Dan Williams wrote:
>
>> > I'm actually leaning towards enabling the check for warm reset broadly.
>> > It seems like it wouldn't hurt to issue a warm reset on the USB 3.0
>> > ports if they're in compliance, poll, or rx.de
On Fri, 13 Dec 2013, Dan Williams wrote:
> > I'm actually leaning towards enabling the check for warm reset broadly.
> > It seems like it wouldn't hurt to issue a warm reset on the USB 3.0
> > ports if they're in compliance, poll, or rx.detect. So, let's enable
> > this broadly in xhci_resume, ma
On Fri, Dec 13, 2013 at 9:48 AM, Sarah Sharp
wrote:
> On Thu, Dec 12, 2013 at 11:05:04AM -0500, Alan Stern wrote:
>> On Wed, 11 Dec 2013, Julius Werner wrote:
>>
>> > >> ...although, the spec says that it does not wait for the port resets
>> > >> to complete. As far as I can see re-issuing a warm
Hi Sarah,
On Fri, Dec 13, 2013 at 09:48:15AM -0800, Sarah Sharp wrote:
> On Thu, Dec 12, 2013 at 11:05:04AM -0500, Alan Stern wrote:
> > On Wed, 11 Dec 2013, Julius Werner wrote:
> >
> > > >> ...although, the spec says that it does not wait for the port resets
> > > >> to complete. As far as I c
On Thu, Dec 12, 2013 at 11:05:04AM -0500, Alan Stern wrote:
> On Wed, 11 Dec 2013, Julius Werner wrote:
>
> > >> ...although, the spec says that it does not wait for the port resets
> > >> to complete. As far as I can see re-issuing a warm reset and waiting
> > >> is the only way to guarantee the
On Wed, 11 Dec 2013, Julius Werner wrote:
> >> ...although, the spec says that it does not wait for the port resets
> >> to complete. As far as I can see re-issuing a warm reset and waiting
> >> is the only way to guarantee the core times the recovery. Presumably
> >> the portstatus debounce in
>> ...although, the spec says that it does not wait for the port resets
>> to complete. As far as I can see re-issuing a warm reset and waiting
>> is the only way to guarantee the core times the recovery. Presumably
>> the portstatus debounce in hub_activate() mitigates this, but that
>> 100ms is
On Wed, Dec 11, 2013 at 2:51 PM, Dan Williams wrote:
> On Wed, Dec 11, 2013 at 11:36 AM, Sarah Sharp
> wrote:
>> On Wed, Dec 11, 2013 at 11:00:13AM -0800, Julius Werner wrote:
>>> > I don't know what you mean by "fails". The system goes to sleep and
>>> > then later on wakes up, doesn't it?
>>>
On Wed, Dec 11, 2013 at 11:36 AM, Sarah Sharp
wrote:
> On Wed, Dec 11, 2013 at 11:00:13AM -0800, Julius Werner wrote:
>> > I don't know what you mean by "fails". The system goes to sleep and
>> > then later on wakes up, doesn't it?
>> >
>> > Do you mean that the Jetflash device gets disconnected
On Wed, Dec 11, 2013 at 11:00:13AM -0800, Julius Werner wrote:
> > I don't know what you mean by "fails". The system goes to sleep and
> > then later on wakes up, doesn't it?
> >
> > Do you mean that the Jetflash device gets disconnected when the system
> > wakes up? That's _supposed_ to happen u
> I don't know what you mean by "fails". The system goes to sleep and
> then later on wakes up, doesn't it?
>
> Do you mean that the Jetflash device gets disconnected when the system
> wakes up? That's _supposed_ to happen under those circumstances.
> When hub_activate() sees HUB_RESET_RESUME, al
On Tue, 10 Dec 2013, Vikas Sajjan wrote:
> > Finally, I don't see why you put this in hub_activate(). Isn't it more
> > closely connected with the reset-resume procedure for the child device?
>
>
> I was trying to add a FIX in usb_port_resume(), but in our case we
> have CONFIG_USB_DEFAULT_PERS
Hi Alan,
On Mon, Dec 9, 2013 at 8:54 PM, Alan Stern wrote:
> On Mon, 9 Dec 2013, Vikas Sajjan wrote:
>
>> Does warm reset while activating SuperSpeed HUBs if the hub activate type
>> is HUB_RESET_RESUME.
>>
>> When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend
>> USB 3.
Hi Sarah,
On Mon, Dec 9, 2013 at 11:54 PM, Sarah Sharp
wrote:
> On Mon, Dec 09, 2013 at 10:24:52AM -0500, Alan Stern wrote:
>> On Mon, 9 Dec 2013, Vikas Sajjan wrote:
>>
>> > Does warm reset while activating SuperSpeed HUBs if the hub activate type
>> > is HUB_RESET_RESUME.
>> >
>> > When we do S
On Mon, Dec 09, 2013 at 10:24:52AM -0500, Alan Stern wrote:
> On Mon, 9 Dec 2013, Vikas Sajjan wrote:
>
> > Does warm reset while activating SuperSpeed HUBs if the hub activate type
> > is HUB_RESET_RESUME.
> >
> > When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash)
> > transcend
On Mon, 9 Dec 2013, Vikas Sajjan wrote:
> Does warm reset while activating SuperSpeed HUBs if the hub activate type
> is HUB_RESET_RESUME.
>
> When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend
> USB 3.0 device connected on 3.0 port, during resume I noticed that the
> X
Hi Vikas,
On Mon, Dec 9, 2013 at 5:59 PM, Vikas Sajjan wrote:
few minor nits here. ;-)
> Does warm reset while activating SuperSpeed HUBs if the hub activate type
> is HUB_RESET_RESUME.
>
> When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend
> USB 3.0 device connected
Does warm reset while activating SuperSpeed HUBs if the hub activate type
is HUB_RESET_RESUME.
When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend
USB 3.0 device connected on 3.0 port, during resume I noticed that the
XHCI controller has moved to sometimes RECOVERY, POLLI
19 matches
Mail list logo
