On Wed, 14 Sep 2016, Arun Thiruvanantha wrote:
> Hi Alan ,
> We are using linux kernel 2.6.32 version
That's a very old kernel release. A lot of bugs have been fixed since
it came out.
Can you try using a more recent version, like 4.7? It will make
debugging a lot easier.
Alan S
gt; [182058.640944] xhci_hcd :02:00.0: init :02:00.0 fail, -110
> >> [182058.640947] xhci_hcd: probe of :02:00.0 failed with error -110
> >>
> >> can not see my flash inserted into the USB
> >>
> >> echo -n 'module xhci_hcd =p' >
On Wed, 14 Sep 2016, c400 wrote:
> yep! enabling You need to enable CONFIG_DYNAMIC_DEBUG. did the trick!
> here is my new dmesg output:
Did you use the 32-bit DMA quirks option for xhci_hcd?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb"
ng the xhci-pci and xhci-hcd modules:
sudo modprobe xhci_hcd quirks=0x00800090
sudo modprobe xhci_pci
Nobody here can help you if you don't pay attention to what we say.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb&q
ts, although perhaps just removing that line would be worth a
> try!?
No, the realtek_cr driver has no connection with this. It's a
sub-module of the usb_storage driver; it uses the SCSI interface,
not the MMC interface.
> If neither of the above works, the next step could be to start
46c port reserved reg = 0x0
> [ 90.143525] xhci_hcd :02:00.0: QUIRK: Resetting on resume
> [ 90.143527] xhci_hcd :02:00.0: // Halt the HC
> [ 90.166739] xhci_hcd :02:00.0: Host not halted after 16000
> microseconds.
> [ 90.166741] xhci_hcd :02:00.0: can't se
On Sat, 10 Sep 2016, Wade Berrier wrote:
> On Thu Aug 11 16:18, Alan Stern wrote:
> > I never received any replies to this message. Should the patch I
> > suggested be merged?
> >
>
> Hello,
>
> I applied this updated patch to the fedora23 4.7.2 kernel and
fo/?l=mythtv-users&m=144131333703197&w=2
You should a check for ep_out to the probe routine.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
an 32 ms.
Signed-off-by: Alan Stern
Tested-by: Wade Berrier
CC:
---
[as1812]
drivers/usb/core/config.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
Index: usb-4.x/drivers/usb/core/con
On Thu, 15 Sep 2016, Wade Berrier wrote:
> On Thu Sep 15 15:13, Alan Stern wrote:
> > On Sat, 10 Sep 2016, Wade Berrier wrote:
> >
> > > On Thu Aug 11 16:18, Alan Stern wrote:
> > > > I never received any replies to this message. Should the
On Fri, 16 Sep 2016, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hello Ulf and Alan,
>
> On Thu, 2016-09-15 at 10:16 -0400, Alan Stern wrote:
> > > ---
> > > drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++
> > > 1 fi
On Sat, 17 Sep 2016, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hello Alan,
>
>
> On Fri, 2016-09-16 at 17:40 -0400, Alan Stern wrote:
> > We're still getting runtime suspends, but now at 2-second intervals.
> > T
suspend for the sdmmc device.
The second approach would also prevent the sdmmc device from going into
autosuspend as soon as the LED update is finished. Maybe that's okay,
but if going into suspend is a lightweight procedure then you may want
to prevent it.
Alan Stern
--
To unsubscribe from th
t; $ grep -RnH "raise_exception\|fsg_main_thread" /tmp/trace.txt
> /tmp/trace.txt:111743: irq/17-dwc3-3527 [003] d..164.833078:
> raise_exception: raise_exception 4
> /tmp/trace.txt:111745:file-storage-3526 [002] 64.833139:
> fsg_main_thread: get_next_co
On Mon, 19 Sep 2016, Ulf Hansson wrote:
> On 18 September 2016 at 03:42, Alan Stern wrote:
> > Well, this is pretty clear:
> >
> > Sep 17 15:55:52 learner kernel: CPU: 1 PID: 535 Comm: rtsx_usb_ms_1
> > Tainted: G U 4.8.0-rc6ulf1alan1+ #19
> &g
On Mon, 19 Sep 2016, Ulf Hansson wrote:
> On 18 September 2016 at 04:30, Alan Stern wrote:
> > On Sat, 17 Sep 2016, Ulf Hansson wrote:
> >
> >> Each access of the parent device (usb device) needs to be done in runtime
> >> resumed state. Currently this isn&#
control the polling interval (or
disable it entirely). But I don't know how the MMC stack interacts
with the block layer.
One awkward point is that the sdmmc and memstick drivers each do their
own polling. This is a waste. You can see it in the usbmon trace;
every second there are two
On Tue, 20 Sep 2016, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Mon, 2016-09-19 at 13:48 -0400, Alan Stern wrote:
> >
> > This ought to help. Ritesh, please apply this patch on top of the
> > two earlier ones and let
On Tue, 20 Sep 2016, Oliver Neukum wrote:
> On Mon, 2016-09-19 at 14:02 -0400, Alan Stern wrote:
> > > We can for sure enable autosuspend for the sdmmc device, although as
> > > soon as an SD card will be detected the rtsx driver will increase
> > the
> > >
read did start running
and get_next_command should have returned.
The trace you posted after this one doesn't seem to show anything new,
as far as I can tell.
So I still can't tell what's happening. Maybe the patch below will
help. It concentrates on the critical area.
Alan Stern
oblem has been there all along, but it simply wasn't
reported until commit 71723f95463d ("PM / runtime: print error when
activating a child to unactive parent") was merged in 4.8-rc1.
Does this patch get rid of the error message?
Alan Stern
Index: usb-4.x/drivers/usb/storage/
On Tue, 20 Sep 2016, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hello Alan,
>
> On Tue, 2016-09-20 at 10:16 -0400, Alan Stern wrote:
> > This is a lot better. No more I/O errors.
> >
> > We still have irregular su
On Tue, 20 Sep 2016, Carsten Mattner wrote:
> On Tue, Sep 20, 2016 at 5:41 PM, Alan Stern wrote:
>
> > I suspect the problem has been there all along, but it simply wasn't
> > reported until commit 71723f95463d ("PM / runtime: print error when
> > activatin
On Wed, 21 Sep 2016, Oliver Neukum wrote:
> On Tue, 2016-09-20 at 10:12 -0400, Alan Stern wrote:
> > On Tue, 20 Sep 2016, Oliver Neukum wrote:
>
> > That shouldn't be an issue in this case, at least, not with the current
> > code. The sdmmc and memstick drivers
On Wed, 21 Sep 2016, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi Alan,
>
> On Tue, 2016-09-20 at 10:16 -0400, Alan Stern wrote:
> > This is a lot better. No more I/O errors.
> >
> > We still have irregular su
gt; > synchronize the polls so that the device doesn't need to be resumed
> > twice every second.
>
> Yes, you are right. I just haven't been able to prioritize doing that
> change for MMC. Another thing added on my mmc TODO list. :-)
To tell the truth, I'm not sure h
Can you post the "lspci -v -s 2:00" output? Maybe the
XHCI_NO_64BIT_SUPPORT quirk flag should be set for all controllers of
this sort.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
On Tue, 20 Sep 2016, Carsten Mattner wrote:
> On Tue, Sep 20, 2016 at 9:49 PM, Alan Stern wrote:
> > On Tue, 20 Sep 2016, Carsten Mattner wrote:
> >
> > > On Tue, Sep 20, 2016 at 5:41 PM, Alan Stern
> > > wrote:
> > >
> > > > I suspect the
ng call to
usb_autopm_get_interface_no_resume() up from its current position to
before scsi_add_host() is called.
Signed-off-by: Alan Stern
Reported-by: Carsten Mattner
Tested-by: Carsten Mattner
CC:
---
[as1813]
drivers/usb/storage/usb.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Inde
On Wed, 21 Sep 2016, Greg KH wrote:
> On Wed, Sep 21, 2016 at 11:25:37AM -0400, Alan Stern wrote:
> > A warning message that was recently added to the PM core has alerted
> > us to a potential problem in usb-storage. Although the USB interface
> > is in the runtime active
ns when a
> device is no longer required to be runtime resumed. As when a driver
> has completed to serve a request and is about to call pm_runtime_put()
> (or similar API).
>
> So, I still believe doing it in the runtime PM core is just a waste.
>
> I think it's better to
On Thu, 22 Sep 2016, Oliver Neukum wrote:
> On Wed, 2016-09-21 at 10:35 -0400, Alan Stern wrote:
> > On Wed, 21 Sep 2016, Oliver Neukum wrote:
>
> > > Yes, but this is not the point. A heuristic with a timeout makes
> > > sense only if the uses are unpredic
ectors set to 240. However, you can
change the value if you want. Read the usb-storage.quirks section in
Documentation/kernel-parameters.txt; the m flag will set max_sectors to
64.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a
On Wed, 28 Sep 2016, Felipe Balbi wrote:
> We have introduced a helper to calculate multiplier
> value from wMaxPacketSize. Start using it.
>
> Cc: Alan Stern
> Cc:
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/host/ehci-sched.c | 2 +-
> 1 file changed,
new usb_endpoint_maxp_mult()
>
> We have introduced a helper to calculate multiplier
> value from wMaxPacketSize. Start using it.
>
> Cc: Alan Stern
> Cc:
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/host/ehci-q.c | 10 ++
> drivers/usb/host/ehci-sc
e on the stack */
> + memcpy(ldev->buf, buf, ldev->config->report_size);
In fact, this is not the best way to solve the problem. Not only must
the buffer be dynamically allocated, it also must not be part of a
larger structure (such as struct hidled_device).
Instead you should c
> Probably, _S0W, _DSM and XFLT code for xHCI are useless in that ACPI DSDT
> firmware version.
>
> But we still want the driver to handle cases like this.
> Just wrote the patch.
> Adding Alan Stern to CC for PM sanity feedback on it:
>
> ---
>
> Author: Mathias Nyma
checked all the completion routines in all the USB
drivers to make sure they don't make this mistake.
Alan Stern
> Signed-off-by: Bin Liu
> ---
> v2: fix build warning
>
> drivers/usb/core/hcd.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --gi
prefer to avoid suspending the controller at all,
rather than have it go into runtime suspend and then stop working.
On Wed, 5 Oct 2016, Mathias Nyman wrote:
> On 04.10.2016 17:11, Alan Stern wrote:
> > On Tue, 4 Oct 2016, Mathias Nyman wrote:
> >
> >> On 03.10.2016 23:54,
On Wed, 5 Oct 2016, Lukas Wunner wrote:
> On Wed, Oct 05, 2016 at 01:54:01PM -0500, Bjorn Helgaas wrote:
> > On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> > > In short, Pierre's USB host controller doesn't send wakeup signals from
> > > runtime
ill behave exactly the same as before, the only difference
being that the object image will not contain unused exynos_ehci_suspend
and exynos_ehci_resume routines. And the compiler won't issue a
warning at build time that the routines are unused.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
r the callers of pci_dev_run_wake() and the above
> seems safe but you should double-check them.
That seems like a good suggestion. The patch is below; Pierre, can you
test it? This should remove the need to set the USB auto
nably thorough instructions on how to build and install
your own version of their kernel.
Once you know how to do all that, I can tell you how the patch should
be applied -- that's the easy part.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the
> *pdev)
>
> device_remove_file(&dum->gadget.dev, &dev_attr_function);
> usb_del_gadget_udc(&dum->gadget);
> + memset(&dum->gadget, 0, sizeof(dum->gadget));
> return 0;
> }
Have you checked that no other parts of the dri
On Fri, 14 Oct 2016, Pierre de Villemereuil wrote:
> Hi!
>
> I've branched the kernel package on the OpenSUSE Build Server, I'll
> try to apply the patch there (this ought to be cleanest method).
>
> Starting from the root of the kernel tarball, the patch should be
> applied to drivers/pci/pci
might be okay -- I can't think of
any reason why a udc driver would need to call back into the composite
core while disabling an endpoint. It should be a pretty self-contained
operation.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
happy to provide more
> info.
Can you run git bisect between 4.7 and 4.8-rc1 to find the particular
commit that introduced this problem? There haven't been any
significant changes to the ohci-hcd driver during that period.
Alan Stern
--
To unsubscribe from this list: send the line &
nclude "pci-quirks.h"
Bryan, if you submit this patch (following the instructions in
Documentation/SubmittingPatches), I'll merge it into the kernel. Or if
you prefer not to, I can submit the patch myself, giving you the
appropriate credit.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hcd";
>
> #defineSTATECHANGE_DELAY msecs_to_jiffies(300)
> -#defineIO_WATCHDOG_DELAY msecs_to_jiffies(250)
> +#defineIO_WATCHDOG_DELAY msecs_to_jiffies(275)
>
> #include "ohci.h"
> #include "pci-quirks.h"
Acked
t
context, so it doesn't seem reasonable to require that endpoints be
disabled in process context.
f_mass_storage has its own worker thread. Mainly for other reasons,
but it can also use the thread to handle these events. But it doesn't
seem right to require all gadget drivers to do th
dmmc driver. This change should improve the boot
> > time
> > with ~100ms per rtsx_usb_sdmmc device.
> >
> > Finally, as I couldn't find an active maintainer for the memstick
> > subsystem/driver and because the author of the drivers can be reached, I
> > voluntee
>
> So we cannot set CONFIG_PM_SLEEP=n and CONFIG_PM=y
You have it backward. We cannot set CONFIG_PM_SLEEP=y and CONFIG_PM=n.
But you can have CONFIG_PM_SLEEP=n and CONFIG_PM=y.
Alan Stern
> I observed at many places were either CONFIG_PM or CONFIG_PM_SLEEP are used.
>
> So I would li
On Thu, 20 Oct 2016, Lukas Wunner wrote:
> On Tue, Oct 11, 2016 at 11:18:28AM -0400, Alan Stern wrote:
> > On Sat, 8 Oct 2016, Lukas Wunner wrote:
> > > The PCI core already calls pm_runtime_get_sync() before invoking the
> > > ->probe hook of a driver (see local_
(PORTSC.PLS=4'd15).
> + */
> + if (xhci->quirks & XHCI_PORT_RST_ON_RESUME) {
It's always a bad idea to drive a reset signal while a port is
resuming. We don't need a quirk flag for this. The HCD should never
do it, and
.
If the device relies on PME# for wakeup signals but is not capable of
generating PME# in the target state, the PCI core should accurately
report that it cannot do wakeup from runtime suspend. This patch
modifies the pci_dev_run_wake() routine to add this check.
Signed-off-by: Alan Stern
CC:
Alan Stern
CC:
---
Greg:
This patch is somewhat independent of the 1/2 patch I sent to Bjorn.
Still, it will help to keep them together. Is it okay to have him
merge both of them through his tree?
Alan Stern
[as1815]
drivers/usb/host/uhci-pci.c |4
1 file changed, 4 inser
;s a problem, there's no recovery attempt. So it's
> very noticeable when this happens.
I should think so! The whole point of the watchdog is to catch bad
hardware when it starts misbehaving. If that happens, we need to
cancel everything and kill the driver so that it doesn
On Sun, 23 Oct 2016, Lucas Stach wrote:
> This removes 10 timer wakeups per second. I'm running this patch for
> a while now and haven't spotted any adverse effects.
>
> Signed-off-by: Lucas Stach
> ---
> v2: Merge vendor AMD case with vendor Intel case, as requested
On Sun, 23 Oct 2016, Lucas Stach wrote:
> This merges the vendor NEC case with the INTEL and AMD one,
> as those 3 do exactly the same thing: disabling of the IO
> watchdog.
>
> Signed-off-by: Lucas Stach
> ---
> v2: New patch in v2.
Acked-by: Alan Stern
> ---
>
for yourself. In drivers/usb/core/hub.c, the
usb_reset_device() routine calls usb_autoresume_device() before calling
usb_reset_and_verify_device(). Therefore the port will have finished
resuming before the reset signal is sent.
Alan Stern
--
To unsubscribe from this list: send the line "unsub
.
>
> I'm not however able to test that part of the code since I don't have a USB-3
> device that would support remote wakeup. I'd like to get some feedback, or an
> ack from Alan about this approach before sending this patch forward.
I'll review the patch after
the PM usage
counter of a device before probing its interfaces.
Alan Stern
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/net/usb/usbnet.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> inde
On Thu, 3 Nov 2016 sonofa...@openmailbox.org wrote:
> Hello guys! Did you have any progress on this?
In a word: No.
> Do you still have the
> affected machine and devices?
I never had them in the first place.
Alan Stern
--
To unsubscribe from this list: send the line "unsubsc
to
> be able to detect cable connects or disconnects. But in RxDetect the
> connected device is detected again and eventually enabled.
>
> Instead set the link into U3 and disable remote wakeups for the device.
> This is what Windows does, and what Alan Stern suggested.
The general
-2: config 1 has an invalid interface number: 13 but max is
1
[3.862255] usb 2-2: config 1 has no interface number 0
[3.862256] usb 2-2: config 1 has no interface number 1
...
[8.295180] usb 2-2: Disable of device-initiated U1 failed.
[8.295322] usb 2-2: Disable of device-i
AK. alt->endpoint is deallocated in usb_release_interface_cache()
even if usb_parse_endpoint() fails.
Alan Stern
> ---
> drivers/usb/core/config.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
On Tue, 8 Nov 2016, Bjørn Mork wrote:
> Alan Stern writes:
>
> > On Tue, 8 Nov 2016, Kai-Heng Feng wrote:
> >
> >> Hi,
> >>
> >> On Mon, Nov 7, 2016 at 7:02 PM, Oliver Neukum wrote:
> >> > On Fri, 2016-11-04 at 17:57 +0800, Kai-Heng
subject and were not added to the
> original subject?
I don't know. What new subject are you referring to?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
device number 2
This is a known bug in the 4.8 kernel, caused by changes to the timer
code. A workaround and a proper fix have both been added to the 4.9-rc
series and will be part of the next 4.8.stable release.
Alan Stern
> on Ubuntu 16.04:
> [ 1168.662575] usb 7-4: new full-s
On Thu, 10 Nov 2016, Kai-Heng Feng wrote:
> Hi,
>
> On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote:
> > Oliver Neukum writes:
> >
> >> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
> >>
> >>> These problems could very well be cause
CI dumps would help with debugging this. I also don't
see why this issue would be at all connected with the fact that there
are two EHCI controllers on the chipset.
A usbmon trace of the affected bus might be more helpful.
Alan Stern
--
To unsubscribe from this list: send the line "u
us->ifnum, us->iobuf, srb->cmd_len);
>
> /* check the return code for the command */
> usb_stor_dbg(us, "Call to usb_stor_ctrl_transfer() returned %d\n",
Good work. Please submit an updated patch, following the format
described in Docume
ister+0x6c/0xc0
> [rtsx_usb]
> [36494.422147] []
> rtsx_usb_detect_ms_card+0x74/0x100 [rtsx_usb_ms]
> [36494.422149] [] ?
> rtsx_usb_ms_set_param+0x780/0x780 [rtsx_usb_ms]
There's a known bug in the rtsx_usb drivers in the 4.8 kernel. Try
running a 4.9-rc ke
rnel.release
> Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong
> not supported by compiler
> make: *** [prepare-compiler-check] Error 1
> make: *** Waiting for unfinished jobs
So turn off CONFIG_CC_STACKPROTECTOR_STRONG or upgrade your C compiler.
Alan Stern
--
d be fine,
> right now Canonical is shipping a version of gcc that doesn't want to
> build the kernel. There's a patch floating around, go bug the Canonical
> developers to get it upstream please...
>
> If not, I don't know, sorry.
Alternatively, you can try running a 4.8.7 or 4.8.8 kernel, if
Canonical supplies them. They contain the patches that fix the bugs in
rtsx_usb.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to
> be able to detect cable connects or disconnects. But in RxDetect the
> connected device is detected again and eventually enabled.
>
> Instead set the link into U3 and disable remote wakeups for the device.
> This is what Windows does, and what Alan Stern suggested.
>
> C
ding this. Kernel version 3.10 is seriously out of
date; you ought to consider upgrading. That message has been removed
in later kernel versions.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
> > warning:
>
> OK, the slowpath warning is a red herring -- it's just because I do the free
> under a spinlock, and I can fix that.
>
> There's still something that causes me to not get any frames, though.
What does usbmon show? (See Documentation/usb/usbmon.txt.)
vm_start + iter->size) {
if (uurb->buffer_length > iter->vm_start + iter->size -
uurb_start) {
usbm = ERR_PTR(-EINVAL);
} else {
us
On Sat, 5 Dec 2015, Steinar H. Gunderson wrote:
> On Sat, Dec 05, 2015 at 12:36:51PM -0500, Alan Stern wrote:
> > I meant that this "if" statement should test only uurb_start. If the
> > test succeeds, a nested "if" statement should test buffer_length and
&
as in Markus's patch.
> > As pointed out repeatedly by the kbuild test robot, this should be
> > IS_ERR, not IS_ERR_VALUE. Also, you need to set as->usbm back to NULL
> > before jumping.
> >
> > At this point, set num_sgs to 0 if as->usbm is non-NULL.
&g
ENOMEM;
> + goto error;
> + }
> }
>
> - if (!is_in) {
> + if (as->usbm) {
> + ; /* Transfer buffer is okay as it is */
> + } else if (!is_in) {
>
Michael:
Here at last is the final version of the patch, or something very close
to it. This should be applied on top of the other EHCI patches, but
not the quick-and-dirty fix, which it replaces.
Please test it and let me know the results.
Alan Stern
Index: usb-4.3/drivers/usb/host
/2-3.1.2/power.
For more information on what's happening, try collecting a usbmon trace
for bus 2 (see Documentation/usb/usbmon.txt).
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
pm_runtime_callbacks_present() above fail) for all interfaces, but
> I can't seem to find where that's undone. Alan, any hints ?
The USB subsystem treats runtime PM of interfaces differently from
runtime PM of devices. Josh should be monitoring the device, not the
interface.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
AULT;
> + isopkt = memdup_user(iso_frame_desc, isofrmlen);
> + if (IS_ERR(isopkt)) {
> + ret = PTR_ERR(isopkt);
> + isopkt = NULL;
> goto error;
> }
> for (totlen = u = 0; u <
nclude
> -
> -#include
> -#include
>
> #define USB_CONFIG_BASE 0x3102
> #define PWRMAN_BASE 0x40004000
If this still builds correctly, it's okay with me. I have no way to
test it.
Alan Stern
--
To unsubscribe from this list: send the lin
t that seems less likely. You could test it by
removing the dock and then connecting the mouse to the computer by way
of a USB-2.0 hub.
I don't have any other good suggestions for further debugging. You did
check the kernel log to see if anything unusual showed up, right?
About the only
On Mon, 7 Dec 2015, Steinar H. Gunderson wrote:
> On Mon, Dec 07, 2015 at 10:45:55AM -0500, Alan Stern wrote:
> >> Here we are. Lightly tested, I believe all comments should be addressed.
> > This looks quite good. I have only a couple of comments.
>
> Excellent. I'
On Tue, 8 Dec 2015, Steinar H. Gunderson wrote:
> On Tue, Dec 08, 2015 at 03:26:28PM -0500, Alan Stern wrote:
> > I just noticed this -- usbm->memlist needs to be initialized before
> > dec_usb_memory_use_count() can be called. INIT_LIST_HEAD before the
> > "if&qu
On Tue, 8 Dec 2015, Josh Triplett wrote:
> On Tue, Dec 08, 2015 at 11:04:00AM -0500, Alan Stern wrote:
> > On Mon, 7 Dec 2015, Josh Triplett wrote:
> >
> > > > You're looking at the wrong files. The files to monitor are the ones
> > > > in /sys/devi
; adding?
>
> I can write documentation if you can point me to a reasonable place.
The only documentation I know of for usbfs is a dreadfully out-of-date
section in Documentation/DocBook/usb.tmpl.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-us
On Tue, 8 Dec 2015, Steinar H. Gunderson wrote:
> Do you know what the status is for the LPM blacklisting patch we discussed
> earlier?
Last I heard, Baolu Lu was working on a more general solution. In its
absence, maybe I should go ahead and submit the patch.
Alan Stern
--
To unsub
(cpu_to_hc32(ehci, (((u32) dma) & ~0x01f) | Q_TYPE_QH))
>
> For the maintainers: Is having two lines here better than having a line with
> 83 chars?
Two lines is better. This patch is fine and so are the other 7 -- I
never received 9/9v2 (the original 9/9 was okay).
Alan Stern
ty of bandwidth available.
This patch introduces a new quirk flag for devices that should remain
disabled for LPM, and creates quirk entries for Steinar's devices.
Signed-off-by: Alan Stern
Reported-by: Steinar H. Gunderson
---
[as1786]
drivers/usb/core/hub.c |7 ++-
driver
mmy->qh_dma);
Ditto.
> + type = Q_NEXT_TYPE(ehci, q.sitd->hw_next);
> + wmb();
> + modified = sitd_complete(ehci, q.sitd);
> + q = *q_p;
> break;
> + default:
> + ehci_dbg(ehci, "corrupt type %d frame %d shadow %p\n",
> + type, frame, q.ptr);
Ditto.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
start = (stream->ps.phase << 3) + stream->ps.phase_uf;
> }
> -
Don't do this.
> stream->next_uframe = start;
> new_stream = true;
> }
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
eady lisp for this style? :-)
I don't.
> Is there a doc like the Documentation/CodingStyle with this different rules?
Not as far as I know.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
s true whereas frame == now_frame is true
only some percentage of the time. Therefore the frame == now_frame
test should come first.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ny memory mappings exist, by calling
try_module_get(THIS_MODULE) when a mapping is created and
module_put(THIS_MODULE) when a mapping is removed.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
601 - 700 of 7023 matches
Mail list logo
