On Thu, Dec 07, 2017 at 01:26:14AM -0800, Alexander Kappner wrote:
> Date: Wed, 6 Dec 2017 15:28:37 -0800
> Subject: [PATCH] usb-core: Fix potential null pointer dereference in
> xhci-debugfs.c
Something went wrong here, resulting in an email with no subject.
Can you fix this up and resend?
tha
On Thu, 13 Nov 2014, Sebastian Andrzej Siewior wrote:
> On 11/07/2014 07:53 PM, Alan Stern wrote:
> >> If I put pm_runtime_get_sync() + put in musb_resume() then the problem
> >> is gone. I don't see ehci-hcd doing this in resume, in fact I don't see
> >> ehci doing pm_runtime_* at all. So for ehc
On 11/07/2014 07:53 PM, Alan Stern wrote:
>> If I put pm_runtime_get_sync() + put in musb_resume() then the problem
>> is gone. I don't see ehci-hcd doing this in resume, in fact I don't see
>> ehci doing pm_runtime_* at all. So for ehci the device is probably
>> always RPM_ACTIVE.
>
> No, it does
On Fri, 7 Nov 2014, Sebastian Andrzej Siewior wrote:
> > Ah. In usb_resume(), what happened after usb_resume_both() returned?
> > The code says this:
> >
> > status = usb_resume_both(udev, msg);
> > if (status == 0) {
> > pm_runtime_disable(dev);
> > pm_runtime_
On Fri, Nov 07, 2014 at 07:03:27PM +0100, Sebastian Andrzej Siewior wrote:
> On 11/07/2014 06:58 PM, Felipe Balbi wrote:
> >> If I put pm_runtime_get_sync() + put in musb_resume() then the problem
> >
> > shouldn't you have:
> >
> > pm_runtime_disable(dev);
> > pm_runtime_set_active(dev);
On 11/07/2014 06:58 PM, Felipe Balbi wrote:
>> If I put pm_runtime_get_sync() + put in musb_resume() then the problem
>
> shouldn't you have:
>
> pm_runtime_disable(dev);
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
>
> in musb_resume() ?
that might be correct, I am
On Fri, Nov 07, 2014 at 06:54:21PM +0100, Sebastian Andrzej Siewior wrote:
> On 11/06/2014 08:16 PM, Alan Stern wrote:
> >> --- now get back out of suspend ---
> >> - usb_resume() is invoked with different RPM status.
> >> - hub_activate() is invoked. The status URB is enqueued again, RPM
> >> re
On 11/06/2014 08:16 PM, Alan Stern wrote:
>> --- now get back out of suspend ---
>> - usb_resume() is invoked with different RPM status.
>> - hub_activate() is invoked. The status URB is enqueued again, RPM
>> remains unchanged.
>> - and we are done
>
> Ah. In usb_resume(), what happened af
On Wed, 5 Nov 2014, Sebastian Andrzej Siewior wrote:
> On 11/04/2014 08:10 PM, Alan Stern wrote:
> > Now, maybe something went wrong somewhere. Perhaps the kernel thought
> > that after the system resume, the root hub was still in runtime
> > suspend. If that's true, we need to find out why an
On 11/04/2014 08:10 PM, Alan Stern wrote:
> Now, maybe something went wrong somewhere. Perhaps the kernel thought
> that after the system resume, the root hub was still in runtime
> suspend. If that's true, we need to find out why and fix it.
This is what I have so far (I have no idea what is
On Tue, 4 Nov 2014, Sebastian Andrzej Siewior wrote:
> I have two musb instances running in OTG. One instance is in device mode,
> the other in host mode. I enable remote wakeup for both ports
> (echo 1 > /sys/…/power/wakeup). On leaving suspend I see that the root-hub
> is resumed twice. I added
On Mon, 1 Jul 2013, Devin Heitmueller wrote:
> Hi all,
>
> I've been doing some debugging of a video corruption problem in the
> em28xx video capture driver, and after a couple of weeks of digging
> in, I think I might have exposed some sort race condition in the USB
> core.
>
> http://devinheit
12 matches
Mail list logo
