Re: [PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

On Tue, Apr 18, 2017 at 8:59 PM, wlf wrote: > Dear Guenter, > > > > 在 2017年04月18日 21:18, Guenter Roeck 写道: >> >> On Mon, Apr 17, 2017 at 10:17 PM, William Wu >> wrote: >>> >>> This patch adds a quirk to disable USB 2.0 MAC linestate check >>>

Re: [PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

Dear Guenter, 在 2017年04月18日 21:18, Guenter Roeck 写道: On Mon, Apr 17, 2017 at 10:17 PM, William Wu wrote: This patch adds a quirk to disable USB 2.0 MAC linestate check during HS transmit. Refer the dwc3 databook, we can use it for some special platforms if the

Re: [PATCH 2/3] usb: gadget: function: f_fs: Let ffs_epfile_ioctl wait for enable.

On Tue, Apr 18 2017, Jerry Zhang wrote: > Also change the docs to reflect that ENODEV is no longer returned. > > This allows users to make an ioctl call as the first action on a > connection. Ex, some functions might want to get endpoint size > before making any i/os. > > Previously, calling

Re: [PATCH 3/3] usb: gadget: function: f_fs: Move epfile waitqueue to ffs_data.

On Tue, Apr 18 2017, Jerry Zhang wrote: > There were individual waitqueues for each epfile but eps_enable > would iterate through all of them, resulting in essentially the > same wakeup time. > > The waitqueue represents the function being enabled, so a central > waitqueue in ffs_data makes more

Re: [PATCH 1/3] usb: gadget: function: f_fs: Fix doc for FUNCTIONFS_INTERFACE_REVMAP

On Tue, Apr 18 2017, Jerry Zhang wrote: > The comment for this states that it returns -ENODEV > when the function is inactive. Really, an inactive > function is treated as having no interfaces, so -EDOM > is returned. Uh? Than what’s this: if (code == FUNCTIONFS_INTERFACE_REVMAP) {

VL805 USB 3.0 does not see connected devices (only on x86_64) (x86 is ok)

Found the solution! Changing BIOS settings to the values on the screenshots above made the trick! Supermicro X9SRI-F now works with PCI-E USB 3.0 card on x86_64 linux

[PATCH 2/3] usb: gadget: function: f_fs: Let ffs_epfile_ioctl wait for enable.

Also change the docs to reflect that ENODEV is no longer returned. This allows users to make an ioctl call as the first action on a connection. Ex, some functions might want to get endpoint size before making any i/os. Previously, calling ioctls before read/write would depending on the timing of

[PATCH 3/3] usb: gadget: function: f_fs: Move epfile waitqueue to ffs_data.

There were individual waitqueues for each epfile but eps_enable would iterate through all of them, resulting in essentially the same wakeup time. The waitqueue represents the function being enabled, so a central waitqueue in ffs_data makes more sense and is less redundant. Also use

[PATCH 1/3] usb: gadget: function: f_fs: Fix doc for FUNCTIONFS_INTERFACE_REVMAP

The comment for this states that it returns -ENODEV when the function is inactive. Really, an inactive function is treated as having no interfaces, so -EDOM is returned. Signed-off-by: Jerry Zhang --- include/uapi/linux/usb/functionfs.h | 3 +-- 1 file changed, 1

[PATCH 0/3] Small patches for f_fs.c

Mostly some maintainence patches. I'm happy to take feedback. Patch 2 is useful for the mtp function, since it uses endpoint size to figure out when to read/write a zero length packet. It would be nice to get these values at the start of a connection and cache them for the duration, although

Re: Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace

Am 18.04.2017 um 21:31 schrieb Alan Stern: On Mon, 17 Apr 2017, Andreas Hartmann wrote: Good start, but there are five (!) other places in this driver where the same bug occurs, at lines 904, 1350, 1577, 2088, and 2157. Would you like to fix them too? Maybe it would be easier for the driver

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

> Doug Anderson hat am 18. April 2017 um 22:41 > geschrieben: > > > Stefan, > > On Tue, Apr 18, 2017 at 1:25 PM, Stefan Wahren wrote: > > Hi, > > > > [add Johan] > > > >> Stefan Wahren hat am 18. April 2017 um 10:07 >

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

Stefan, On Tue, Apr 18, 2017 at 1:25 PM, Stefan Wahren wrote: > Hi, > > [add Johan] > >> Stefan Wahren hat am 18. April 2017 um 10:07 >> geschrieben: >> >> >> Am 18.04.2017 um 00:37 schrieb Doug Anderson: >> > Hi, >> > >> > On Mon, Apr 17, 2017

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

Hi, [add Johan] > Stefan Wahren hat am 18. April 2017 um 10:07 > geschrieben: > > > Am 18.04.2017 um 00:37 schrieb Doug Anderson: > > Hi, > > > > On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren > > wrote: > >> Hi, > >> > >>> Stefan Wahren

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

Hi, On Tue, Apr 18, 2017 at 1:07 AM, Stefan Wahren wrote: >> 1. With dwc2 you often end up in the situation where you need to >> service an interrupt every 125 uS. If servicing that interrupt takes >> anywhere near 125 uS in the common case then you'll be in trouble. > >

Re: Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace

On Mon, 17 Apr 2017, Andreas Hartmann wrote: > > Good start, but there are five (!) other places in this driver where > > the same bug occurs, at lines 904, 1350, 1577, 2088, and 2157. Would > > you like to fix them too? > > > > Maybe it would be easier for the driver to allocate a single

Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi Heikki, I have a question regarding the preferred_role node. +What: /sys/class/typec//preferred_role +Date: March 2017 +Contact: Heikki Krogerus +Description: + The user space can notify the driver about the preferred

Re: usb: host: xhci: stalled endpoint ring not cleared on empty td_list

Am Sonntag, den 16.04.2017, 20:34 +0200 schrieb Rolf Evers-Fischer: > Both functions are described in Documentation/usb/anchors.txt and I agree: It > is not stated clearly that we must always call the > "usb_wait_anchor_empty_timeout()" function before we can call the >

Re: [PATCH V2] USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit

On 04/18/2017 11:56 AM, Johan Hovold wrote: > On Mon, Apr 17, 2017 at 01:56:54PM +0200, Marek Vasut wrote: >> This development kit has an FT4232 on it with a custom USB VID/PID. >> The FT4232 provides four UARTs, but only two are used. The UART 0 >> is used by the FlashPro5 programmer and UART 2

[PATCH] USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit

This development kit has an FT4232 on it with a custom USB VID/PID. The FT4232 provides four UARTs, but only two are used. The UART 0 is used by the FlashPro5 programmer and UART 2 is connected to the SmartFusion2 CortexM3 SoC UART port. Note that the USB VID is registered to Actel according to

Re: usb: host: xhci: stalled endpoint ring not cleared on empty td_list

Dear Alan and Oliver, > Oliver Neukum hat am 18. April 2017 um 09:37 geschrieben: > > You can call usb_kill_anchored_urbs() always. > Alan Stern hat am 17. April 2017 um 16:14 > geschrieben: > > It is not necessary to call

XHCI is slow during boot (bios/efi) and leaves many dmesg messages

Hi, I can't find how to reply to an old thread with majordomo, sorry for the inconvenience it might cause. I'm reposting an issue [0] that has been inactive for a few month but still present in kernel 4.10.10 on a Macbook pro 12,1. I can provide more informations if needed but the issue is

Re: [GIT PULL] usb: chipidea changes for v4.12-rc1

On Tue, Apr 18, 2017 at 02:31:26AM +, Peter Chen wrote: > The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81: > > Linux 4.11-rc2 (2017-03-12 14:47:08 -0700) > > are available in the git repository at: > >

Re: [PATCH v4 4/6] usb.rst: move documentation from proc_usb_info.txt to USB ReST book

On Sun, Apr 16, 2017 at 09:51:09PM -0300, Mauro Carvalho Chehab wrote: > The contents of proc_usb_info.txt complements what's there at > driver-api usb book. Yet, it is outdated, as it still refers > to the USB character devices as usbfs. > > So, move the contents to usb.rst, adjusting it to

Re: [PATCH v4 2/6] usb: fix some references for /proc/bus/usb

On Sun, Apr 16, 2017 at 09:51:07PM -0300, Mauro Carvalho Chehab wrote: > Since when we got rid of usbfs, the /proc/bus/usb is now > elsewhere. Fix references for it. > > Signed-off-by: Mauro Carvalho Chehab Oops, will take this one instead... -- To unsubscribe from

Re: [PATCH v3 2/3] usb: fix some references for /proc/bus/usb

On Sun, Apr 16, 2017 at 01:40:04PM -0300, Mauro Carvalho Chehab wrote: > Since when we got rid of usbfs, the /proc/bus/usb is now > elsewhere. Fix references for it. > > Signed-off-by: Mauro Carvalho Chehab As this touches USB code, I'll take this in my tree. thanks,

Re: [PATCH v3 1/3] docs-rst: usb: update old usbfs-related documentation

On Sun, Apr 16, 2017 at 01:40:03PM -0300, Mauro Carvalho Chehab wrote: > There's no usbfs anymore. The old features are now either > exported to /dev/bus/usb or via debugfs. > > Update documentation accordingly, pointing to the new > places where the character devices and usb/devices are > now

Re: [PATCH] xhci: switch to pci_alloc_irq_vectors

On Wed, Apr 12, 2017 at 08:32:20PM +0200, Christoph Hellwig wrote: > Use the modern API to request MSI or MSI-X interrupts, which allows us to > get rid of the msix_entries array, as well as cleaning up the cleanup > code. > > Signed-off-by: Christoph Hellwig > --- >

Re: usb: typec: Missing link for altmode active store

Hi Mats, On Sun, Apr 16, 2017 at 09:28:01PM +0200, Mats Karrman wrote: > Hello Heikki, > > I'm working with the new typec class code and have run into a problem. > The struct typec_capability defines a callback function as: > > int (*activate_mode)(const struct typec_capability *, int mode, int

Re: Ops in usb stack

On Tue, Apr 18, 2017 at 3:42 AM, Lars Melin wrote: > On 2017-04-18 02:06, Anders Eriksson wrote: >> >> [1.056684] dwc_otg: version 3.00a 10-AUG-2012 (platform bus) > > > The pesky dwc_otg driver is the reason for your problem, it is not > part of the official 4.9 kernel. >

Re: [PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

On Mon, Apr 17, 2017 at 10:17 PM, William Wu wrote: > This patch adds a quirk to disable USB 2.0 MAC linestate check > during HS transmit. Refer the dwc3 databook, we can use it for > some special platforms if the linestate not reflect the expected > line state(J)

Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

Hi, Thinh Nguyen writes: >> (Thinh, for whatever I didn't receive your email via the list, replying >> to myself) > > Could it be because of the attached file? > >> >> Felipe Balbi writes: Hmm, can you apply this patch and provide output when

[PATCH] USB: serial: constify arrays

Declare three constant driver arrays as const. Signed-off-by: Johan Hovold --- drivers/usb/serial/io_edgeport.c | 6 +++--- drivers/usb/serial/mos7720.c | 2 +- drivers/usb/serial/usb_debug.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git

RE: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

From: Bjorn Helgaas > Sent: 12 April 2017 16:05 ... > >> So we mask the interrupt in the TH and a short time later, the > >> interrupt de-assertion packet is sent on PCIe bus and if that's not > >> seen right away we may already have another call to TH before the BH > >> gets scheduled. > > > >

Re: [PATCH] usb: Make sure usb/phy/of gets built-in

Hello Frank, On Mon, 2017-04-17 at 20:15 -0700, Frank Rowand wrote: > On 04/13/17 05:33, Alexey Brodkin wrote: > > > > DWC3 driver uses of_usb_get_phy_mode() which is > > implemented in drivers/usb/phy/of.c and in bare minimal > > configuration it might not be pulled in kernel binary. > > > >

[PATCH V3 2/4] reset: Add APIs to manage array of resets

Many devices may want to request a bunch of resets and control them. So it's better to manage them as an array. Add APIs to _get(), _assert(), and _deassert() an array of reset_control. Cc: Philipp Zabel Signed-off-by: Vivek Gautam ---

[PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

Make use of reset_control_array_*() set of APIs to manage an array of reset controllers available with the device. Cc: Thierry Reding Cc: Philipp Zabel Signed-off-by: Vivek Gautam --- drivers/soc/tegra/pmc.c | 99

[PATCH V3 1/4] reset: Add API to count number of reset available with device

Count number of reset phandles available with the device node to know the resets a given device has. Cc: Philipp Zabel Signed-off-by: Vivek Gautam --- drivers/reset/core.c | 23 +++ include/linux/reset.h | 6 ++ 2

[PATCH V3 0/4] reset: APIs to manage a list of resets

Set of patches to support getting and de/asserting a list (array) of reset controllers available with the device. This series also contains reset controls patches for dwc3-of-simple and tegra pmc drivers. This V3 version addresses Philipp's review comments to make the APIs inline with gpiod APIs.

[PATCH V3 3/4] usb: dwc3: of-simple: Add support to get resets for the device

Add support to get a list of resets available for the device. These resets must be kept de-asserted until the device is in use. Cc: Felipe Balbi Cc: Philipp Zabel Signed-off-by: Vivek Gautam ---

RE: [PATCH 1/1] usb: host: xhci: using correct specification chapter reference for DCBAAP

>> >> /* >> - * Section 5.4.8 - doorbell array must be >> + * xHCI rev 1.1 Section 5.4.6 - doorbell array must be >> * "physically contiguous and 64-byte (cache line) aligned". >> */ >> xhci->dcbaa = dma_alloc_coherent(dev, sizeof(*xhci->dcbaa), , >> > >Thanks >This

Re: [PATCH 1/1] usb: host: xhci: using correct specification chapter reference for DCBAAP

On 18.04.2017 11:35, Peter Chen wrote: Using correct specification chapter reference for DCBAAP (Device Context Base Address Array Pointer). Signed-off-by: Peter Chen --- drivers/usb/host/xhci-mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/1] usb: host: xhci: print correct command ring address

Print correct command ring address using 'val_64'. Cc: stable Signed-off-by: Peter Chen --- drivers/usb/host/xhci-mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c

Re: [PATCH 3/3] usb: host: xhci-plat: set resume_quirk() for R-Car controllers

On 17.03.2017 12:02, Yoshihiro Shimoda wrote: This patch sets resume_quirk() for R-Car controllers to re-download the firmware in resume timing. Otherwise, if the controller's power is down in suspend timing, the firmware in the controller goes away, and then the controller doesn't work after

Re: [PATCH V2] USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit

On Mon, Apr 17, 2017 at 01:56:54PM +0200, Marek Vasut wrote: > This development kit has an FT4232 on it with a custom USB VID/PID. > The FT4232 provides four UARTs, but only two are used. The UART 0 > is used by the FlashPro5 programmer and UART 2 is connected to the > SmartFusion2 CortexM3 SoC

[PATCH 1/1] usb: host: xhci: using correct specification chapter reference for DCBAAP

Using correct specification chapter reference for DCBAAP (Device Context Base Address Array Pointer). Signed-off-by: Peter Chen --- drivers/usb/host/xhci-mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-mem.c

Re: [PATCH] Partially revert "usb: Kconfig: using select for USB_COMMON dependency"

On Tue, Apr 18, 2017 at 4:36 AM, Ben Hutchings wrote: > This reverts commit cb9c1cfc86926d0e86d19c8e34f6c23458cd3478 for > USB_LED_TRIG. This config symbol has bool type and enables extra code > in usb_common itself, not a separate driver. Enabling it should not > force

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

Am 18.04.2017 um 00:37 schrieb Doug Anderson: > Hi, > > On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren wrote: >> Hi, >> >>> Stefan Wahren hat am 31. Oktober 2016 um 21:34 >>> geschrieben: >>> >>> >>> I inspired by this issue [1] i build up a

Re: usb: host: xhci: stalled endpoint ring not cleared on empty td_list

Am Sonntag, den 16.04.2017, 20:34 +0200 schrieb Rolf Evers-Fischer: > Both functions are described in Documentation/usb/anchors.txt and I agree: It > is not stated clearly that we must always call the > "usb_wait_anchor_empty_timeout()" function before we can call the >