Re: [PATCH net-next v2 00/12] cdc_ncm: add buffer tuning and stats using ethtool

David Miller writes: > From: Bjørn Mork > Date: Fri, 16 May 2014 21:48:17 +0200 > >> Quoting the previous description of this series (skip to the >> changelog below if you only want a summary of the changes): > > Ok I'm fine with this, applied to net-next. Thanks. > Just make doubly sure that

Re: [PATCH net-next v2 00/12] cdc_ncm: add buffer tuning and stats using ethtool

From: Bjørn Mork Date: Fri, 16 May 2014 21:48:17 +0200 > Quoting the previous description of this series (skip to the > changelog below if you only want a summary of the changes): Ok I'm fine with this, applied to net-next. Just make doubly sure that you will be ok, for a long time, with using

Re: [PATCHv4 15/20] ARM: configs: enable XHCI mvebu support in multi_v7_defconfig

On Wed, May 07, 2014 at 03:52:21PM +0200, Thomas Petazzoni wrote: > From: Gregory CLEMENT > > The Marvell Armada 38x platform needs the xhci_mvebu driver enabled > for the xHCI USB hosts, so this commit enables the corresponding > Kconfig option in multi_v7_defconfig. > > Signed-off-by: Gregory

Longcheer SU9800 usb 3g modem 1c9e:9800

This device vendor and product id is 1c9e:9800 It is working as serial interface with generic usbserial driver. I thought it is more suitable to use usbserial option driver, which has better capability distinguishing between modem serial interface and micro sd storage interface. I hope it would b

[PATCH v2] separate usb_address0 mutexes for each bus

This patch creates a separate instance of the usb_address0 mutex for each USB bus, and attaches it to the usb_bus device struct. This allows devices on separate buses to be enumerated in parallel; saving time. In the current code, there is a single, global instance of the usb_address0 mutex which

Re: [PATCH v2] ARM: OMAP: replace checks for CONFIG_USB_GADGET_OMAP

* Paul Bolle [140516 03:01]: > Commit 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built") > apparently required that checks for CONFIG_USB_GADGET_OMAP would be > replaced with checks for CONFIG_USB_OMAP. Do so now for the remaining > checks for CONFIG_USB_GADGET_OMAP, even though thes

Re: CP210x Driver - Issue Enumerating Multiple Interfaces

On Fri, 16 May 2014, Miner, Blake wrote: > Alan, > > I'm not sure what the final patch is going to look like just yet, but > I fixed up the one I linked to previously, per your request. I wanted > to mention that calling `usb_queue_device_reset()` causes the kernel > to crash. Well, good grief

Re: CP210x Driver - Issue Enumerating Multiple Interfaces

Alan Stern writes: > Finally, I don't understand how this patch could make any difference. > At the time the ->attach() routine runs, the device should already be > locked. A better strategy might be to call usb_queue_device_reset(). Or maybe even better: usb_queue_reset_device() :-) Bjør

Re: CP210x Driver - Issue Enumerating Multiple Interfaces

Alan, I'm not sure what the final patch is going to look like just yet, but I fixed up the one I linked to previously, per your request. I wanted to mention that calling `usb_queue_device_reset()` causes the kernel to crash. Thanks, Blake On Fri, May 16, 2014 at 12:00 PM, Alan Stern wrote: > O

Re: CP210x Driver - Issue Enumerating Multiple Interfaces

I agree. I think that the line should be removed altogether. Everything seems to work without it. I am testing on the CP2105. The device's buffers are cleared based upon the settings configured in the device's memory (some devices have a one-time programmable EPROM; others have an EEPROM). They

[PATCH net-next v2 04/12] net: cdc_ncm: support rx_max/tx_max updates when running

Finish the rx_max/tx_max setup by flushing buffers and informing usbnet about the changes. This way, the settings can be modified while the netdev is up and running. Signed-off-by: Bjørn Mork --- drivers/net/usb/cdc_ncm.c | 31 +-- 1 file changed, 25 insertions(+), 6

[PATCH net-next v2 09/12] net: cdc_ncm: use sane defaults for rx/tx buffers

Lots of devices request much larger buffers than reasonable. This cause real problems for users of hosts with limited resources. Reducing the default buffer size to 16kB for such devices is a reasonable trade-off between allowing them to aggregate traffic and avoiding memory exhaustion on resource

