Re: [PATCH] phy: qcom-qmp: Fix failure path in phy_init functions

On Wed, Aug 2, 2017 at 10:39 AM, Kishon Vijay Abraham I wrote: > Vivek, > > On Monday 31 July 2017 10:58 AM, Vivek Gautam wrote: >> Hi Kishon, >> >> >> On Tue, Jun 20, 2017 at 11:27 AM, Vivek Gautam >> wrote: >>> Fixing the clk enable failure path in

Re: [PATCH 3/5] phy: phy-bcm-ns2-usbdrd: Replace the deprecated extcon API

On Monday 17 July 2017 06:50 AM, Chanwoo Choi wrote: > This patch replaces the deprecated extcon API as following: > - extcon_set_cable_state_() -> extcon_get_state() > > Cc: Kishon Vijay Abraham I > Cc: Raviteja Garimella > Signed-off-by:

Re: [PATCH 2/5] phy: rockchip-inno-usb2: Replace the extcon API

On Monday 17 July 2017 06:50 AM, Chanwoo Choi wrote: > This patch uses the resource-managed extcon API for extcon_register_notifier() > and replaces the deprecated extcon API as following: > - extcon_get_cable_state_() -> extcon_get_state() > - extcon_set_cable_state_() ->

Re: [PATCH] phy: qcom-qmp: Fix failure path in phy_init functions

Vivek, On Monday 31 July 2017 10:58 AM, Vivek Gautam wrote: > Hi Kishon, > > > On Tue, Jun 20, 2017 at 11:27 AM, Vivek Gautam > wrote: >> Fixing the clk enable failure path in qcom_qmp_phy_init() >> and cleanup the reset control deassertion failure path in >>

[PATCH] usb: renesas_usbhs: Fix UGCTRL2 value for R-Car Gen3

The latest HW manual (Rev.0.55) shows us this UGCTRL2.VBUSSEL bit. If the bit sets to 1, the VBUS drive is controlled by phy related registers (called "UCOM Registers" on the manual). Since R-Car Gen3 environment will control VBUS by phy-rcar-gen3-usb2 driver, the UGCTRL2.VBUSSEL bit should be set

Re: [PATCH] USB: Check for dropped connection before switching to full speed

On 08/01/2017 07:41 AM, Alan Stern wrote: Some buggy USB disk adapters disconnect and reconnect multiple times during the enumeration procedure. This may lead to a device connecting at full speed instead of high speed, because when the USB stack sees that a device isn't able to enumerate at

Re: [PATCH 0/2] Workaround for uPD72020x USB3 chips

On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote: > Ard and myself have just spent quite some time lately trying to pin > down an issue in the DMA code which was taking the form of a PCIe USB3 > controller issuing a DMA access at some bizarre address, and being > caught red-handed by

Re: [PATCH 0/2] Workaround for uPD72020x USB3 chips

On 1 August 2017 at 22:44, Bjorn Helgaas wrote: > On Thu, Jul 13, 2017 at 10:26:40AM +0200, Greg Kroah-Hartman wrote: >> On Wed, Jul 12, 2017 at 10:12:34PM -0500, Bjorn Helgaas wrote: >> > On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote: >> > > Ard and myself have

Re: [PATCH 0/2] Workaround for uPD72020x USB3 chips

On Thu, Jul 13, 2017 at 10:26:40AM +0200, Greg Kroah-Hartman wrote: > On Wed, Jul 12, 2017 at 10:12:34PM -0500, Bjorn Helgaas wrote: > > On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote: > > > Ard and myself have just spent quite some time lately trying to pin > > > down an issue in

gadget serial oops in gs_write_room when data rx'd after close

Felipe, I've found a problem in the gadget serial driver, which I believe is triggered in the following scenario: 1) Both host and gadget system have a USB gadget serial port open. 2) Gadget side application closes the serial port. 3) Host side sends data to the serial port. (Steps 2, 3

