Re: mass storage behaviour

On Tue, 6 Oct 2015, Paul Jones wrote: > On 05 Oct 2015, at 23:09, Alan Stern wrote: > > > On Mon, 5 Oct 2015, Paul Jones wrote: > > > >>> Increasing the max_sectors_kb value, on the other hand, might remove > >>> overhead by allowing a higher percentage of the

Re: mass storage behaviour

John Youn writes: > Hi Paul, > > Good to see you're still hanging around. > > On 10/5/2015 3:38 PM, Paul Zimmerman wrote: >> On Mon, 5 Oct 2015, Alan Stern wrote: >>> On Mon, 5 Oct 2015, Paul Jones wrote: >>> > Increasing the max_sectors_kb value, on the other hand,

RE: Configfs composite gadget with CCID and mass storage

> ConfigFS is used to compose a gadget of existing functions. > As far as I can tell there is no smart card CCID usb function in kernel, so > either you need to have your own out-of-tree implementation or implement it > in userspace with FunctionFS. I also could not find a CCID usb function in

Re: [PATCH v9 3/5] phy: add usb3.0 phy driver for mt65xx SoCs

Hi Chunfeng, On Tuesday 29 September 2015 08:31 AM, Chunfeng Yun wrote: > support usb3.0 phy of mt65xx SoCs I have merged this driver. Can you also send a patch adding yourself as the maintainer of this driver? Thanks Kishon > > Signed-off-by: Chunfeng Yun > --- >

Re: Aw: Re: Intel XHCI: random URB_INTERRUPTs triggering port resets and device disconnects

On Tue, 6 Oct 2015, Eugen Rogoza wrote: > > The only way to turn off Link Power Management currently is to disable > > CONFIG_PM entirely. > > I recompiled the 4.2.0 having disabled CONFIG_PM: > > # CONFIG_PM is not set > > This time there were no observable disconnects after just plugging in

[PATCH V9] dt: add NVIDIA Tegra XUSB controller binding

From: Stephen Warren Add device-tree binding documentation for the XUSB (xHCI) controller present on Tegra124 and later SoCs. Signed-off-by: Andrew Bresticker [swarren, combined separate MFD, mailbox, XHCI bindings into one node] Signed-off-by:

Re: Multiple drives on JMS56x-based sata-usb docking station.

On Tue, 2015-10-06 at 14:46 -0400, Alan Stern wrote: > On Tue, 6 Oct 2015, Daniel Ranger wrote: > > > Alan Stern writes: > > > > > > > > On Fri, 31 Jul 2015, Giulio Bernardi wrote: > > > > > > > P.S: it looks like scsi_dev_info_list_del_keyed() shares the same > > code, so maybe

Re: Multiple drives on JMS56x-based sata-usb docking station.

On Tue, 6 Oct 2015, Daniel Ranger wrote: > Alan Stern writes: > > > > > On Fri, 31 Jul 2015, Giulio Bernardi wrote: > > > > > P.S: it looks like scsi_dev_info_list_del_keyed() shares the same > code, so maybe > > > it should be modified too? > > > > You're right. I'll split

alloc_tty_driver fails with ENOMEM

Hi linux-usb list, Since upgrading to kernel version from 4.1.x to 4.2.1 on Debian testing I am getting on my PC the following usbserial module init failure when connecting my PC to the i.MX6 SabreSD FTDI USB/serial connector: [39987.092021] usb 1-5.1: new full-speed USB device number 4 using

Re: [PATCH v4] usb: of: add an api to get dr_mode by the phy node

Hi, > How about add a new function as follows to convert dr_mode from string to > enum, then both Keikki's and my function will be shorter by calling it? > > static enum usb_dr_mode of_usb_get_dr_mode_from_string(char *string) > { > for (i = 0; i < ARRAY_SIZE(usb_dr_modes); i++) >

Re: [PATCH 18/23] spear13xx_pcie_gadget: use per-attribute show and store methods

On Sat, Oct 3, 2015 at 7:02 PM, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig Acked-by: Pratyush Anand -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org

Re: mass storage behaviour

On 05 Oct 2015, at 23:09, Alan Stern wrote: > On Mon, 5 Oct 2015, Paul Jones wrote: > >>> Increasing the max_sectors_kb value, on the other hand, might remove >>> overhead by allowing a higher percentage of the transfer to consist of >>> real data as opposed to CBW

Re: [PATCH 0/7][v4] Add OTG support for FSL socs

On Mon, 5 Oct 2015, Felipe Balbi wrote: > Ramneek Mehresh writes: > > > Add support for otg for all freescale socs having internal > > usb phy. > > > > Ramneek Mehresh (7): > > usb:fsl:otg: Make fsl otg driver as tristate > > usb:fsl:otg: Add controller