[PATCH net-next v2 02/12] net: cdc_ncm: factor out one-time device initialization

Split the parts of setup dealing with device initialization from parts just setting defaults for attributes which might be changed after initialization. Some commands of the device initialization are only allowed when the data interface is in its disabled altsetting, so we must separate them out o

[PATCH net-next v2 07/12] net: cdc_ncm: set reasonable padding limits

We pad frames larger than X to maximum size for devices which don't need a ZLP after maximum sized frames. This allows the device to optimize its transfers for one fixed buffer size. X was arbitrarily set at 512 bytes regardless of real buffer maximum, causing extreme overheads due to excessive pa

[PATCH net-next v2 03/12] net: cdc_ncm: split .bind device initialization

Now that we have split out the part of the device setup which MUST be done with the data interface in altsetting 0, we can delay the rest of the initialization. This allows us to move some of post-init buffer size config from bind to the appropriate setup function. The purpose of this refactoring

[PATCH net-next v2 08/12] net: cdc_ncm/cdc_mbim: adding NCM protocol statistics

To have an idea of the effects of the protocol coalescing it's useful to have some counters showing the different aspects. Due to the asymmetrical usbnet interface the netdev rx_bytes counter has been counting real received payload, while the tx_bytes counter has included the NCM/MBIM framing over

[PATCH net-next v2 00/12] cdc_ncm: add buffer tuning and stats using ethtool

Quoting the previous description of this series (skip to the changelog below if you only want a summary of the changes): "I have got quite a few reports from frustrated users of OpenWRT hosts trying to use some powerful LTE modem, but not achieving full speed. This is typically caused by a combin

[PATCH net-next v2 01/12] net: cdc_ncm: split out rx_max/tx_max update of setup

Split out the part of setup dealing with updating the rx_max and tx_max buffer sizes so that this code can be reused for dynamically updating the limits. Signed-off-by: Bjørn Mork --- drivers/net/usb/cdc_ncm.c | 88 ++- 1 file changed, 57 insertions(+)

[PATCH net-next v2 12/12] net: cdc_ncm: do not start timer on an empty skb

We can end up with a freshly allocated tx_curr_skb with no frames in it. In this case it does not make any sense to start the timer. This avoids the timer periodically trying to start tx when there is nothing in the queue. Signed-off-by: Bjørn Mork --- drivers/net/usb/cdc_ncm.c | 4 ++-- 1 file

[PATCH net-next v2 06/12] net: cdc_ncm: use true max dgram count for header estimates

Many newer NCM and MBIM devices will request a maximum tx datagram count which is much smaller than our hard-coded absolute max. We can reduce the overhead without sacrificing any of the simplicity for these devices, by simply using the true negotiated count in when calculated the maximum NTH and N

[PATCH net-next v2 10/12] net: cdc_ncm: fix argument alignment

Reported-by: Joe Perches Signed-off-by: Bjørn Mork --- drivers/net/usb/cdc_ncm.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index bb53abe1f3a1..1d1ff2fa8ae1 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/dr

[PATCH net-next v2 11/12] net: cdc_ncm: remove redundant "disconnected" flag

Calling netif_carrier_{on,off} is sufficient. There is no need to duplicate the carrier state in a driver specific flag. Acked-by: Enrico Mioso Signed-off-by: Bjørn Mork --- drivers/net/usb/cdc_ncm.c| 19 ++- drivers/net/usb/huawei_cdc_ncm.c | 13 - include/

[PATCH net-next v2 05/12] net: cdc_ncm: use ethtool to tune coalescing settings

Datagram coalescing is an integral part of the NCM and MBIM protocols, intended to reduce the interrupt load primarily on the device end of the USB link. As with all coalescing solutions, there is a trade-off between buffering and interrupts. The current defaults are based on the assumption that

Re: [PATCH v9 15/19] usb: introduce port status lock

On Wed, 7 May 2014, Dan Williams wrote: > In general we do not want khubd to act on port status changes that are > the result of in progress resets or USB runtime PM operations. > Specifically port power control testing has been able to trigger an > unintended disconnect in hub_port_connect_change

Re: [PATCH v6 14/17] ARM: mvebu: add Device Tree description of xHCI controllers on Armada 38x