Re: [PATCH 1/2] usb: option: add D-Link DWM-222 device ID

On Wed, Aug 02, 2017 at 12:45:06AM +0900, Hector Martin wrote: I'll fix it up this time, but please make sure to include a proper commit message in the future. > Cc: sta...@vger.kernel.org > Signed-off-by: Hector Martin Now applied, thanks. Johan -- To unsubscribe from this

Bug 196559: xhci_hcd: kernel panic using thunderbolt dell dock TB16 on 4.12.4

I'm running archlinux on a Dell XPS15 9550 and I connect it to a TB16 thunderbolt dock. Connected to the dock I have a 4k external display and a USB logitech transmitter for my wireless keyboard and mouse. The TB16 dock is a finicky beast and doesn't currently work 100% with linux. However,

[PATCH 2/2] usb: qmi_wwan: add D-Link DWM-222 device ID

Cc: sta...@vger.kernel.org Signed-off-by: Hector Martin --- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 5894e3c9468f..ff6f39fe6c00 100644 --- a/drivers/net/usb/qmi_wwan.c +++

[PATCH 1/2] usb: option: add D-Link DWM-222 device ID

Cc: sta...@vger.kernel.org Signed-off-by: Hector Martin --- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index ebe51f11105d..fe123153b1a5 100644 --- a/drivers/usb/serial/option.c +++

[PATCH] USB: Check for dropped connection before switching to full speed

Some buggy USB disk adapters disconnect and reconnect multiple times during the enumeration procedure. This may lead to a device connecting at full speed instead of high speed, because when the USB stack sees that a device isn't able to enumerate at high speed, it tries to hand the connection

RE: [PATCH] usb: gadget: core: unmap request from DMA only if previously mapped

Hi Jack-san, > -Original Message- > From: Jack Pham > Sent: Tuesday, August 1, 2017 6:01 PM > Subject: [PATCH] usb: gadget: core: unmap request from DMA only if previously > mapped > > In the SG case this is already handled since a non-zero > request->num_mapped_sgs is a clear indicator

Re: [PATCH 2/3] gpio: Add FT232H CBUS GPIO driver

On Tue, Aug 01, 2017 at 08:49:02AM +0200, Linus Walleij wrote: > On Thu, Jul 6, 2017 at 10:49 PM, Anatolij Gustschin wrote: > > > Add driver for CBUS pins on FT232H. The driver supports setting > > GPIO direction and getting/setting CBUS 0-3 pin value. The CBUS > > pins have to be

[PATCH] usb: gadget: core: unmap request from DMA only if previously mapped

In the SG case this is already handled since a non-zero request->num_mapped_sgs is a clear indicator that dma_map_sg() had been called. While it would be nice to do the same for the singly mapped case by simply checking for non-zero request->dma, it's conceivable that 0 is a valid dma_addr_t

[PATCH] usb: xhci: fix call_kern.cocci warnings

GFP_KERNEL used when a lock is held. Convert to GFP_ATOMIC to avoid the possibility of deadlock. Fixes: 725d53536473 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Julia Lawall Signed-off-by: Fengguang Wu --- I don't have access to

Re: [PATCH 2/3] gpio: Add FT232H CBUS GPIO driver

On Thu, Jul 6, 2017 at 10:49 PM, Anatolij Gustschin wrote: > Add driver for CBUS pins on FT232H. The driver supports setting > GPIO direction and getting/setting CBUS 0-3 pin value. The CBUS > pins have to be enabled by configuring I/O mode in the FTDI EEPROM. > > Signed-off-by:

[PATCH v2 1/1] usb: xhci: Add debugfs interface for xHCI driver

This adds debugfs consumer for xHCI driver. The debugfs entries read all host registers, device/endpoint contexts, command ring, event ring and various endpoint rings. With these entries, users can check the registers and memory spaces used by a host during run time, or save all the information