[ adding Greg to the cc as a ping and in case he was curious of the
current review state of this patchset ]
On Thu, May 15, 2014 at 12:41 PM, Dan Williams wrote:
> On Mon, 2014-05-12 at 15:14 -0400, Alan Stern wrote:
>> On Mon, 12 May 2014, Dan Williams wrote:
>>
>> > Fixed. And dropped "wakeup"
On Mon, 2014-05-12 at 15:14 -0400, Alan Stern wrote:
> On Mon, 12 May 2014, Dan Williams wrote:
>
> > Fixed. And dropped "wakeup" out of the patch subject.
> >
> > > There's a nasty bug here. I'll let you figure it out for yourself. :-)
> > > Hint: Hiding a variable by declaring another local
On Mon, 12 May 2014, Dan Williams wrote:
> Fixed. And dropped "wakeup" out of the patch subject.
>
> > There's a nasty bug here. I'll let you figure it out for yourself. :-)
> > Hint: Hiding a variable by declaring another local variable with the
> > same name in an inner block often leads to
On Mon, 2014-05-12 at 10:22 -0400, Alan Stern wrote:
> On Fri, 9 May 2014, Dan Williams wrote:
>
> > Testing looks good. In my objection to this approach I neglected to
> > consider that the port_status_lock now protects us from port_event()
> > usb_port_{suspend_resume} collisions. I have updat
On Mon, May 12, 2014 at 7:22 AM, Alan Stern wrote:
> On Fri, 9 May 2014, Dan Williams wrote:
>
>> Testing looks good. In my objection to this approach I neglected to
>> consider that the port_status_lock now protects us from port_event()
>> usb_port_{suspend_resume} collisions. I have updated th
On Fri, 9 May 2014, Dan Williams wrote:
> Testing looks good. In my objection to this approach I neglected to
> consider that the port_status_lock now protects us from port_event()
> usb_port_{suspend_resume} collisions. I have updated the changelog
> accordingly.
>
> 8<---
> Subject: u
On Thu, 2014-05-08 at 15:14 -0400, Alan Stern wrote:
> On Thu, 8 May 2014, Dan Williams wrote:
>
> > On Thu, May 8, 2014 at 11:09 AM, Alan Stern
> > wrote:
> > > On Thu, 8 May 2014, Dan Williams wrote:
> > >
> > >> On Thu, May 8, 2014 at 9:09 AM, Alan Stern
> > >> wrote:
> > >> > On Thu, 8 May
On Thursday, May 08, 2014 08:56:24 AM Dan Williams wrote:
> On Thu, May 8, 2014 at 4:09 AM, Rafael J. Wysocki wrote:
> > On Wednesday, May 07, 2014 10:37:24 PM Dan Williams wrote:
> >> Unconditionally wake up the child device when the power session is
> >> recovered.
> >
> > [cut]
> >
> >> +
On Thu, 8 May 2014, Dan Williams wrote:
> On Thu, May 8, 2014 at 11:09 AM, Alan Stern wrote:
> > On Thu, 8 May 2014, Dan Williams wrote:
> >
> >> On Thu, May 8, 2014 at 9:09 AM, Alan Stern
> >> wrote:
> >> > On Thu, 8 May 2014, Dan Williams wrote:
> >> >
> >> >> > I don't understand this last p
On Thu, May 8, 2014 at 11:09 AM, Alan Stern wrote:
> On Thu, 8 May 2014, Dan Williams wrote:
>
>> On Thu, May 8, 2014 at 9:09 AM, Alan Stern wrote:
>> > On Thu, 8 May 2014, Dan Williams wrote:
>> >
>> >> > I don't understand this last part. Why do we need to guarantee the
>> >> > child device ha
On Thu, 8 May 2014, Dan Williams wrote:
> On Thu, May 8, 2014 at 9:09 AM, Alan Stern wrote:
> > On Thu, 8 May 2014, Dan Williams wrote:
> >
> >> > I don't understand this last part. Why do we need to guarantee the
> >> > child device has recovered from power loss? Why not proceed the same
> >>
On Thu, May 8, 2014 at 9:09 AM, Alan Stern wrote:
> On Thu, 8 May 2014, Dan Williams wrote:
>
>> > I don't understand this last part. Why do we need to guarantee the
>> > child device has recovered from power loss? Why not proceed the same
>> > way we do now when the child is suspended?
>>
>> Tw
On Thu, 8 May 2014, Dan Williams wrote:
> > I don't understand this last part. Why do we need to guarantee the
> > child device has recovered from power loss? Why not proceed the same
> > way we do now when the child is suspended?
>
> Two reasons I believe:
>
> 1/ The child may be gone, and us
On Thu, May 8, 2014 at 8:44 AM, Alan Stern wrote:
> On Wed, 7 May 2014, Dan Williams wrote:
>
>> Unconditionally wake up the child device when the power session is
>> recovered.
>
> ...
>
>> 1, 2, and 4 are not a problem in the system dpm_resume() case because,
>> although the power-session is los
On Thu, May 8, 2014 at 4:09 AM, Rafael J. Wysocki wrote:
> On Wednesday, May 07, 2014 10:37:24 PM Dan Williams wrote:
>> Unconditionally wake up the child device when the power session is
>> recovered.
>
> [cut]
>
>> + /*
>> + * Revalidate t
On Wed, 7 May 2014, Dan Williams wrote:
> Unconditionally wake up the child device when the power session is
> recovered.
...
> 1, 2, and 4 are not a problem in the system dpm_resume() case because,
> although the power-session is lost, khubd is frozen until after device
> resume. For the rpm_r
On Wednesday, May 07, 2014 10:37:24 PM Dan Williams wrote:
> Unconditionally wake up the child device when the power session is
> recovered.
[cut]
> + /*
> + * Revalidate the device if it was requested by
> + *
Unconditionally wake up the child device when the power session is
recovered.
This address the following scenarios:
1/ The device may need a reset on power-session loss, without this
change port power-on recovery exposes khubd to scenarios that
usb_port_resume() is set to handle. Prior to
18 matches
Mail list logo