On Thu, May 15, 2014 at 12:17:39PM +0200, Gregory CLEMENT wrote: > The Marvell Armada 38x SoCs contains two xHCI controllers. This commit > adds the Device Tree description of those interfaces at the SoC level, > and also enables the two USB3 ports on the Armada 385 DB platform and > one USB3 port

Re: [PATCH v6 10/17] ARM: mvebu: add USB3 support for Armada 38x

On Thu, May 15, 2014 at 12:17:35PM +0200, Gregory CLEMENT wrote: > This patch adds the selection of the config symbol needed to build the > USB3 support for Armada 38x into mvebu_v7_defconfig. > > Signed-off-by: Gregory CLEMENT > Signed-off-by: Thomas Petazzoni > --- > arch/arm/mach-mvebu/Kconf

Re: [PATCH v6 12/17] ARM: configs: enable XHCI mvebu support in mvebu_v7_defconfig

On Thu, May 15, 2014 at 12:17:37PM +0200, Gregory CLEMENT wrote: > The Marvell Armada 38x platform needs the xhci_mvebu driver enabled > for the xHCI USB hosts, so this commit enables the corresponding > Kconfig option in mvebu_v7_defconfig. > > Signed-off-by: Gregory CLEMENT > Signed-off-by: Tho

Re: [PATCH v9 14/19] usb: synchronize port poweroff and khubd

On Wed, 7 May 2014, Dan Williams wrote: > If a port is powered-off, or in the process of being powered-off, prevent > khubd from operating on it. Otherwise, the following sequence of events > leading to an unintended disconnect may occur: > > Events: > (0) > (1) hub 2-2:1.0: hub_resume > (2) hu

Re: [PATCH v9 13/19] usb: refactor port handling in hub_events()

On Wed, 7 May 2014, Dan Williams wrote: > In preparation for synchronizing port handling with pm_runtime > transitions refactor port handling into its own subroutine. > > We expect that clearing some status flags will be required regardless of > the port state, so handle those first and group all

Re: [PATCH v9 09/19] usb: make usb_port flags atomic, rename did_runtime_put to child_usage

On Wed, 7 May 2014, Dan Williams wrote: > We want to manipulate ->did_runtime_put in usb_port_runtime_resume(), > but we don't want that to collide with other updates. Move usb_port > flags to new port-bitmap fields in usb_hub. "did_runtime_put" is renamed > "child_usage_bits" to reflect that it

Re: [PATCH] usb: ehci: Enable support for 64bit EHCI host controllers in arm64

On Fri, 2014-05-16 at 13:55 +0100, Catalin Marinas wrote: [...] > > It could if arm64 would restrict the DMA addresses to 32-bit, but it doesn't > > and I end up on my platform with USB DMA buffers allocated >4GB address. > > dma_alloc_coherent() on arm64 should return 32-bit addresses if the > co

Re: [PATCH v9 17/19] usb: resume (wakeup) child device when port is powered on

[ adding Greg to the cc as a ping and in case he was curious of the current review state of this patchset ] On Thu, May 15, 2014 at 12:41 PM, Dan Williams wrote: > On Mon, 2014-05-12 at 15:14 -0400, Alan Stern wrote: >> On Mon, 12 May 2014, Dan Williams wrote: >> >> > Fixed. And dropped "wakeup"

Re: [PATCH] usb: ehci: Enable support for 64bit EHCI host controllers in arm64

On Fri, May 16, 2014 at 06:08:45PM +0100, Jon Medhurst (Tixy) wrote: > On Fri, 2014-05-16 at 13:55 +0100, Catalin Marinas wrote: > [...] > > > It could if arm64 would restrict the DMA addresses to 32-bit, but it > > > doesn't > > > and I end up on my platform with USB DMA buffers allocated >4GB ad

[ANNOUNCE] tree closed for v3.16

Hi folks, my tree is now closed for v3.16 merge window. I'll be sending my pull request to Greg next week (unless he wants it earlier) so that things can soak for another full week in linux-next. cheers ps: for the late patches, sorry you couldn't go in. Some of the patches can be merged during

Re: [RFC PATCH 06/10] usb: xhci: Add Tegra XHCI host-controller driver

On Thu, May 15, 2014 at 2:18 PM, Thierry Reding wrote: > On Thu, May 15, 2014 at 01:18:22PM -0700, Andrew Bresticker wrote: >> Arnd, >> >> On Thu, May 15, 2014 at 1:17 AM, Arnd Bergmann wrote: >> > On Wednesday 14 May 2014 17:33:02 Andrew Bresticker wrote: >> >> + >> >> +int tegra_xhci_register_m

