Re: [PATCH v2 1/1] usb: xhci: fix checking ep busy for CFC

Hello. On 10/29/2015 5:46 AM, Lu Baolu wrote: Function ep_ring_is_processing() checks the dequeue pointer in endpoint context to know whether an endpoint is busy with processing TRBs. This is not correct since dequeue pointer field in an endpoint context is only valid when the endpoint is in

Re: [PATCH v4 3/3] USB: serial: cp210x: Workaround cp2108 GET_LINE_CTL bug

I tested it on cp2102, cp2105 and cp2108. I'm a little worried about that extra PURGE command, so I did several manual tests on each with a standard PC serial port on the other end of the cable. - run several open/write/close iteration (the test that used to break cp2108), observe data on the

Re: [PATCH v2 1/1] usb: xhci: fix checking ep busy for CFC

On 29.10.2015 14:58, Lu, Baolu wrote: On 10/29/2015 08:51 PM, Sergei Shtylyov wrote: Hello. On 10/29/2015 5:46 AM, Lu Baolu wrote: Function ep_ring_is_processing() checks the dequeue pointer in endpoint context to know whether an endpoint is busy with processing TRBs. This is not correct

Re: [PATCH v2 1/1] usb: xhci: fix checking ep busy for CFC

On 10/29/2015 08:51 PM, Sergei Shtylyov wrote: Hello. On 10/29/2015 5:46 AM, Lu Baolu wrote: Function ep_ring_is_processing() checks the dequeue pointer in endpoint context to know whether an endpoint is busy with processing TRBs. This is not correct since dequeue pointer field in an

Re: f_loopback warning

On 10/29/2015 10:36 AM, Peter Chen wrote: Hi, It is due to try to allocate memory with GFP_KERNEL at ISR, below change can fix it, if not better solution, I can submit a patch. diff --git a/drivers/usb/gadget/function/f_loopback.c b/drivers/usb/gadget/function/f_loopback.c index

[PATCH V4] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

The USB OTG support currently depends on power management (CONFIG_PM) being enabled, but does not actually need it enabled. Remove this dependency. Tested on Bay Trail hardware with dwc3 USB. Signed-off-by: Nathan Sullivan --- drivers/usb/core/Kconfig |1 - 1 file

[PATCH v3 1/1] usb: xhci: fix checking ep busy for CFC

Function ep_ring_is_processing() checks the dequeue pointer in endpoint context to know whether an endpoint is busy with processing TRBs. This is not correct since dequeue pointer field in an endpoint context is only valid when the endpoint is in Halted or Stopped states. This buggy code causes

Re: [PATCH v2 1/1] usb: xhci: fix checking ep busy for CFC

On 10/29/2015 10:08 PM, Mathias Nyman wrote: On 29.10.2015 14:58, Lu, Baolu wrote: On 10/29/2015 08:51 PM, Sergei Shtylyov wrote: Hello. On 10/29/2015 5:46 AM, Lu Baolu wrote: Function ep_ring_is_processing() checks the dequeue pointer in endpoint context to know whether an endpoint is

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

On Thu, 29 Oct 2015, Peter Chen wrote: > > > [In practice it's not feasible to wait for an active QH to become > > > inactive before removing it, for several reasons. For one, the QH may > > > _never_ become inactive (if the endpoint NAKs indefinitely). For > > > another, the procedure given in

Re: [PATCH] usb: dwc2: host: Fix remote wakeup when not in DWC2_L2

John, On Thu, Oct 22, 2015 at 1:05 PM, Douglas Anderson wrote: > In commit 734643dfbdde ("usb: dwc2: host: add flag to reflect bus > state") we changed dwc2_port_suspend() not to set the lx_state > anymore (instead it sets the new bus_suspended variable). This >

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

On Thu, 29 Oct 2015, Matthew Dharm wrote: > Uhh... I think this is a bad idea. The 120K limit was chosen based on > seeing a lot of devices which broke if you tried to transfer more. At > least, that's my memory. Otherwise, it's a really goofy number. > > I certainly wouldn't mind you

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

(Resend, as I forgot to switch to plain-text for linux-usb@vger rules). Uhh... I think this is a bad idea. The 120K limit was chosen based on seeing a lot of devices which broke if you tried to transfer more. At least, that's my memory. Otherwise, it's a really goofy number. I certainly

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

IIRC, the sysfs attribute doesn't exist until after the device is probed, and the SCSI probing might fail (can't read partition tables, leading to errors, catastrophic failure) if the max-sectors is too high during probing. While I agree 20-25% performance gain is significant, a high failure-rate

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

