RE: [PATCH V2] USBIP: return correct port ENABLE status

Hi Shuah, Thanks for your response. It's on KVM hypervisor platform, while the Dom0 is the usbip server, and a DomU act as the client. This issue could be 100% reproduced with the specified devices referred in my patch comment. I will prepare the environment and then send you related informatio

RE: [PATCH v4 1/3] usb: renesas_usbhs: Add support for RZ/A1

Hi Chris-san, > From: Chris Brandt, Sent: Monday, January 8, 2018 9:31 PM > > This patch adds the capability to support RZ/A1 SoCs. > > Signed-off-by: Chris Brandt Thank you for the patch! Acked-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda -- To unsubscribe from this list: send th

RE: [PATCH v4 1/3] usb: renesas_usbhs: Add support for RZ/A1

+Felipe > -Original Message- > From: Yoshihiro Shimoda, Sent: Wednesday, January 10, 2018 5:27 PM > > Hi Chris-san, > > > From: Chris Brandt, Sent: Monday, January 8, 2018 9:31 PM > > > > This patch adds the capability to support RZ/A1 SoCs. > > > > Signed-off-by: Chris Brandt > > Than

RE: [PATCH v4 2/3] dt-bindings: usb: renesas_usbhs: Add support for RZ/A1

Hi Chris-san, (And I added Felipe's email as To) > From: Chris Brandt, Sent: Monday, January 8, 2018 9:31 PM > > Document support for RZ/A1 SoCs > > Signed-off-by: Chris Brandt > Reviewed-by: Geert Uytterhoeven > --- Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yos

Re: [PATCH V2 1/5] usb: serial: f81534: add high baud rate support

On Wed, Jan 10, 2018 at 01:30:18PM +0800, Ji-Ze Hong (Peter Hong) wrote: > Hi Johan, > > Johan Hovold 於 2018/1/9 下午 07:08 寫道: > > On Thu, Jan 04, 2018 at 10:29:17AM +0800, Ji-Ze Hong (Peter Hong) wrote: > >> The F81532/534 had 4 clocksource 1.846/18.46/14.77/24MHz and baud rates > >> can be up to

Re: [PATCH V2 5/5] usb: serial: f81534: fix tx error on some baud rate

On Wed, Jan 10, 2018 at 01:42:32PM +0800, Ji-Ze Hong (Peter Hong) wrote: > Hi Johan, > > Johan Hovold 於 2018/1/9 下午 07:32 寫道: > > On Thu, Jan 04, 2018 at 10:29:21AM +0800, Ji-Ze Hong (Peter Hong) wrote: > >> + /* > >> + * We'll make tx frame error when baud rate from 384~500kps. So we'll > >> +

Re: [PATCH V2 1/5] usb: serial: f81534: add high baud rate support

Hi Johan, Johan Hovold 於 2018/1/10 下午 04:49 寫道: Normally, the communication with F81534 ep0 will take less than 1 sec (even only some milliseconds), but It maybe take much long time with huge loading with UART functional. We had tested it on BurnInTest, 4 ports with 921600bps + MSR status check

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On 9 January 2018 at 17:28, Rafael J. Wysocki wrote: > On Tuesday, January 9, 2018 5:03:18 PM CET Rafael J. Wysocki wrote: >> On Tue, Jan 9, 2018 at 4:30 PM, Geert Uytterhoeven >> wrote: >> > Hi Rafael, >> > >> > CC usb >> > >> > On Tue, Jan 9, 2018 at 4:00 PM, Rafael J. Wysocki >> > wrote: >>

Re: [PATCH V2 1/5] usb: serial: f81534: add high baud rate support

On Wed, Jan 10, 2018 at 05:16:01PM +0800, Ji-Ze Hong (Peter Hong) wrote: > Hi Johan, > > Johan Hovold 於 2018/1/10 下午 04:49 寫道: > >> Normally, the communication with F81534 ep0 will take less than 1 sec > >> (even only some milliseconds), but It maybe take much long time with > >> huge loading with

Re: dvb usb issues since kernel 4.9

On Tue, 9 Jan 2018 10:58:30 -0800 Linus Torvalds wrote: > So I really think "you can use up 90% of CPU time with a UDP packet > flood from the same network" is very very very different - and > honestly not at all as important - as "you want to be able to use a > USB DVB receiver and watch/recor

Re: [GIT PULL] usb: chipidea: updates for v4.16-rc1

On Wed, Jan 10, 2018 at 09:19:06AM +0800, Peter Chen wrote: > The following changes since commit 16e791e7659645e6d8ea6286d210a24ee473d6c2: > > doc: usb: chipidea: Fix typo in 'enumerate' (2017-12-08 17:43:53 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/

Re: Help needed debugging Motorola Solutions TETRA PEI interface

Please keep linux-usb on CC. On Wed, Jan 10, 2018 at 10:01:40AM +0100, Max Schulze wrote: > > > Yeah, that's not a CDC device so usb-serial is the right subsystem for > > this one. > > > >>> Yeah, this is expected since you will not be able to do modem control > >>> when using the generic driver.

Re: [PATCH] usb: dwc2: Fix endless deferral probe

Hi Arnd, Am 09.01.2018 um 22:33 schrieb Arnd Bergmann: On Tue, Jan 9, 2018 at 8:28 PM, Stefan Wahren wrote: The dwc2 USB driver tries to find a generic PHY first and then look for an old style USB PHY. In case of a valid generic PHY node without a PHY driver, the PHY layer will return -EPROBE_

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi Manu, On 27/09/17 14:19, Manu Gautam wrote: > Driver powers-off PHYs and reinitializes DWC3 core and gadget on > resume. While this works fine for gadget mode but in host > mode there is not re-initialization of host stack. Also, resetting > bus as part of bus_suspend/resume is not correct whic

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Roger Quadros writes: > Hi Manu, > > On 27/09/17 14:19, Manu Gautam wrote: >> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >> resume. While this works fine for gadget mode but in host >> mode there is not re-initialization of host stack. Also, resetting >> bus as part of

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

On 10/01/18 14:57, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> Hi Manu, >> >> On 27/09/17 14:19, Manu Gautam wrote: >>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >>> resume. While this works fine for gadget mode but in host >>> mode there is not re-initializat

[PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

The USB PHYs should be requested only once during the life cycle of this driver. As dwc3_core_init() is called during system suspend/resume it will result in multiple calls to dwc3_core_get_phy() which is wrong. To prevent that let's move dwc3_core_get_phy() call outside dwc3_core_init(). Fixes:

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Felipe, On 10/01/18 15:11, Roger Quadros wrote: > The USB PHYs should be requested only once during the life cycle of > this driver. > > As dwc3_core_init() is called during system suspend/resume > it will result in multiple calls to dwc3_core_get_phy() which is wrong. > > To prevent that let's

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: > Felipe, > > On 10/01/18 15:11, Roger Quadros wrote: >> The USB PHYs should be requested only once during the life cycle of >> this driver. >> >> As dwc3_core_init() is called during system suspend/resume >> it will result in multiple calls to dwc3_core_get_phy() whic

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

On 10/01/18 15:33, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> Felipe, >> >> On 10/01/18 15:11, Roger Quadros wrote: >>> The USB PHYs should be requested only once during the life cycle of >>> this driver. >>> >>> As dwc3_core_init() is called during system suspend/resume >>> it wil

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: >> Roger Quadros writes: >>> Felipe, >>> >>> On 10/01/18 15:11, Roger Quadros wrote: The USB PHYs should be requested only once during the life cycle of this driver. As dwc3_core_init() is called during system suspend/resume it will result in m

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

On 10/01/18 16:04, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >>> Roger Quadros writes: Felipe, On 10/01/18 15:11, Roger Quadros wrote: > The USB PHYs should be requested only once during the life cycle of > this driver. > > As dwc3_core_init() is cal

Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

On 2017-12-20 12:54, Jarkko Nikula wrote: > On Wed, Dec 20, 2017 at 10:32:11AM +0100, Greg Kroah-Hartman wrote: >> On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote: >>> On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote: On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wr

Re: [PATCH] uas: Unblock scsi-requests on failure to alloc streams in post_reset

Am Mittwoch, den 10.01.2018, 08:13 +0100 schrieb Hans de Goede: > If we return 1 from our post_reset handler, then our disconnect handler > will be called immediately afterwards. Since pre_reset blocks all scsi > requests our disconnect handler will then hang in the scsi_remove_host > call. Hi Han

[PATCH] usb: mtu3: fix ssusb_wakeup_set dummy

Changing from ssusb_wakeup_enable/disable to ssusb_wakeup_set was done in only one of two places in the kernel, the other one now causes a build failure: drivers/usb/mtu3/mtu3_plat.c: In function 'mtu3_suspend': drivers/usb/mtu3/mtu3_plat.c:462:2: error: implicit declaration of function 'ssusb_wa

[PATCH 0/2] Add driver for Xaptum ENF Access card (XAP-EA-00x)

This series add a driver for the Xaptum ENF Access card line (XAP-EA-00x), a series of mini PCI-e cards containing a TPM 2.0 chip used to authenticate IoT devices and gateways. The hardware is essentially a USB-SPI bridge and an SPI TPM 2.0 chip. The first patch registers the bridge as an SPI cont

[PATCH 2/2] usb: misc: xapea00x: perform platform initialization of TPM

Normally the system platform (i.e., BIOS/UEFI for x86) is responsible for performing intialization of the TPM. For these modules, the host kernel is the platform, so we perform the initialization in the driver before registering the TPM with the kernel TPM subsystem. The initialization consists o

[PATCH 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0 hardware module for authenticating IoT devices and gateways. The card consists of a SPI TPM 2.0 chip and a USB-SPI bridge. This driver configures the bridge, registers the bridge as an SPI controller, and adds the TPM 2.0 as an SPI

Re: [PATCH] uas: Unblock scsi-requests on failure to alloc streams in post_reset

Hi, On 10-01-18 16:23, Oliver Neukum wrote: Am Mittwoch, den 10.01.2018, 08:13 +0100 schrieb Hans de Goede: If we return 1 from our post_reset handler, then our disconnect handler will be called immediately afterwards. Since pre_reset blocks all scsi requests our disconnect handler will then ha

Re: [PATCH] phy: work around 'phys' references to usb-phy devices

On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I wrote: > Hi Arnd, > > On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote: >> Stefan Wahren reports a problem with a warning fix that was merged >> for v4.15: we had lots of device nodes with a 'phys' property pointing >> to a device node

[PATCH v2 0/2] usb: dwc3: Properly update ep0 for IN direction

This patch series fixes an issue with HS/FS 3-stage control read transfer where DWC3 incorrectly check when to send ZLP. Changes in v2: - Separate from "usb: dwc3: Add new updates for DWC_usb31" patch series - Add 'Cc' to stable mailing list Thinh Nguyen (2): usb: dwc3: gadget: Set maxpacket

[PATCH v2 1/2] usb: dwc3: gadget: Set maxpacket size for ep0 IN

There are 2 control endpoint structures for DWC3. However, the driver only updates the OUT direction control endpoint structure during ConnectDone event. DWC3 driver needs to update the endpoint max packet size for control IN endpoint as well. If the max packet size is not properly set, then the dr

[PATCH v2 2/2] usb: dwc3: ep0: Reset TRB counter for ep0 IN

In control read transfer completion handler, the driver needs to reset the TRB enqueue counter. Since there is one control endpoint structure for each direction, we must also track the TRB enqueue counter for each direction. Currently the driver only resets the TRB counter for control OUT endpoint

[PATCH v2 00/14] usb: dwc3: Add new updates for DWC_usb31

This patch series adds new updates and some fixes for DWC_usb31. Changes in v2: - Add another patch to the series to increase mass_storage max_speed - Separate "usb: dwc3: ep0: Reset TRB counter for ep0 IN" from series - Separate "usb: dwc3: gadget: Set maxpacket size for ep0 IN" from series -

[PATCH v2 01/14] usb: dwc3: Add SoftReset PHY synchonization delay

>From DWC_usb31 databook section 1.3.2, once DWC3_DCTL_CSFTRST bit is cleared, we must wait at least 50ms before accessing the PHY domain (synchronization delay). Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/core.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --g

[PATCH v2 03/14] usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields

Update two GTXFIFOSIZ bit fields for the DWC_usb31 controller. TXFDEP is a 15-bit value instead of 16-bit value, and bit 15 is TXFRAMNUM. The GTXFIFOSIZ register for DWC_usb31 is as follows: +---+---+--+ | BITS | Name | Description

[PATCH v2 05/14] usb: dwc3: Add DWC_usb31 GRXTHRCFG bit fields

Add new GRXTHRCFG bit field macros for DWC_usb31. The GRXTHRCFG register fields for DWC_usb31 is as follows: +---+--+--+ | BITS | Name | Description | +===+==+===

[PATCH v2 02/14] usb: core: urb: Check SSP isoc ep comp descriptor

The maximum bytes per interval for USB SuperSpeed Plus can be set by isoc endpoint companion descriptor when it is above 48K. If the descriptor is provided, then use its value. USB 3.1 spec 9.6.8 Signed-off-by: Thinh Nguyen --- drivers/usb/core/urb.c | 8 1 file changed, 8 insertions(+

[PATCH v2 04/14] usb: dwc3: Check IP revision for GTXFIFOSIZ

DWC_usb31 controller has different GTXFIFOSIZE bit field for TXFDEF. Check for DWC_usb31 IP revision to read the appropriate bit fields. Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/gadget.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/d

[PATCH v2 06/14] usb: dwc3: gadget: Check IP revision for GRXTHRCFG

DWC_usb31 controller has a different UsbRxPktCnt bit fields from GRXTHRCFG register. Check for DWC_usb31 IP revision to read the appropriate value. Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/gadget.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/

[PATCH v2 07/14] usb: dwc3: Add DWC_usb31 GTXTHRCFG reg fields

Add new GTXTHRCFG bit field macros for DWC_usb31. The GTXTHRCFG register fields for DWC_usb31 is as follows: +---+--+---+ | BITS | Name | Description | +===+==+=

[PATCH v2 08/14] usb: dwc3: Make TX/RX threshold configurable

DWC_usb31 periodic transfer at 48K+ bytes per interval may need modification to the TX/RX packet threshold to achieve optimal result. Add properties to make it configurable. Cc: John Youn Signed-off-by: Thinh Nguyen --- Documentation/devicetree/bindings/usb/dwc3.txt | 4 1 file changed, 4

[PATCH v2 09/14] usb: dwc3: Check for ESS TX/RX threshold config

Check and configure TX/RX threshold for DWC_usb31. Update dwc3 structure with new fields to store these threshold configurations. Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/core.c | 55 + drivers/usb/dwc3/core.h | 8 +++ 2 files changed,

[PATCH v2 11/14] usb: dwc3: Track DWC_usb31 VERSIONTYPE

Add a new field to dwc3 structure to track VERSIONTYPE. The VERSIONTYPE is represented in ASCII in the 32-bit VERSIONTYPE register. In DWC_usb31, sub releases for each version are tracked with VERSIONTYPE such as "ea01" and "ea02". Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/core.c | 2 ++

[PATCH v2 12/14] usb: dwc3: Add disabling of start_transfer failure quirk

In DWC_usb31 version 1.70a-ea06 and prior needs a SW workaround for isoc START TRANSFER command failure. However, some affected versions may have RTL patches to fix this without a SW workaround. Add this quirk to disable the SW workaround when it is not needed. Synopsys STAR 9001202023: Wrong micr

[PATCH v2 10/14] usb: dwc3: Dump LSP and BMU debug info

Dump LSP and BMU debug info. Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/core.h| 5 + drivers/usb/dwc3/debugfs.c | 5 + 2 files changed, 10 insertions(+) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index e53ae6038bbe..fd794972802d 100644 --- a/drivers/usb/dwc

[PATCH v2 14/14] usb: gadget: mass_storage: Set max_speed to SSP

Increase max_speed of the mass_storage driver for UDCs that support SuperSpeed Plus. The composite driver will pass this value to UDC core to set the device speed on probe (actual speed may be different depending on whether the USB controller supports it or other external factors). Signed-off-by:

[PATCH v2 13/14] usb: dwc3: Add workaround for isoc start transfer failure

In DWC_usb31 version 1.70a-ea06 and prior, for highspeed and fullspeed isochronous IN, BIT[15:14] of the 16-bit microframe number reported by the XferNotReady event are invalid. The driver uses this number to schedule the isochronous transfer and passes it to the START TRANSFER command. Because thi

Re: [PATCH] usb: mtu3: fix ssusb_wakeup_set dummy

On Wed, 2018-01-10 at 17:45 +0100, Arnd Bergmann wrote: > Changing from ssusb_wakeup_enable/disable to ssusb_wakeup_set was done > in only one of two places in the kernel, the other one now causes a > build failure: > > drivers/usb/mtu3/mtu3_plat.c: In function 'mtu3_suspend': > drivers/usb/mtu3/m

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Wed, Jan 10, 2018 at 10:26 AM, Ulf Hansson wrote: > On 9 January 2018 at 17:28, Rafael J. Wysocki wrote: >> On Tuesday, January 9, 2018 5:03:18 PM CET Rafael J. Wysocki wrote: >>> On Tue, Jan 9, 2018 at 4:30 PM, Geert Uytterhoeven >>> wrote: [cut] >>> That's because of the pm_runtime_force

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, On 1/10/2018 6:18 PM, Roger Quadros wrote: > Hi Manu, > > On 27/09/17 14:19, Manu Gautam wrote: >> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >> resume. While this works fine for gadget mode but in host >> mode there is not re-initialization of host stack. Also, resettin

[PATCH V3 6/6] usb: serial: f81534: fix tx error on some baud rate

The F81532/534 had 4 clocksource 1.846/18.46/14.77/24MHz and baud rates can be up to 1.5Mbits with 24MHz. But on some baud rate (384~500kps), the TX side will send the data frame too close to treat frame error on RX side. This patch will force all TX data frame with delay 1bit gap. Signed-off-by:

[PATCH V3 5/6] usb: serial: f81534: add H/W disable port support

The F81532/534 can be disable port by manufacturer with following H/W design. 1: Connect DCD/DSR/CTS/RI pin to ground. 2: Connect RX pin to ground. In driver, we'll implements some detect method likes following: 1: Read MSR. 2: Turn MCR LOOP bit on, off and read LSR after delay wit

[PATCH V3 1/6] usb: serial: f81534: add high baud rate support

The F81532/534 had 4 clocksource 1.846/18.46/14.77/24MHz and baud rates can be up to 1.5Mbits with 24MHz. This device may generate data overrun when baud rate setting to 921600bps or higher with old UART trigger level setting (8x14=112) with full loading. We'll change trigger level from 8x14=112 t

[PATCH V3 4/6] usb: serial: f81534: refactoring calc_num_ports()

In the original code, We'll read configuration in calc_num_ports() and read again in attach(). In fact, we can move all content from attach() to calc_num_ports() to simplify the code. Signed-off-by: Ji-Ze Hong (Peter Hong) --- V3: 1: First introduced in this series patches. drivers/usb/

[PATCH V3 3/6] usb: serial: f81534: add output pin control

The F81532/534 had 3 output pin (M0/SD, M1, M2) with open-drain mode to control transceiver. We'll read it from internal Flash with address 0x2f05~0x2f08 for 4 ports. The value is range from 0 to 7. The M0/SD is MSB of this value. For a examples, If read value is 6, we'll write M0/SD, M1, M2 as 1,

[PATCH V3 2/6] usb: serial: f81534: add auto RTS direction support

The F81532/534 had auto RTS direction support for RS485 mode. We'll read it from internal Flash with address 0x2f01~0x2f04 for 4 ports. There are 4 conditions below: 0: F81534_PORT_CONF_RS232. 1: F81534_PORT_CONF_RS485. 2: value error, default to F81534_PORT_CONF_RS232.