Re: [PATCH 0/7] staging: dwc2: miscellaneous cleanups

Hi Greg, On Thu, May 16, 2013 at 03:26:25PM -0700, Greg KH wrote: > On Mon, May 13, 2013 at 07:08:05PM -0700, Paul Zimmerman wrote: > > Here are some dwc2 patches which Matthijs submitted just before the merge > > window opened, looks like they did not get picked up. Please apply. > > I think I j

Re: [PATCH 03/10] usb: phy: ab8500-usb: add transceiver clock control

On 15 May 2013 14:03, Fabio Baltieri wrote: > From: Mian Yousaf Kaukab > > Add common clock support code for the ab8500-usb phy driver. > > Acked-by: Linus Walleij > Acked-by: Maxime Coquelin > Signed-off-by: Mian Yousaf Kaukab > Signed-off-by: Fabio Baltieri > --- > drivers/usb/phy/phy-ab85

[PATCH] staging: dwc2: Fix dma-enabled platform devices using a default dma_mask

Platform devices added through OF usually do not have any dma_mask pointer set. If the hardware advertises DMA support, the driver will expect DMA buffers to be passed in, but the USB core will not do this due to lack of a dma mask, breaking all connectiviy. To fix this, set a default dma_mask by

Re: Crash in dwc3 driver on module unload

> I found out a couple more things about this. > > If I do "rmmod dwc3" first, and then do "rmmod dwc3-pci", it doesn't > crash. > dwc3-pci will release dwc3 and its resources at its removal. So, dwc3 core must be released first, then glue layer. Since there are no relationship between core and g

Re: [PATCH v4] usb host: Faraday USB2.0 FUSBH200-HCD driver

On Fri, May 17, 2013 at 8:45 AM, Greg KH wrote: > On Fri, Apr 26, 2013 at 09:37:20AM +, Yuan-Hsin Chen wrote: >> FUSBH200-HCD is an USB2.0 hcd for Faraday FUSBH200. >> FUSBH200 is an ehci-like controller with some differences. >> First, register layout of FUSBH200 is incompatible with EHCI. >>

[PATCH 01/12] usb: chipidea: ci13xxx_imx: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat Cc: Marek Vasut Cc: Alexander Shishkin --- drivers/usb/chipidea/ci13xxx_imx.c |2 -- 1 file changed, 2 deletions(-) diff --git a/dr

[PATCH 02/12] usb: gadget: mv_u3d_core: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat Cc: Yu Xu --- drivers/usb/gadget/mv_u3d_core.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/usb/gadget/mv_u3d_core.c

[PATCH 03/12] usb: gadget: pxa27x_udc: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat Cc: Eric Miao --- drivers/usb/gadget/pxa27x_udc.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/gadget/pxa27x_udc.c b

[PATCH 04/12] usb: host: ehci-tilegx: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat Cc: Alan Stern --- drivers/usb/host/ehci-tilegx.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/ehci-tilegx.c b/

[PATCH 05/12] usb: host: ohci-da8xx: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat --- drivers/usb/host/ohci-da8xx.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/o

[PATCH 06/12] usb: host: ohci-nxp: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat Cc: Dmitry Chigirev --- drivers/usb/host/ohci-nxp.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/host/ohci-nxp.c b

[PATCH 07/12] usb: host: ohci-octeon: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat --- drivers/usb/host/ohci-octeon.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/host/ohci-octeon.c b/drivers/usb/ho

[PATCH 08/12] usb: host: ohci-omap: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat Cc: Tony Lindgren --- drivers/usb/host/ohci-omap.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/ohci-omap.c b/d

[PATCH 09/12] usb: host: ohci-tilegx: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat --- drivers/usb/host/ohci-tilegx.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/ohci-tilegx.c b/drivers/usb/host

[PATCH 10/12] usb: host: ohci-tmio: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat --- drivers/usb/host/ohci-tmio.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/o

[PATCH 11/12] usb: host: oxu210hp-hcd: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat Cc: Rodolfo Giometti --- drivers/usb/host/oxu210hp-hcd.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/host/oxu210h

[PATCH 12/12] usb: host: uhci-platform: Remove redundant platform_set_drvdata()

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat Cc: Tony Prisk --- drivers/usb/host/uhci-platform.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/uhci-platform.

Huawei 3276 with option and cdc_ncm

Hi, the LTE-stick huawei 3276 (in Germany also alias "Telekom Speedstick LTE III") works well with linux. (also IPv6) Here is the output of dmesg (IPv4-connection). at^ndisdup=1,1,"internet.telekom" OK ^NDISSTAT:1,,,"IPV4" [ 97.342188] usb 1-1: new high-speed USB device number 3 using

Re: Huawei 3276 with option and cdc_ncm

Thomas Schäfer writes: > Hi, > > the LTE-stick huawei 3276 (in Germany also alias "Telekom Speedstick > LTE III") works well with linux. (also IPv6) Thanks. We have many reports that it works as expected for IPv4, but I believe this is the first one for IPv6. Not that it is surprising, but yo