On Thu, 29 Oct 2015, Felipe Balbi wrote: > Hi, > > Alan Stern writes: > > On Thu, 29 Oct 2015, Matthew Dharm wrote: > > > >> Uhh... I think this is a bad idea. The 120K limit was chosen based on > >> seeing a lot of devices which broke if you tried to transfer more.

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

Hi Felipe, [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/Felipe-Balbi/usb-storage-scsiglue-increase-transfer-size-limit/20151030-042306 config:

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

Hi, Alan Stern writes: > On Thu, 29 Oct 2015, Matthew Dharm wrote: > >> Uhh... I think this is a bad idea. The 120K limit was chosen based on >> seeing a lot of devices which broke if you tried to transfer more. At >> least, that's my memory. Otherwise, it's a

[PATCH] usb: storage: scsiglue: increase transfer size limit

Instead of using only 120K for transfer size, let's increase it to 1024K. This has a very noticeable impact on USB3 storage devices. The following measurements were done with v4.2 on the host side and latest linux-next available at the time (20151022). Following are results with default and

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

Hi, Matthew Dharm writes: > Uhh... I think this is a bad idea. The 120K limit was chosen based on > seeing a lot of devices which broke if you tried to transfer more. At > least, that's my memory. Otherwise, it's a really goofy number. okay, if somebody has

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

Hi, kbuild test robot writes: > Hi Felipe, > > [auto build test ERROR on usb/usb-next -- if it's inappropriate base, please > suggest rules for selecting the more suitable base] > > url: >

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

On Thu, Oct 29, 2015 at 02:00:57PM -0700, Matthew Dharm wrote: > IIRC, the sysfs attribute doesn't exist until after the device is > probed, and the SCSI probing might fail (can't read partition tables, > leading to errors, catastrophic failure) if the max-sectors is too > high during probing. >

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

On Thu, Oct 29, 2015 at 4:44 PM, Linus Torvalds wrote: > > That said, I'm pretty sure it's just that there were (and probably > still are) tons of bad USB sticks with cheap controllers with 8-bit > sector counts, and you're better off picking something that causes >

Re: [PATCH] usb: dwc2: host: Fix remote wakeup when not in DWC2_L2

Am Donnerstag, 22. Oktober 2015, 13:05:03 schrieb Douglas Anderson: > In commit 734643dfbdde ("usb: dwc2: host: add flag to reflect bus > state") we changed dwc2_port_suspend() not to set the lx_state > anymore (instead it sets the new bus_suspended variable). This > introduced a bug where we

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

Hi, Alan Stern writes: >> Alan Stern writes: >> > On Thu, 29 Oct 2015, Matthew Dharm wrote: >> > >> >> Uhh... I think this is a bad idea. The 120K limit was chosen based on >> >> seeing a lot of devices which broke if you tried to transfer

Re: [PATCH] usb: dwc2: host: Fix remote wakeup when not in DWC2_L2

Hi, On Thu, Oct 29, 2015 at 3:49 PM, Heiko Stuebner wrote: > Am Donnerstag, 22. Oktober 2015, 13:05:03 schrieb Douglas Anderson: >> In commit 734643dfbdde ("usb: dwc2: host: add flag to reflect bus >> state") we changed dwc2_port_suspend() not to set the lx_state >> anymore

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

On Thu, Oct 29, 2015 at 4:25 PM, Felipe Balbi wrote: > > Fair enough. Linus, do you have any recollection of which device you > found to be quirky ? Your original commit limitting to 240 sectors > doesn't make that clear at all ;-) > > [1]

Re: [PATCH 2/3] kbuild: Allow to specify composite modules with modname-m

On Wed, Oct 28, 2015 at 02:25:41PM +0100, Michal Marek wrote: > From: Michal Marek > > This allows to write > > drm-$(CONFIG_AGP) += drm_agpsupport.o > > without having to handle CONFIG_AGP=y vs. CONFIG_AGP=m. Only support > this syntax for modules, since built-in code

Re: [PATCH v4 3/3] USB: serial: cp210x: Workaround cp2108 GET_LINE_CTL bug

On Wed, Oct 28, 2015 at 09:51:26AM +0100, Johan Hovold wrote: > On Tue, Oct 27, 2015 at 04:53:34PM -0500, Konstantin Shkolnyy wrote: > > cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped. > > However, SET_LINE_CTL functions properly. When the driver tries to modify > > the

Re: [PATCH 2/3] kbuild: Allow to specify composite modules with modname-m

Dne 29.10.2015 v 07:34 Peter Chen napsal(a): > On Wed, Oct 28, 2015 at 02:25:41PM +0100, Michal Marek wrote: >> From: Michal Marek >> >> This allows to write >> >> drm-$(CONFIG_AGP) += drm_agpsupport.o >> >> without having to handle CONFIG_AGP=y vs. CONFIG_AGP=m. Only support

Re: [PATCH 2/3] kbuild: Allow to specify composite modules with modname-m

On Thu, Oct 29, 2015 at 09:05:55AM +0100, Michal Marek wrote: > Dne 29.10.2015 v 07:34 Peter Chen napsal(a): > > On Wed, Oct 28, 2015 at 02:25:41PM +0100, Michal Marek wrote: > >> From: Michal Marek > >> > >> This allows to write > >> > >> drm-$(CONFIG_AGP) += drm_agpsupport.o

Re: [PATCHv2] usb: dwc2: use devm_phy_optional_get

Hello Stephen, On Wed, Oct 28, 2015 at 09:55:05PM -0600, Stephen Warren wrote: > On 10/27/2015 12:18 PM, Uwe Kleine-König wrote: > > Hello, > > > > On Tue, Oct 27, 2015 at 09:08:27AM -0600, Stephen Warren wrote: > >> On 10/27/2015 01:41 AM, Uwe Kleine-König wrote: > >>> Hello, > >>> > >>> On

Re: [PATCH V3] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

On Wed, Oct 28, 2015 at 08:41:41AM -0500, Nathan Sullivan wrote: > The USB OTG support currently depends on power management > (CONFIG_PM) being enabled, but does not actually need it enabled. > Remove this dependency. > > Remove the unneeded "default n" from USB_OTG as well, the default is >

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

On Thu, Oct 22, 2015 at 05:14:41PM -0400, Alan Stern wrote: > [Resend with Hans's correct email address this time...] > > On Thu, 22 Oct 2015, Alan Stern wrote: > > > Hans and everyone else: > > > > This continues the discussion of a problem originally posted to the > > libusb-devel mailing

f_loopback warning

Hi, It is due to try to allocate memory with GFP_KERNEL at ISR, below change can fix it, if not better solution, I can submit a patch. diff --git a/drivers/usb/gadget/function/f_loopback.c b/drivers/usb/gadget/function/f_loopback.c index 6b2102b..d2524a1 100644 ---

Re: [PATCH] usb: dwc2: host: Fix remote wakeup when not in DWC2_L2

On 10/29/2015 9:43 AM, Doug Anderson wrote: > John, > > On Thu, Oct 22, 2015 at 1:05 PM, Douglas Anderson > wrote: >> In commit 734643dfbdde ("usb: dwc2: host: add flag to reflect bus >> state") we changed dwc2_port_suspend() not to set the lx_state >> anymore (instead it

[RESEND PATCH] USB: usbmon: Use 64bit timestamp for mon_bin_hdr

struct mon_bin_hdr allows for a 64-bit seconds timestamp. The code currently uses 'struct timeval' to populate the timestamp in mon_bin_hdr, which has a 32-bit seconds field and will overflow in year 2038 and beyond. This patch replaces 'struct timeval' with 'struct timespec64' which is y2038

[PATCH v2] USB: usbmon: Remove timeval usage for timestamp

struct timeval' uses 32-bits for its seconds field and will overflow in the year 2038 and beyond. This patch replaces the usage of 'struct timeval' in mon_get_timestamp() with timespec64 which uses a 64-bit seconds field and is y2038-safe. mon_get_timestamp() truncates the timestamp at 4096