[PATCH 0/5] Add support for USB cluster(PHY muxer) on the Armada 375 SoC

Hello, This series adds support for the USB cluster which is on the Armada 375 SoC. We can mainly see this device as a PHY muxer. After talking with Antoine Ténart about it I found a better way than the previous series to model it. Only one controller can access to the PHY so instead trying to en

[PATCH 3/5] ARM: mvebu: add Device Tree description of USB cluster controller on Armada 375

On Armada 375, the USB cluster allows to control the cluster composed of the USB2 and USB3 host controllers. Signed-off-by: Gregory CLEMENT --- arch/arm/boot/dts/armada-375.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armad

[PATCH 1/5] phy: add support for USB cluster on the Armada 375 SoC

The Armada 375 SoC comes with an USB2 host and device controller and an USB3 controller. The USB cluster control register allows to manage common features of both USB controllers. This commit adds a driver integrated in the generic PHY framework to control this USB cluster feature. Signed-off-by:

[PATCH 5/5] ARM: mvebu: add PHY support to the dts for the USB controllers on Armada 375

Now that the USB cluster node has been added, use it as a PHY provider for the USB controller linked to it: the first EHCI and the xHCI. Signed-off-by: Gregory CLEMENT --- arch/arm/boot/dts/armada-375.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/armada-375.dtsi

[PATCH 4/5] usb: host: xhci-plat: add optional PHY support

This commit extends the xhci-plat so that it can optionally be passed a reference to a PHY through the Device Tree. It will be useful for the Armada 375 SoCs. If no PHY is provided then the behavior of the driver is unchanged. As for the clock, to achieve this, it adds a 'struct phy *' member in x

[PATCH 2/5] Documentation: dt-bindings: document the Armada 375 USB cluster binding

Armada 375 comes with an USB2 host and device controller and an USB3 controller. The USB cluster control register allows to manage common features of both USB controllers. This commit adds the Device Tree binding documentation for this piece of hardware. Signed-off-by: Gregory CLEMENT --- .../bi

Re: CP210x Driver - Issue Enumerating Multiple Interfaces

On Fri, 16 May 2014, Miner, Blake wrote: > Thanks to everyone who helped me with my first kernel patch. Please > see the patch in the link below. If any revisions are necessary, > please let me know. Thanks! > > http://sweetamandas.com/cp210x.patch.txt You should post patches in your email me

[PATCH] USB: keyspan: fix potential null pointer dereference

From: Rickard Strandqvist Move control-urb dereference to after NULL-check. There is otherwise a risk of a possible null pointer dereference. Was largely found by using a static code analysis program called cppcheck. [Johan: modify commit message somewhat ] Signed-off-by: Rickard Strandqvist

Re: [PATCH] Fix for possible null pointer dereference in keyspan.c

On Thu, May 15, 2014 at 11:55:10PM +0200, Rickard Strandqvist wrote: > There is otherwise a risk of a possible null pointer dereference. I don't think this can be triggered unless the URB allocation fails at probe, but let's move the offending line nonetheless. I'll fix up the patch subject as we

[PATCH 1/2] Add tusb_revision to struct musb to store the revision.

From 0bd8c14855eeb049f49685f36386750a999078a3 Mon Sep 17 00:00:00 2001 From: "Matwey V. Kornilov" Date: Fri, 9 May 2014 15:52:00 +0400 Subject: [PATCH 1/2] Add tusb_revision to struct musb to store the revision. Add field to store tusb6010 revision value. Read the revision at the startup and st

[PATCH 2/2] Use musb->tusb_revision instead of tusb_get_revision call.

From e24375ea6aefe2ad1ee72b8facab91abd1be190a Mon Sep 17 00:00:00 2001 From: "Matwey V. Kornilov" Date: Fri, 9 May 2014 16:10:16 +0400 Subject: [PATCH 2/2] Use musb->tusb_revision instead of tusb_get_revision call. The value of the revision is stored in musb->tusb_revision, so don't re-read it

[PATCH 0/2] Fix dependency loop in tusb6010

From: "Matwey V. Kornilov" Subject: [PATCH 0/2] Fix dependency loop in tusb6010 With the following configure options, musb_hdrc and tusb6010 make dependency loop: CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_TUSB6010=m CONFIG_USB_TUSB_OMAP_DMA=y tusb6010.ko provides function `tusb_get_revision` whi

