Hi Sarah,
I will resubmit the patch with these changes shortly.
On Fri, Aug 9, 2013 at 10:22 AM, Sarah Sharp
wrote:
> Hi Shawn,
>
> I noticed that the ChromeOS kernel tree is still using this particular
> patch, and thought it was probably time to revisit it.
>
> On Sat, May 25, 2013 at 09:57:57
Hi Shawn,
I noticed that the ChromeOS kernel tree is still using this particular
patch, and thought it was probably time to revisit it.
On Sat, May 25, 2013 at 09:57:57AM -0700, Shawn Nematbakhsh wrote:
> Hi Sarah and Alan,
>
> Thanks for the comments. I will make the following revisions:
>
> 1
On Wednesday 29 May 2013 16:32:38 Don Zickus wrote:
> On Wed, May 29, 2013 at 12:38:28PM -0700, Sarah Sharp wrote:
> > On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
> > > The policy we want to achieve is to disable runtime PM iff there is a
> > > device connected that doesn't have
On Wed, May 29, 2013 at 12:38:28PM -0700, Sarah Sharp wrote:
> On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
> > The policy we want to achieve is to disable runtime PM iff there is a
> > device connected that doesn't have persist_enabled or a reset_resume()
> > handler and whose pa
On Wed, 29 May 2013, Sarah Sharp wrote:
> On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
> > The policy we want to achieve is to disable runtime PM iff there is a
> > device connected that doesn't have persist_enabled or a reset_resume()
> > handler and whose parent/root hub resets
On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
> The policy we want to achieve is to disable runtime PM iff there is a
> device connected that doesn't have persist_enabled or a reset_resume()
> handler and whose parent/root hub resets on resume, right?
Makes sense. However, not al
On Tue, 28 May 2013, Julius Werner wrote:
> The policy we want to achieve is to disable runtime PM iff there is a
> device connected that doesn't have persist_enabled or a reset_resume()
> handler and whose parent/root hub resets on resume, right? So couldn't
Probably just root hub, not parent.
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have persist_enabled or a reset_resume()
handler and whose parent/root hub resets on resume, right? So couldn't
we remove the HCD-specific XHCI_RESET_ON_RESUME and set the (existing)
generic USB_QUIR
On Sat, May 25, 2013 at 09:57:57AM -0700, Shawn Nematbakhsh wrote:
> Hi Sarah and Alan,
>
> Thanks for the comments. I will make the following revisions:
>
> 1. Call pm_runtime_get_noresume only when the first device is connected,
> and call pm_runtime_put when the last device is disconnected.
>
Hi Sarah and Alan,
Thanks for the comments. I will make the following revisions:
1. Call pm_runtime_get_noresume only when the first device is
connected, and call pm_runtime_put when the last device is
disconnected.
2. Wrap the calls in an ifdef CONFIG_USB_DEFAULT_PERSIST.
3. Make sure that all p
On Fri, 24 May 2013, Sarah Sharp wrote:
> On Fri, May 24, 2013 at 11:12:57AM -0700, Shawn Nematbakhsh wrote:
> > If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
> > a reset will be performed upon runtime resume. Any previously suspended
> > devices attached to the controller
On Fri, May 24, 2013 at 11:12:57AM -0700, Shawn Nematbakhsh wrote:
> If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
> a reset will be performed upon runtime resume. Any previously suspended
> devices attached to the controller will be re-enumerated at this time.
> This will
If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will cause problems, for example, if an open system call on the
device triggered
13 matches
Mail list logo
