Re: [PATCH 01/12] usb: xhci: expose xhci extended capabilities via debugfs

On 10/30/2015 10:45 PM, Greg Kroah-Hartman wrote: On Fri, Oct 30, 2015 at 08:09:17PM +0800, Lu, Baolu wrote: On 10/28/2015 08:40 PM, Greg Kroah-Hartman wrote: +static const char *get_extcap_desc(u32 cap_id) +{ + switch (cap_id) { + case XHCI_EXT_CAPS_LEGACY: +

Re: Overly conservative xHCI bandwidth estimation

Thanks for the information. I will let you know if I have anything. Thanks, Baolu On 11/01/2015 04:20 AM, Steinar H. Gunderson wrote: On Wed, Oct 21, 2015 at 09:49:16AM +0800, Lu, Baolu wrote: I could spend some time on this issue a week later. I'd like to check whether there is any bugs in

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 11:04:42AM -0500, Alan Stern wrote: > To make your life easier, here's a patch which blacklists these two > devices for Link Power Management. Please let me know if it works > okay. OK, this worked brilliantly. I can now use both cards at the same time, and I also see

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 01:28:09PM -0500, Alan Stern wrote: >> Thanks for testing. I will submit the patch in two weeks, when the >> current merge window closes. > Or maybe not. This may not be the best way to solve the problem, since > you found that the two video cards worked okay with one

Re: Page allocation failure

On Mon, 2 Nov 2015, Steinar H. Gunderson wrote: > > Once the data is in the kernel, the rest of the procedure is basically > > zero-copy. The problem is getting it there from within your program. > > We currently don't have any support for zero-copy data submissions, > > although it has been

Re: Overly conservative xHCI bandwidth estimation

On Mon, 2 Nov 2015, Steinar H. Gunderson wrote: > On Mon, Nov 02, 2015 at 11:04:42AM -0500, Alan Stern wrote: > > To make your life easier, here's a patch which blacklists these two > > devices for Link Power Management. Please let me know if it works > > okay. > > OK, this worked

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

Hi, On Mon, Nov 2, 2015 at 9:16 AM, Rob Herring wrote: > On Mon, Nov 2, 2015 at 10:22 AM, Doug Anderson wrote: >> Rob, >> >> On Mon, Nov 2, 2015 at 8:12 AM, Rob Herring wrote: >>> On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson

Re: Overly conservative xHCI bandwidth estimation

On Mon, 2 Nov 2015, Alan Stern wrote: > On Mon, 2 Nov 2015, Steinar H. Gunderson wrote: > > > On Mon, Nov 02, 2015 at 11:04:42AM -0500, Alan Stern wrote: > > > To make your life easier, here's a patch which blacklists these two > > > devices for Link Power Management. Please let me know if it

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 11:04:42AM -0500, Alan Stern wrote: > To make your life easier, here's a patch which blacklists these two > devices for Link Power Management. Please let me know if it works > okay. Thanks! I'll give it a shot. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To

Re: Page allocation failure

On Mon, Nov 02, 2015 at 11:48:36AM -0500, Alan Stern wrote: > Order 7? Maybe you're trying to put too much data into a single > transfer and encountering problems with memory fragmentation. Try > using more frequent, smaller transfers. Yes, my transfers are rather big; 512 kB or so. (They used

Re: [PATCH V6 1/1] usb:serial: Add Fintek F81532/534 driver

Hi Peter, [auto build test ERROR on usb/usb-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Peter-Hung/usb-serial-Add-Fintek-F81532-534-driver/20151103-115336 config: tile-allyesconfig (attached as

Re: [PATCH V6 1/1] usb:serial: Add Fintek F81532/534 driver

Hi Peter, [auto build test ERROR on usb/usb-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Peter-Hung/usb-serial-Add-Fintek-F81532-534-driver/20151103-115336 config: m68k-allyesconfig (attached as

Re: implement put_char() in cdc-acm

On 02/11/15 12:32, Oliver Neukum wrote: > given this test I will submit the patch. Mind you, I don't know if the improvement is due to your patch or other things. I didn't test the new kernel without your patch; should I? > Sven, can you ramp up the buffers in the manner Peter suggested > and

Re: Overly conservative xHCI bandwidth estimation

On Mon, 2 Nov 2015, Steinar H. Gunderson wrote: > On Mon, Nov 02, 2015 at 02:38:41PM -0500, Alan Stern wrote: > >> Note that the two controllers were running different kernels. The one that > >> worked had a kernel before LPM was turned on, I believe. > > Oh. Can you try running a more recent

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 03:32:46PM -0500, Alan Stern wrote: > You don't need 4.3. Anything released within the last few years > will contain the LPM code. According to the bisect, the patch that broke it was from June this year (2d2a316765d956bc5cb6bb367b2ec52ca59ab8e9), so it would really seem

Re: Overly conservative xHCI bandwidth estimation

On Mon, 2 Nov 2015, Steinar H. Gunderson wrote: > On Mon, Nov 02, 2015 at 01:28:09PM -0500, Alan Stern wrote: > >> Thanks for testing. I will submit the patch in two weeks, when the > >> current merge window closes. > > Or maybe not. This may not be the best way to solve the problem, since > >

Re: Overly conservative xHCI bandwidth estimation

On Mon, Nov 02, 2015 at 02:38:41PM -0500, Alan Stern wrote: >> Note that the two controllers were running different kernels. The one that >> worked had a kernel before LPM was turned on, I believe. > Oh. Can you try running a more recent kernel on that computer? Does > it fail with the same

Re: [PATCH v5 0/5] usb/gadget: independent registration of gadgets and gadget drivers

Hi Maxime, On Mon, Oct 19, 2015 at 11:11 AM, Maxime Ripard wrote: > Hi, > > On Tue, Jun 23, 2015 at 01:01:09AM +0300, Ruslan Bilovol wrote: >> This patchset adds independent registration of gadgets >> and gadget drivers to udc-core. This is very useful for >>

Re: Page allocation failure

On Sun, 1 Nov 2015, Steinar H. Gunderson wrote: > Hello again, > > I am (still) using libusb-1.0 to drive an USB 3.0 video card. After I turned > off power management (see previous emails :-) ) it seems stable, but after > running something like 5–6 hours, I seem to get problems on URB

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson wrote: > From: Doug Anderson > > On the rk3288 USB host-only port (the one that's not the OTG-enabled > port) the PHY can get into a bad state when a wakeup is asserted (not > just a wakeup from full

Re: Help needed for EHCI problem: removing an active bulk-in QH

On Mon, 2 Nov 2015, Peter Chen wrote: > Hi Alan, > > After a discussion with IC engineer, a brief idea like below: > > - Delete the QH from the asynclist directly, Issue the first IAA > routine, this is we do now. > - During the first IAA interrupt, judge if asynclistaddr is next address of >

Re: Overly conservative xHCI bandwidth estimation

On Sat, 31 Oct 2015, Steinar H. Gunderson wrote: > On Wed, Oct 21, 2015 at 09:49:16AM +0800, Lu, Baolu wrote: > > I could spend some time on this issue a week later. > > I'd like to check whether there is any bugs in the driver itself. > > Otherwise, blacklist this specific device for LPM. > > I

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

Rob, On Mon, Nov 2, 2015 at 8:12 AM, Rob Herring wrote: > On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson > wrote: >> From: Doug Anderson >> >> On the rk3288 USB host-only port (the one that's not the OTG-enabled >> port) the

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

On Mon, Nov 2, 2015 at 10:22 AM, Doug Anderson wrote: > Rob, > > On Mon, Nov 2, 2015 at 8:12 AM, Rob Herring wrote: >> On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson >> wrote: >>> From: Doug Anderson

Re: [PATCH net,stable] qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module

From: Bjørn Mork Date: Sun, 1 Nov 2015 01:34:50 +0100 > The lt4112 is a HP branded Huawei me906e modem. Like other Huawei > modems, it does not have a fixed interface to function mapping. > Instead it uses a Huawei specific scheme: functions are mapped by > subclass and protocol.

Re: Overly conservative xHCI bandwidth estimation

On Mon, 2 Nov 2015, Steinar H. Gunderson wrote: > On Mon, Nov 02, 2015 at 03:32:46PM -0500, Alan Stern wrote: > > You don't need 4.3. Anything released within the last few years > > will contain the LPM code. > > According to the bisect, the patch that broke it was from June this year >

Re: Help needed for EHCI problem: removing an active bulk-in QH

On Mon, 2 Nov 2015, Michael Reutman wrote: > On Wed, Oct 28, 2015 at 10:48 AM, Alan Stern > wrote: > > The patch below is meant to apply on top of the previous patch. It's a > > quick-and-dirty workaround which ought to prevent the problem from > > occurring. Let's

[PATCH 1/1] usblp: do not set TASK_INTERRUPTIBLE before lock

It is not permitted to set task state before lock. usblp_wwait sets the state to TASK_INTERRUPTIBLE and calls mutex_lock_interruptible. Upon return from that function, the state will be TASK_RUNNING again. This is clearly a bug and a warning is generated with LOCKDEP too: WARNING: CPU: 1 PID:

Re: Help needed for EHCI problem: removing an active bulk-in QH

On Fri, Oct 30, 2015 at 11:15:05AM -0400, Alan Stern wrote: > On Fri, 30 Oct 2015, Peter Chen wrote: > > > After reading spec at 4.8.2: > > > > Software must not remove an active queue head from the schedule. > > Software should first deactivate all active qTDs, wait for the > > queue head to go

Re: implement put_char() in cdc-acm

On Sun, 2015-11-01 at 20:28 +0100, Sven Brauch wrote: > I cloned that tree (git describe said v4.3-rc5), and applied Oliver's > patch. With that kernel booted, the error occured much less > frequently, > but was still reproducable under load. With 4.2.5, I get a failure > after > a few hundred MB;

[PATCH V6 1/1] usb:serial: Add Fintek F81532/534 driver

This driver is for Fintek F81532/F81534 USB to Serial Ports IC. Features: 1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC 2. Support Baudrate from B50 to B150 (excluding B100). 3. The RTS signal can be transformed their behavior with configuration by ioctl TIOCGRS485/TIOCSRS485