Re: CP210x Driver - Issue Enumerating Multiple Interfaces

Thanks to everyone who helped me with my first kernel patch. Please see the patch in the link below. If any revisions are necessary, please let me know. Thanks! http://sweetamandas.com/cp210x.patch.txt Signed-of-by: Blake Miner On Fri, May 16, 2014 at 10:08 AM, Alan Stern wrote: > On Fri, 1

Re: PROBLEM: usb2 port does not work on a "ultrabook" laptop.

On 05/16/2014 04:45 AM, Mathias Nyman wrote: Thanks a lot, I'll send the patch upstream. With some luck it can still make 3.15, otherwise 3.16 Great! Would you like me to add Reported-by: Jorge Tested-by: Jorge to the patch? Or maybe with a different address so you can get credit with your

Re: [PATCH] usb: dwc3: gadget: check link trb after free_slot is increased

Hi, On Fri, May 16, 2014 at 07:41:06AM -0500, Felipe Balbi wrote: > On Fri, May 16, 2014 at 11:50:13PM +0800, Zhuang Jin Can wrote: > > > On Fri, May 16, 2014 at 05:57:57AM +0800, Zhuang Jin Can wrote: > > > > In ISOC transfers, when free_slot points to the last TRB (i.e. Link > > > > TRB), and all

Re: CP210x Driver - Issue Enumerating Multiple Interfaces

On Fri, 16 May 2014, Miner, Blake wrote: > > I am not sure about this, but I wonder can we do the reset in > > cp210x_open() instead of in cp210x_startup()? > > Possibly, but I'd rather perform the reset just once, right when the > device is detected and bound to the driver. After doing some mor

Re: [PATCH] usb: ehci: Enable support for 64bit EHCI host controllers in arm64

On Fri, May 16, 2014 at 01:55:01PM +0100, Catalin Marinas wrote: > On Thu, May 15, 2014 at 05:53:53PM +0100, Liviu Dudau wrote: > > On Thu, May 15, 2014 at 04:36:25PM +0100, Alan Stern wrote: > > > On Thu, 15 May 2014, Liviu Dudau wrote: > > > > On Thu, May 15, 2014 at 03:11:48PM +0100, Alan Stern

Re: CP210x Driver - Issue Enumerating Multiple Interfaces

On Fri, May 16, 2014 at 05:54:12AM -0400, Miner, Blake wrote: > > I am not sure about this, but I wonder can we do the reset in > > cp210x_open() instead of in cp210x_startup()? > > Possibly, but I'd rather perform the reset just once, right when the > device is detected and bound to the driver.

Re: [PATCH] usb: ehci: Enable support for 64bit EHCI host controllers in arm64

On Thu, May 15, 2014 at 05:53:53PM +0100, Liviu Dudau wrote: > On Thu, May 15, 2014 at 04:36:25PM +0100, Alan Stern wrote: > > On Thu, 15 May 2014, Liviu Dudau wrote: > > > On Thu, May 15, 2014 at 03:11:48PM +0100, Alan Stern wrote: > > > > On Wed, 14 May 2014, Mark Brown wrote: > > > > > arm64 arc

Re: [PATCH] usb: dwc3: gadget: check link trb after free_slot is increased

Hi, On Fri, May 16, 2014 at 11:50:13PM +0800, Zhuang Jin Can wrote: > > On Fri, May 16, 2014 at 05:57:57AM +0800, Zhuang Jin Can wrote: > > > In ISOC transfers, when free_slot points to the last TRB (i.e. Link > > > TRB), and all queued requests meet Missed Interval Isoc error, busy_slot > > > poi

[PATCH 0/4] Add Gadget Bus

Hi Felipe & Alan, To continue with topic discussed at http://www.spinics.net/lists/linux-usb/msg105279.html, I implement the gadget bus to bind udc to gadget driver follow most ideas from your two. Now this problem is really annoying, many gadget build-in platforms (Eg, Android) will fail to enab

[PATCH 1/4] usb: gadget: core: change udc class to gadget bus

The udc will be the device at gadget bus, and the gadget driver will be the driver at this bus. With gadget bus, we can support below features: - udc driver is loaded later than gadget driver - Binding udc and gadget driver manually Signed-off-by: Peter Chen --- drivers/usb/gadget/udc-core.c |