[RFC PATCH 4/4] arm: omap: remove using usb_bind_phy for binding musb and phy

Now that MUSB for OMAP started using devm_usb_get_phy_by_name which does not require PHY library to already have the binding information, removed usb_bind_phy calls that binds the MUSB controller with the PHY from the board files. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/mach-omap2/boa

[RFC PATCH 3/4] usb: musb: omap: use the new API to get PHY reference by label

After the devices are created using PLATFORM_DEVID_AUTO, devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably as it relies on the device_names passed in usb_bind_phy. So used the new API devm_usb_get_phy_by_name to get the PHY reference. Signed-off-by: Kishon Vijay Abraham I --- drive

[RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data

In order for controllers to get PHY in case of non dt boot, the phy binding information (phy label) should be added in the platform data of the controller. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/mach-omap2/usb-musb.c |6 +- include/linux/usb/musb.h |3 +++ 2 files c

[RFC PATCH 2/4] usb: phy: add a new API to get PHY ref by label

After the devices are created using PLATFORM_DEVID_AUTO, devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably as it relies on the device_names passed in usb_bind_phy. So added a new API to get the PHY reference by PHY label (PHY label should be filled which creating the PHY). Signed-off

[RFC PATCH 0/4] Add usb2 link powermanagement BESL support

This series adds usb2 best effort service latency (BESL) link PM support to xHCI. BESL is an updated alternative to host initated resume delay (HIRD) method of describing idle link timeouts. Additionally this series fixes port capability checking and replaces magic numbers with port register name

[RFC PATCH 1/4] usb: xhci: check usb2 port capabilities before adding hw link PM support

Hardware link powermanagement in usb2 is a per-port capability. Previously support for hw lpm was enabled for all ports if any usb2 port supported it. Now instead cache the capability values and check them for each port individually Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci-mem.c

[RFC PATCH 2/4] usb: xhci: define port register names and use them instead of magic numbers

Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci-hub.c | 16 +++- drivers/usb/host/xhci.c |4 ++-- drivers/usb/host/xhci.h |5 + 3 files changed, 14 insertions(+), 11 deletions(-) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index

[RFC PATCH 3/4] usb: xhci: add USB2 Link power management BESL support

usb 2.0 devices with link power managment (LPM) can describe their idle link timeouts either in BESL or HIRD format, so far xHCI has only supported HIRD but later xHCI errata add BESL support as well BESL timeouts need to inform exit latency changes with an evaluate context command the same way US

[RFC PATCH 4/4] usb: add usb2 Link PM variables to sysfs and usb_device

Adds abitilty to tune L1 timeout (inactivity timer for usb2 link sleep) and BESL (best effort service latency)via sysfs. This also adds a new usb2_lpm_parameters structure with those variables to struct usb_device. Signed-off-by: Mathias Nyman --- drivers/usb/core/sysfs.c | 54 +++

Re: [PATCH v7 7/9] rcar-phy: add platform data

On Wed, May 01, 2013 at 03:00:30AM +0400, Sergei Shtylyov wrote: > Currently the driver hard-codes USBPCTRL0 register to 0. It is wrong since > this > register contains board-specific USB ports configuration and so its value > should > be somehow passed via the platform data. Add the global hea

Re: usb:is that a bug?

On Fri, 17 May 2013, linux fddl wrote: > Hi, > > When I used mass_storage as a gadget You should CC: the maintainer of the g_mass_storage driver. > (use a linux-3.0.77 kernel), That kernel is pretty old. You would be much better off using 3.9. The problem you found may already have been fix

Re: Crash in dwc3 driver on module unload

On Fri, 17 May 2013, Peter Chen wrote: > > I found out a couple more things about this. > > > > If I do "rmmod dwc3" first, and then do "rmmod dwc3-pci", it doesn't > > crash. > > > > dwc3-pci will release dwc3 and its resources at its removal. > So, dwc3 core must be released first, then glue la

[PATCH 1/5] usb: add Atmel USBA UDC DT support

Allow to compile the driver all the time if AT91 enabled. Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Cc: Nicolas Ferre Cc: linux-usb@vger.kernel.org --- .../devicetree/bindings/usb/atmel-usb.txt | 82 drivers/usb/gadget/Kconfig |2 +- drivers

Re: [RFC PATCH 4/4] usb: add usb2 Link PM variables to sysfs and usb_device

On Fri, 17 May 2013, Mathias Nyman wrote: > Adds abitilty to tune L1 timeout (inactivity timer for usb2 link sleep) > and BESL (best effort service latency)via sysfs. > > This also adds a new usb2_lpm_parameters structure with those variables to > struct usb_device. > +static ssize_t > +set_usb2

drivers/usb/core/devio.c, USB3.0 and "arbitrary limit for USB2"

With USB2.0 the max isochronous size can be 3x1024 byte every 125us With USB3.0 the max isochronous size can be 1x1024 byte * Mult * bMaxBurst every 125us super speed companion descriptor. bMaxBurst (0~15 allowed, 1~16 packets) super speed companion descriptor. bmAttributes (bit 1:0, mult 0~2)

[PATCH 0/5 v3] ARM: at91: dt: add USBA support

HI, v3: rebase againt 3.10-rc1 + dt macro cleanup This patch serie finish to add the usb device support to dt for at91 with the usba support present on the last at91 generation since sam9g45 The following changes since commit b3f442b0eedbc20b5ce3f4a96530588d149011

RE: [PATCH] staging: dwc2: Fix dma-enabled platform devices using a default dma_mask

> From: Matthijs Kooijman [mailto:matth...@stdin.nl] > Sent: Friday, May 17, 2013 1:53 AM > > Platform devices added through OF usually do not have any dma_mask > pointer set. If the hardware advertises DMA support, the driver will > expect DMA buffers to be passed in, but the USB core will not do

[PATCH] USB:ftdi_sio: Add support for Newport CONEX motor drivers

Here are two more devices that use FTDI USB-to-serial chips with new product ID's. The devices are the Newport Conex-AGP and Conex-CC motor controllers. (http://www.newport.com/CONEX-AGP-Integrated-Piezo-Motor-Rotation-Stages-/987623/1033/info.aspx) (http://www.newport.com/CONEX-CC-DC-Servo-Con

Re: [RFT 0/2] TI compliance mode fixes

Sarah, These patches allow return-from-hibernate to work with the latest upstream tree at commit 8f710dd34a46500e135203816c71c3ec567c46fd However, while the restore from hibernate worked, patch 2/2 introduced the following call trace. With just 1/2 applied, the trace does not appear. firewir

[PATCH v4] usb: ehci: Only sleep for post-resume handover if devices use persist

The current EHCI code sleeps a flat 110ms in the resume path if there was a USB 1.1 device connected to its companion controller during suspend, waiting for the device to reappear and reset so that it can be handed back to the companion. This is necessary if the device uses persist, so that the com

Re: Question about dummy_hcd

On Fri, 17 May 2013, Jean-Edouard Lejosne wrote: > Hi, > > I'm Jed, I'm currently using dummy_hcd and g_hid to fake a USB HID > device, and I'm struggling with a problem. > > I'm sorry to bother you by e-mail. If I should ask my question on an IRC > channel, could you please point me to the ri

Re: Question about dummy_hcd

On 05/17/2013 03:16 PM, Alan Stern wrote: On Fri, 17 May 2013, Jean-Edouard Lejosne wrote: Hi, I'm Jed, I'm currently using dummy_hcd and g_hid to fake a USB HID device, and I'm struggling with a problem. I'm sorry to bother you by e-mail. If I should ask my question on an IRC channel, could

Re: [PATCH Resend 1/2] net/usb: r8152: Remove redundant version.h header inclusion

From: Sachin Kamat Date: Fri, 17 May 2013 09:18:07 +0530 > version.h header inclusion is not necessary as detected by > checkversion.pl. > > Signed-off-by: Sachin Kamat Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.k

Re: [PATCH Resend 2/2] net/usb: r8152: Use module_usb_driver()

From: Sachin Kamat Date: Fri, 17 May 2013 09:18:08 +0530 > module_usb_driver() eliminates boilerplate and simplifies the code. > > Signed-off-by: Sachin Kamat Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org

Re: [PATCH v4 3/8] ARM: tegra: update device trees for USB binding rework

On 05/16/2013 05:02 PM, Stephen Warren wrote: > On 05/16/2013 08:12 AM, Venu Byravarasu wrote: >> This patch updates all Tegra board files so that they contain all the >> properties required by the updated USB DT binding. Note that this patch >> only adds the new properties and does not yet remove

[GIT PULL] ARM: tegra: DT-related fixes needed by the USB tree

Felipe, (and Alan, Greg), These are the changes from the Tegra tree that need to be merged before the Tegra USB driver patches 4-8 from Venu can be applied. Recall that we had previously agreed on this approach for v3.9, but Venu's patches didn't end up being ready until now, unfortunately. I note

Question about "generic" HID devices

Hello. I'm working on a driver for a USB to SPI bridge chip (Microchip's MCP2210) that acts as a HID device (generic subclass). Of course, it can be used from user-space via hid-generic, but I'm not really interested in that. I started this work from somebody else's implementation that was a H

Re: Question about "generic" HID devices

On Fri, May 17, 2013 at 06:14:28PM -0500, Daniel Santos wrote: > Anyway, if somebody has some advice, I would greatly appreciate it. > I'm combing through the USB 2 spec to try to find where the HID > protocol is covered, but maybe that's an entirely different spec? > Advice greatly appreciated!!