On Thu, May 15, 2014 at 6:53 PM, Miner, Blake bmi...@sweetamandas.com wrote:
After debugging further, I figured out what was causing the problem.
In the driver for the cp210x, there is a line of code in the `.attach`
function that calls `usb_reset_device(serial-dev);`. See the source
code
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 Mathias,
I've never rebuilt
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;
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#56128
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
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.
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
+++
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
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
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
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
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 peter.c...@freescale.com
---
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 peter.c...@freescale.com
---
drivers/usb/gadget/acm_ms.c |4 ++--
drivers/usb/gadget/audio.c|4 ++--
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
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
points to
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 architecture
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. After
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 wrote:
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 more
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 queued
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 xxo...@gmail.com
Tested-by: Jorge xxo...@gmail.com
to the patch?
Or maybe with a different address
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 bmi...@sweetamandas.com
On Fri, May 16, 2014 at 10:08 AM, Alan
From: Matwey V. Kornilov mat...@sai.msu.ru
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
From e24375ea6aefe2ad1ee72b8facab91abd1be190a Mon Sep 17 00:00:00 2001
From: Matwey V. Kornilov mat...@sai.msu.ru
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
From 0bd8c14855eeb049f49685f36386750a999078a3 Mon Sep 17 00:00:00 2001
From: Matwey V. Kornilov mat...@sai.msu.ru
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
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
From: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
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
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
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 gregory.clem...@free-electrons.com
---
arch/arm/boot/dts/armada-375.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git
On Armada 375, the USB cluster allows to control the cluster composed
of the USB2 and USB3 host controllers.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
arch/arm/boot/dts/armada-375.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git
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
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.
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
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
On Thu, May 15, 2014 at 2:18 PM, Thierry Reding
thierry.red...@gmail.com 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 a...@arndb.de wrote:
On Wednesday 14 May 2014 17:33:02 Andrew Bresticker wrote:
+
+int
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
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 address.
[ 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 dan.j.willi...@intel.com wrote:
On Mon, 2014-05-12 at 15:14 -0400, Alan Stern wrote:
On Mon, 12 May 2014, Dan Williams wrote:
Fixed. And
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
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 is
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
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) set pm_qos_no_poweroff to '0' for port1
(1)
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
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 gregory.clem...@free-electrons.com
Signed-off-by: Thomas Petazzoni
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 on
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(),
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
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 bj...@mork.no
---
drivers/net/usb/cdc_ncm.c |
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
Reported-by: Joe Perches j...@perches.com
Signed-off-by: Bjørn Mork bj...@mork.no
---
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
---
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 mrkiko...@gmail.com
Signed-off-by: Bjørn Mork bj...@mork.no
---
drivers/net/usb/cdc_ncm.c| 19 ++-
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
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 bj...@mork.no
---
drivers/net/usb/cdc_ncm.c | 88 ++-
1 file changed, 57
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
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
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
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
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
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 bj...@mork.no
---
drivers/net/usb/cdc_ncm.c | 31 +--
1 file changed, 25
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).
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
Alan Stern st...@rowland.harvard.edu 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:
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 --
* Paul Bolle pebo...@tiscali.nl [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,
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
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
On Wed, May 07, 2014 at 03:52:21PM +0200, Thomas Petazzoni wrote:
From: Gregory CLEMENT gregory.clem...@free-electrons.com
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
From: Bjørn Mork bj...@mork.no
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,
68 matches
Mail list logo