[PATCH 4/4] usb: gadget: remove __init from gadget driver bind function

Since the .bind may not be called at the driver's initialization routine due to the udc is not ready, we remove __init marker for it. Signed-off-by: Peter Chen --- drivers/usb/gadget/acm_ms.c |4 ++-- drivers/usb/gadget/audio.c|4 ++-- drivers/usb/gadget/cdc2.c |

[PATCH 2/4] usb: gadget: core: add implementation of gadget bus

At gadget bus, the device (udc) and the driver (gadget dirver) will try to match between each other, the automatically binding is designed at this patch. The rule of auto-binding is: if the udc is not in use and the gadget driver is not used by any udcs, it is matched successfully, and will be bin

[PATCH 3/4] usb: gadget: core: add manual binding

The user can bind any unused udc to specific gadget driver if there is no udc has already been binded to that gadget driver. For example: echo udc-0 > /sys/bus/usb_gadget/drivers/g_serial echo udc-1 > /sys/bus/usb_gadget/drivers/g_mass_storage There are three solutions to do manual binding: 1. If

[PATCH v2] ARM: OMAP: replace checks for CONFIG_USB_GADGET_OMAP

Commit 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built") apparently required that checks for CONFIG_USB_GADGET_OMAP would be replaced with checks for CONFIG_USB_OMAP. Do so now for the remaining checks for CONFIG_USB_GADGET_OMAP, even though these checks have basically been broken si

Re: CP210x Driver - Issue Enumerating Multiple Interfaces

> I am not sure about this, but I wonder can we do the reset in > cp210x_open() instead of in cp210x_startup()? Possibly, but I'd rather perform the reset just once, right when the device is detected and bound to the driver. After doing some more reading, I've found that calling `usb_lock_device_

Re: [PATCH] ARM: OMAP: replace checks for CONFIG_USB_GADGET_OMAP

Felipe, On Thu, 2014-05-15 at 18:12 -0500, Felipe Balbi wrote: > On Thu, May 15, 2014 at 10:55:45PM +0200, Paul Bolle wrote: > > diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c > > index 65d2acb31498..57092bc7f4f1 100644 > > --- a/arch/arm/mach-omap1/board-h2.c > > +++

Re: [PATCH v2 0/4] libusbg: Fix potential issues found with coverity

Hi, On 16/05/14 11:35, Krzysztof Opasiak wrote: I have just go through you patches once again and test it. Each commit is able to build. I have also tested it on my board and didn't find any regression. Please update commit messages according to my comments and patches will look good to me. Ex

RE: [PATCH v2 0/4] libusbg: Fix potential issues found with coverity

Hi, I have just go through you patches once again and test it. Each commit is able to build. I have also tested it on my board and didn't find any regression. Please update commit messages according to my comments and patches will look good to me. -- BR's Krzysztof Opasiak > -Original Messag

RE: [PATCH v2 2/4] libusbg: Fix buffer overrun issue. CID#56128

Hi, > -Original Message- > From: Philippe De Swert [mailto:philippedesw...@gmail.com] > Sent: Tuesday, May 13, 2014 4:13 PM > To: Krzysztof Opasiak; linux-usb@vger.kernel.org > Cc: mpor...@linaro.org; Philippe De Swert > Subject: [PATCH v2 2/4] libusbg: Fix buffer overrun issue. > CID#5612

RE: [PATCH v2 1/4] libusbg: Fix readlink/buffer overrun issue. CID#56130, CID#56129

Hi, Sorry that I'm writing it so late, but in previous versions I have focused on code and only run through commit messages. > -Original Message- > From: Philippe De Swert [mailto:philippedesw...@gmail.com] > Sent: Tuesday, May 13, 2014 4:13 PM > To: Krzysztof Opasiak; linux-usb@vger.kern

Re: PROBLEM: usb2 port does not work on a "ultrabook" laptop.

On 05/16/2014 08:56 AM, Jorge wrote: > On 15/05/14 22:16, Jorge wrote: >> On 15/05/14 12:16, Mathias Nyman wrote: >>> >>> Thanks, It appears so. >>> >>> Jorge, I don't have access to a Sony VAIO t-series machine, can you try if >>> the >>> following patch fixes the issue? >>> >>> -Mathias >> Hi M