On Fri, May 2, 2014 at 12:09 PM, Alan Stern wrote:
> On Thu, 1 May 2014, Dan Williams wrote:
>
>> I've been testing this and the pm_request_resume() ends up leaving the
>> usb device enabled indefinitely. It needs to be paired with a
>> pm_runtime_autosuspend(), but at that point why not just add
On Thu, 1 May 2014, Dan Williams wrote:
> I've been testing this and the pm_request_resume() ends up leaving the
> usb device enabled indefinitely. It needs to be paired with a
> pm_runtime_autosuspend(), but at that point why not just add a
> usb_autoresume_device_async() helper.
Why didn't pm_
On Thu, 1 May 2014, Dan Williams wrote:
> On Mon, Apr 28, 2014 at 1:29 PM, Alan Stern wrote:
> > On Wed, 19 Mar 2014, Dan Williams wrote:
> [..]
> >> --- a/drivers/usb/core/port.c
> >> +++ b/drivers/usb/core/port.c
> >> @@ -104,6 +104,8 @@ static int usb_port_runtime_resume(struct device *dev)
>
On Mon, Apr 28, 2014 at 1:29 PM, Alan Stern wrote:
> On Wed, 19 Mar 2014, Dan Williams wrote:
[..]
>> --- a/drivers/usb/core/port.c
>> +++ b/drivers/usb/core/port.c
>> @@ -104,6 +104,8 @@ static int usb_port_runtime_resume(struct device *dev)
>> if (retval < 0)
>>
On Tue, Apr 29, 2014 at 8:12 AM, Alan Stern wrote:
> On Mon, 28 Apr 2014, Dan Williams wrote:
>> ...and as I go to add this I notice that prior to the "use
>> pm_request_resume" suggestion we don't de-reference port_dev->child in
>> usb_port_runtime_resume(). This realization plus the usage count
On Thu, 1 May 2014, Dan Williams wrote:
> > I'll throw this at the front of my series when resubmitting.
>
> Whoops, this patch is missing its own "Subject:".
Call it: "USB: mutual exclusion for resetting a hub and power-managing
a port".
Alan Stern
--
To unsubscribe from this list: send the l
On Thu, May 1, 2014 at 12:09 PM, Dan Williams wrote:
> On Thu, May 1, 2014 at 12:02 PM, Alan Stern wrote:
>> On Thu, 1 May 2014, Dan Williams wrote:
>>
>>> > @@ -122,6 +127,11 @@ static int usb_port_runtime_suspend(stru
>>> > == PM_QOS_FLAGS_ALL)
>>> > retu
On Thu, May 1, 2014 at 12:02 PM, Alan Stern wrote:
> On Thu, 1 May 2014, Dan Williams wrote:
>
>> > @@ -122,6 +127,11 @@ static int usb_port_runtime_suspend(stru
>> > == PM_QOS_FLAGS_ALL)
>> > return -EAGAIN;
>> >
>> > + if (hub->in_reset) {
>> > +
On Thu, 1 May 2014, Dan Williams wrote:
> > @@ -122,6 +127,11 @@ static int usb_port_runtime_suspend(stru
> > == PM_QOS_FLAGS_ALL)
> > return -EAGAIN;
> >
> > + if (hub->in_reset) {
> > + port_dev->power_is_on = 0;
> > + ret
On Wed, 30 Apr 2014, Dan Williams wrote:
> > I'm kind of doubtful about this. Remember, if the hub is being reset
> > then it probably isn't working correctly. There's a good chance that
> > asking it to change a port's power level will fail.
> >
> > It would be better if the port suspend and
On Wed, 2014-04-30 at 15:51 -0400, Alan Stern wrote:
> On Wed, 30 Apr 2014, Dan Williams wrote:
>
> > On Wed, 2014-04-30 at 10:04 -0400, Alan Stern wrote:
> > > On Tue, 29 Apr 2014, Dan Williams wrote:
> > >
> > > > > What happens if a thread tries to resume or suspend a port while the
> > > > >
On Wed, 30 Apr 2014, Dan Williams wrote:
> On Wed, 2014-04-30 at 10:04 -0400, Alan Stern wrote:
> > On Tue, 29 Apr 2014, Dan Williams wrote:
> >
> > > > What happens if a thread tries to resume or suspend a port while the
> > > > hub is being reset? With nothing to prevent it, the request sent t
On Wed, 2014-04-30 at 10:04 -0400, Alan Stern wrote:
> On Tue, 29 Apr 2014, Dan Williams wrote:
>
> > > What happens if a thread tries to resume or suspend a port while the
> > > hub is being reset? With nothing to prevent it, the request sent to
> > > the hub will fail and the port may end up in
On Tue, 29 Apr 2014, Dan Williams wrote:
> > What happens if a thread tries to resume or suspend a port while the
> > hub is being reset? With nothing to prevent it, the request sent to
> > the hub will fail and the port may end up in a runtime PM error state.
> >
>
> I'm expected to be protecte
On Tue, Apr 29, 2014 at 12:25 PM, Alan Stern wrote:
> On Tue, 29 Apr 2014, Dan Williams wrote:
>
>> > However, either way we still have bad interactions between
>> > hub_{quiesce|activate}() and usb_port_runtime_{suspend|resume}().
>> > Consider, for example, what happens to the ports' power state
On Tue, 29 Apr 2014, Dan Williams wrote:
> > However, either way we still have bad interactions between
> > hub_{quiesce|activate}() and usb_port_runtime_{suspend|resume}().
> > Consider, for example, what happens to the ports' power states when the
> > hub is reset.
> >
>
> You mean in terms of
On Tue, Apr 29, 2014 at 8:12 AM, Alan Stern wrote:
> On Mon, 28 Apr 2014, Dan Williams wrote:
>
>> > Can you include a brief description of situations in which this would
>> > be needed, i.e., when something would runtime-resume the port without
>> > also resuming the child device? Testing, sure,
On Mon, 28 Apr 2014, Dan Williams wrote:
> > Can you include a brief description of situations in which this would
> > be needed, i.e., when something would runtime-resume the port without
> > also resuming the child device? Testing, sure, but not much else comes
> > to mind.
>
> I guess it coul
On Mon, Apr 28, 2014 at 2:00 PM, Dan Williams wrote:
> On Mon, Apr 28, 2014 at 1:29 PM, Alan Stern wrote:
>> On Wed, 19 Mar 2014, Dan Williams wrote:
[..]
>> But this got me thinking... It looks like the reference to
>> port_dev->child in usb_port_runtime_resume() already races with the
>> line
On Mon, Apr 28, 2014 at 1:29 PM, Alan Stern wrote:
> On Wed, 19 Mar 2014, Dan Williams wrote:
>
>> 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
>
On Wed, 19 Mar 2014, Dan Williams wrote:
> 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 scenario
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
22 matches
Mail list logo