Re: alloc_tty_driver fails with ENOMEM

On Tue, Oct 06, 2015 at 11:03:46AM +0300, Baruch Siach wrote: > Hi Greg, > > On Tue, Oct 06, 2015 at 08:53:07AM +0100, Greg KH wrote: > > On Tue, Oct 06, 2015 at 09:44:24AM +0300, Baruch Siach wrote: > > > Since upgrading to kernel version from 4.1.x to 4.2.1 on Debian testing I > > > am getting

RE: [PATCH 1/4] usb: host: xhci-rcar: add xhci_rcar_is_compatible() function

Hi Geert-san, > Sent: Tuesday, October 06, 2015 5:55 AM > > Hi Shimoda-san, > > On Mon, Oct 5, 2015 at 2:06 PM, Yoshihiro Shimoda > wrote: > > +bool xhci_rcar_is_compatible(struct usb_hcd *hcd) > > +{ > > + struct device_node *of_node =

[PATCH v5 2/2] usb: dwc2: refactor common low-level hw code to platform.c

DWC2 module on some platforms needs three additional hardware resources: phy controller, clock and power supply. All of them must be enabled/activated to properly initialize and operate. This was initially handled in s3c-hsotg driver, which has been converted to 'gadget' part of dwc2 driver.

Re: iperf UDP packet loss with Chipidea HDRC

On Tue, Oct 06, 2015 at 06:07:50AM +0530, Jayan John wrote: > On Tue, Oct 6, 2015 at 3:38 AM, Fabio Estevam wrote: > > On Mon, Oct 5, 2015 at 10:57 AM, Jayan John wrote: > >> We are developing a custom USB device on a iMX6q platform with a Chipidea > >>

Re: [PATCH v4 4/4] usb: dwc2: refactor common low-level hw code to platform.c

Hello, On 2015-10-06 01:27, Felipe Balbi wrote: John Youn writes: Hi, On 10/2/2015 12:45 AM, Marek Szyprowski wrote: DWC2 module on some platforms needs three additional hardware resources: phy controller, clock and power supply. All of them must be

Re: [PATCH] HID: hiddev: fix returned errno code in hiddev_connect()

On 05/10/15 15:24, Jiri Kosina wrote: > On Sat, 3 Oct 2015, Luis de Bethencourt wrote: > >>> But I am not really sure where you are seeing the bug (mapping to >>> -EPERM) in this case? I think the only caller of hiddev_connect() >>> should be hid_connect(), and the only thing that guy cares

Re: alloc_tty_driver fails with ENOMEM

On Tue, Oct 06, 2015 at 09:44:24AM +0300, Baruch Siach wrote: > Hi linux-usb list, > > Since upgrading to kernel version from 4.1.x to 4.2.1 on Debian testing I am > getting on my PC the following usbserial module init failure when connecting > my PC to the i.MX6 SabreSD FTDI USB/serial

Re: alloc_tty_driver fails with ENOMEM

Hi Greg, On Tue, Oct 06, 2015 at 08:53:07AM +0100, Greg KH wrote: > On Tue, Oct 06, 2015 at 09:44:24AM +0300, Baruch Siach wrote: > > Since upgrading to kernel version from 4.1.x to 4.2.1 on Debian testing I > > am getting on my PC the following usbserial module init failure when > > connecting

[PATCH v5 1/2] usb: dwc2: remove no longer needed init_mutex

init_mutex is a leftover from the time, when s3c-hsotg driver did not implement proper pull up/down control and emulated it by enabling enabling/disabling usb phy. Proper pull up/down control has been added by commit 5b9451f8c4fbaf0549139755fb45ff2b57975b7f ("usb: dwc2: gadget: use soft-disconnect

[PATCH v3 1/1] USB:option:add ZTE PIDs

This is intended to add ZTE device PIDs on kernel. Signed-off-by: Liu.Zhao --- drivers/usb/serial/option.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index 876423b..6b4a766 100644 ---

Re: [PATCH v5 2/2] usb: dwc2: refactor common low-level hw code to platform.c

On 10/6/2015 1:56 AM, Marek Szyprowski wrote: > DWC2 module on some platforms needs three additional hardware > resources: phy controller, clock and power supply. All of them must be > enabled/activated to properly initialize and operate. This was initially > handled in s3c-hsotg driver, which has

[RFT 0/3] usb: usb3503: Fix probing on Arndale board (missing phy)

Hi, Introduction This patchset tries to fix probing of usb3503 on Arndale board if the Samsung PHY driver is probed later (or built as a module). *The patchset was not tested on Arndale board.* I don't have that board. Please test it and say if the usb3503 deferred probe works fine

[RFT 1/3] dt-bindings: usb: usb5303: Document new 'phys' property

Document new 'phys' and 'phys-names' properties. Signed-off-by: Krzysztof Kozlowski Cc: Kevin Hilman Cc: Arnd Bergmann Cc: riku.voi...@linaro.org Cc: Marek Szyprowski ---

[RFT 2/3] usb: misc: usb3503: Allow usage of device through phy interface

The USB3503 hub controller can be connected through I2C interface (e.g. on Odroid-U3 board) or directly by phy (e.g. on Arndale board). Thus the usb3503 driver can act as a i2c or platform device. In the second configuration (phy) the driver did not get a reference to necessary phy to use it.

[RFT 3/3] ARM: dts: Fix usb3503 probe by enabling phy on exynos5250-arndale

On Arndale board (unlike Odroid U3) the USB3503 hub controller is connected in phy mode (not through I2C). For successful probe it needs to get reference to proper phy and enable it. Signed-off-by: Krzysztof Kozlowski Reported-by: Kevin Hilman

Re: [PATCH] xhci: create one unified function to calculate TRB TD remainder.

On 11.09.2015 07:08, chunfeng yun wrote: Hi, On Tue, 2015-09-08 at 14:09 +0300, Mathias Nyman wrote: xhci versions 1.0 and later report the untransferred data remaining in a TD a bit differently than older hosts. We used to have separate functions for these, and needed to check host version

Configfs composite gadget with CCID and mass storage

Hi, I am trying to implement a composite USB device, which consists of a Smart card Chip Card Interface Device (CCID) and a mass storage device, on an embedded platform (ARM processor) using Configfs composite gadget. I was able to successfully setup the mass storage device but I am having

Re: Configfs composite gadget with CCID and mass storage

W dniu 06.10.2015 o 14:38, Frans-Pieter van Wyk pisze: Hi, My question is, is it possible to setup a USB composite device consisting of a smart card CCID and a mass storage device using Configfs? ConfigFS is used to compose a gadget of existing functions. As far as I can tell there is no

Re: mass storage behaviour

On 06 Oct 2015, at 16:44, Alan Stern wrote: > On Tue, 6 Oct 2015, Paul Jones wrote: > >> On 05 Oct 2015, at 23:09, Alan Stern wrote: >> >>> On Mon, 5 Oct 2015, Paul Jones wrote: >>> > Increasing the max_sectors_kb value, on the other

Re: mass storage behaviour

On Tue, 6 Oct 2015, Felipe Balbi wrote: > >> In my experience, you need to do at least the following to get max > >> performance from the mass storage gadget: > >> > >> - Use Windows 8 or higher on the host. It's much faster than Linux. Why is Windows so much faster? Or to put it another way,

Re: iperf UDP packet loss with Chipidea HDRC

On Tue, Oct 6, 2015 at 1:31 PM, Greg KH wrote: > On Tue, Oct 06, 2015 at 06:07:50AM +0530, Jayan John wrote: >> On Tue, Oct 6, 2015 at 3:38 AM, Fabio Estevam wrote: >> > On Mon, Oct 5, 2015 at 10:57 AM, Jayan John wrote: >>

Re: Multiple drives on JMS56x-based sata-usb docking station.

Alan Stern writes: > > On Fri, 31 Jul 2015, Giulio Bernardi wrote: > > > P.S: it looks like scsi_dev_info_list_del_keyed() shares the same code, so maybe > > it should be modified too? > > You're right. I'll split this into two patches: one to remove the > duplicate code, and

Re: mass storage behaviour

On Tue, Oct 6, 2015 at 10:01 AM, Alan Stern wrote: > On Tue, 6 Oct 2015, Felipe Balbi wrote: > >> >> In my experience, you need to do at least the following to get max >> >> performance from the mass storage gadget: >> >> >> >> - Use Windows 8 or higher on the host.

Re: mass storage behaviour

On Tue, 6 Oct 2015, Paul Jones wrote: > I changed /sys/block//device/max_sectors to 4096 and > /sys/block//queue/max_sectors_kb to 2048 > That improves matters slightly from 140MB/s to 160MB/s. > > Using Paul Zimmerman’s suggestion I can increase that to 174MB/s using a 160k > buffer. >

Aw: Re: Re: Intel XHCI: random URB_INTERRUPTs triggering port resets and device disconnects

> You've got it backward. The disconnect isn't _caused_ by the interrupt > URB; rather, the interrupt URB _reports_ the disconnect to the kernel. > In other words, the disconnect occurs first and then the interrupt URB > completes. Then I guess the traces aren't the right way to investigate