Am Montag, 1. Juli 2013, 00:37:14 schrieben Sie:
Hi!
I'm trying to investigate on the Huawei E3131 wwan interface -
Is the E3131 an HILINK-Modem?
Have you tried simply starting dhcp/automatic-configuration?
Open a Browser to get connected.
If dns-redirection doesn't work, try the router or
Hi
Is someone actively working on or maintaining the EHCI debug device
gadget driver? I would like to see some fixes and/or improvements to it
but do not know the gadget framework and some of the required hardware
is not yet on my desk.
So the incomplete report here is from a friends'
Enrico Mioso mrkiko...@gmail.com writes:
Hi!
I'm trying to investigate on the Huawei E3131 wwan interface - like the E398,
this device ignores the at^ndisdup command.
I wanted to verify if my device was running a jungo firmware or not, since I
found contraddictory informations on the
In order to decrease the amount of work done
by PHY users, allow NULL phy pointers to be
passed.
Signed-off-by: Felipe Balbi ba...@ti.com
---
include/linux/usb/phy.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linux/usb/phy.h
This is a Linux-only driver which makes use
of GPL-only symbols. It makes no sense to
maintain Dual BSD/GPL licensing for this driver.
Considering that the amount of work to use this
driver in any different operating system would likely
be as large as developing the driver from scratch and
in order to allow different instances of the
core work in different maximum speeds, we will
move the maximum_speed module_parameter to
both DeviceTree (making use the new maximum-speed
DT property) and platform_data.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.c |
Hi folks,
here's a small series of patches. We're switching dwc3 to GPL v2 only,
protecting our USB PHY layer against NULL pointers, introducing
of_usb_get_maximum_speed() and making sure DWC3's maximum-speed is a
per-instance attribute.
While at that, we also make sure that tx-fifo-resize can
in case we're not in a DT boot, we should
still be able to tell the driver how to behave.
In order to be able to pass flags to the driver,
we introduce platform_data structure which the
core driver should use.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.c | 8
this helper will be used for controllers which
want to work at a lower speed even though they
support higher USB transfer rates.
One such case is Texas Instruments' AM437x
SoC where it uses a USB3 controller without
a USB3 PHY, rendering the controller USB2-only.
Signed-off-by: Felipe Balbi
On Fri, Jun 28, 2013 at 11:32:52AM -0700, Greg Kroah-Hartman wrote:
Enable the USB atm drivers to use the dynamic debugging subsystem, and
not rely on if CONFIG_USB_DEBUG is enabled or not for debugging
messages. This also provides a saner debug message, pointing out the
exact device the
On Fri, Jun 28, 2013 at 11:32:50AM -0700, Greg Kroah-Hartman wrote:
If this code isn't triggering this assert by now, it never will, so just
remove it, it's pointless.
Cc: Duncan Sands duncan.sa...@free.fr
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
compile tested and
On Fri, Jun 28, 2013 at 11:32:56AM -0700, Greg Kroah-Hartman wrote:
Now that no USB phy driver is using CONFIG_USB_DEBUG, remove it from the
Makefile.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Acked-by: Felipe Balbi ba...@ti.com
--
balbi
On Fri, Jun 28, 2013 at 11:32:55AM -0700, Greg Kroah-Hartman wrote:
Use the in-kernel pr_debug() calls instead of trying to roll your own
DBG macro. This means the dynamic debugging calls now work here, and
there is no dependency on CONFIG_USB_DEBUG for the phy code anymore.
Cc: Felipe
On Fri, Jun 28, 2013 at 11:32:53AM -0700, Greg Kroah-Hartman wrote:
Move the atm_dbg() call to use the dynamic debug subsystem, and not rely
on CONFIG_USB_DEBUG for if things should be printed out or not.
This also means the drivers do not have to be rebuilt to get debugging
messages,
On Fri, Jun 28, 2013 at 11:32:51AM -0700, Greg Kroah-Hartman wrote:
We have an in-kernel trace subsystem, so use that instead of printk for
trying to figure out what functions are being called.
Cc: Duncan Sands duncan.sa...@free.fr
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
On Fri, Jun 28, 2013 at 11:32:58AM -0700, Greg Kroah-Hartman wrote:
We shouldn't ever panic in a driver, and these calls were never being
used, so just delete them, as obviously the driver is working properly
now (right?)
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Greg Kroah-Hartman
On Fri, Jun 28, 2013 at 11:32:57AM -0700, Greg Kroah-Hartman wrote:
This endif is for CONFIG_USB_GADGET_DEBUG_FILES, not CONFIG_USB_DEBUG,
so document it properly.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Acked-by: Felipe Balbi ba...@ti.com
On Fri, Jun 28, 2013 at 11:32:59AM -0700, Greg Kroah-Hartman wrote:
Like _BUG_ON(), _WARN_ON() wasn't ever being used, so just delete it, as
obviously things are working properly now (if not, we have bigger
problems...)
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Greg Kroah-Hartman
On Fri, Jun 28, 2013 at 11:33:02AM -0700, Greg Kroah-Hartman wrote:
Move all debugging messages in the driver to use the dynamic debug
subsystem, and not rely on CONFIG_USB_DEBUG to turn them on or off.
This lets debugging be enabled without having to rebuild the driver, an
important thing
On Fri, Jun 28, 2013 at 11:33:00AM -0700, Greg Kroah-Hartman wrote:
If you want a debug call, just make it, so move to using the
already-there DBG() call. No need to make things more complex than they
really need to be.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Greg Kroah-Hartman
On Fri, Jun 28, 2013 at 11:33:03AM -0700, Greg Kroah-Hartman wrote:
This removes the dependency of the driver on CONFIG_USB_DEBUG and moves
it to us the dynamic debug subsystem instead. Bonus is the fact that we
can now properly determine the exact hardware that is spitting out the
messages.
On Fri, Jun 28, 2013 at 11:33:01AM -0700, Greg Kroah-Hartman wrote:
Now that the debugging macros are cleaned up, just rely on the dynamic
debug code in the kernel to do the debug messages for the driver.
This lets debugging be enabled without having to rebuild the driver, an
important thing
On 06/28/2013 10:06 PM, Alan Stern wrote:
On Fri, 28 Jun 2013, Roger Quadros wrote:
That's not what I meant. Never mind the pinctrl; I was asking about
the EHCI controller itself. Under what circumstances does the
controller assert its wakeup signal? And how do you tell it to stop
bInterval must be on the range 1 - 16, if we
want to pass the maximum allowed, we should
be passing 16.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/atm/speedtch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/atm/speedtch.c
bInterval must be on the range 1 - 16, if we
want to pass the maximum allowed, we should
be passing 16
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/class/cdc-acm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/class/cdc-acm.c
Hi Greg,
I found this issue when build testing your latest
cleanup series with Sparse enabled. Clearly it was
not caused by your series, it just helped me expose
the problem since I built drivers I don't normally
build.
Anyway, a too large bInterval will end up zeroing
urb-interval and in turn
bInterval must be within the range 1 - 16,
in order to catch drivers passing a too
large bInterval (thus zeroing urb-interval),
let's clamp() the argument to the allowed
range.
Signed-off-by: Felipe Balbi ba...@ti.com
---
include/linux/usb.h | 4
1 file changed, 4 insertions(+)
diff --git
Hi
Am Samstag, 29. Juni 2013, 15:39:52 schrieb Alan Stern:
On Fri, 28 Jun 2013, Jack Pham wrote:
Sorry to jump into this conversation just now but I saw this thread and
noticed the link to ehset.c. This file was authored by us at Qualcomm,
and had been added to the out-of-tree MSM port of
Hi,
On Mon, Jul 01, 2013 at 11:23:25AM +0300, Felipe Balbi wrote:
bInterval must be within the range 1 - 16,
in order to catch drivers passing a too
large bInterval (thus zeroing urb-interval),
let's clamp() the argument to the allowed
range.
Signed-off-by: Felipe Balbi ba...@ti.com
---
On 06/28/2013 10:18 PM, Alan Stern wrote:
On Fri, 28 Jun 2013, Roger Quadros wrote:
Just found the problem. It seems that enabling the ehci_irq _after_ the root
hub is resumed
is the root cause of the problem. Doing so will miss events from the root
hub.
This sounds like a bug in the
Hi,
No, i don't see that (Set-Config request with a config value of 0)
Well, then I don't know where the problem is, but obviously the problem
occurred before the gadget driver was involved. Either the host sent a
wrong packet, or more likely the UDC received the packet incorrectly.
Yes,
On Mon, Jul 1, 2013 at 12:17 AM, Greg KH gre...@linuxfoundation.org wrote:
On Sun, Jun 30, 2013 at 09:35:59PM +0200, Martin van Es wrote:
3.9.8 brought a tiny improvement!
scanimage -L now succesfully reports the scanner, but then hangs.
I still can not scan with xsane however (no scanner
Hi,
No, i don't see that (Set-Config request with a config value of 0)
Well, then I don't know where the problem is, but obviously the problem
occurred before the gadget driver was involved. Either the host sent a
wrong packet, or more likely the UDC received the packet incorrectly.
Yes,
thank you very much for the hint!
Unfortunately, this is not a Hi-Link modem. But I read about it, maybe your
investigations?
Thank again for the hint!
On Mon, 1 Jul 2013, Thomas Sch?fer wrote:
==Date: Mon, 01 Jul 2013 08:16:34 +0200
==From: Thomas Sch?fer tschae...@t-online.de
==To: Enrico
On 6/30/2013 8:32 PM, Alan Stern wrote:
There are several possible things the HCD could do when an underrun
occurs:
I do not have much experience in working with ISOC host.But by the
experience of device side I can say that, There could be problem
irrespective of tasklet or irq context, only
Hi All,
I'm very happy to announce libusbx-1.0.16-rc2.
Changes since 1.0.16-rc1:
-
* Fix crash on exit on openbsd, netbsd wince
* Logging now use a single write call per log-message, avoiding log-message
interlacing when using multiple threads.
* Do not use
Pratyush Anand wrote:
On 6/30/2013 8:32 PM, Alan Stern wrote:
It could schedule the URB for the first time slot known to be
available, even if that means skipping some time slots which
the hardware might (or might not) be able to use.
IMO, this approach is better.
To quote the
Ming Lei wrote:
On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern st...@rowland.harvard.edu
wrote:
Thus, for example, even if the pipeline contains only a single URB,
with the current code it will not become empty. But with the new code
it will. If the load on the system is too high, the
On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern st...@rowland.harvard.edu wrote:
Naturally, under normal circumstances this won't matter, because
underruns shouldn't occur. But I know from experience that people try
to push the latency as far down as they can, which increases the
likelihood of
On Fri, Jun 28, 2013 at 07:02:32PM -0700, Stephen Boyd wrote:
On 06/28/13 03:58, Felipe Balbi wrote:
Hi,
On Thu, Jun 27, 2013 at 09:57:52AM -0700, Stephen Boyd wrote:
On 06/26/13 23:58, Felipe Balbi wrote:
On Wed, Jun 26, 2013 at 02:52:56PM -0700, Stephen Boyd wrote:
Hi,
I'm
Hi guys!
It's my first experience, and util now I acquired a null pointer dereference,
which kicks my kernel off! :)
This is the patch ... I know for sure I'm doing something horrible!
I'm a newbie !! XD
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 4709fa3..725d892
On 7/1/2013 4:48 PM, Clemens Ladisch wrote:
It could try to schedule the URB for the next time slot after
the last one used by the preceding URB, even if that time slot
has already expired.
There is no meaning of submitting an URB for expired time slot.
Of course there is. The
Ming Lei wrote:
On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern st...@rowland.harvard.edu
wrote:
Naturally, under normal circumstances this won't matter, because
underruns shouldn't occur. But I know from experience that people try
to push the latency as far down as they can, which increases
Hello,
On Monday 01 July 2013 13:19:05 Ming Lei wrote:
On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern wrote:
Clement and Laurent:
The two of you seem to be the people who make the most use of
isochronous USB transfers. Since the ehci-hcd driver is being changed
to use a tasklet for URB
On Mon, Jul 1, 2013 at 9:06 PM, Clemens Ladisch clem...@ladisch.de wrote:
Ming Lei wrote:
On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern st...@rowland.harvard.edu
wrote:
Naturally, under normal circumstances this won't matter, because
underruns shouldn't occur. But I know from experience that
Ming Lei wrote:
On Mon, Jul 1, 2013 at 9:06 PM, Clemens Ladisch clem...@ladisch.de wrote:
Ming Lei wrote:
I understand the latency is effected by packet count in one URB,
and it shouldn't be related with URB count,
This is true only when capturing. For playback, the latency is the
length
Enrico Mioso mrkiko...@gmail.com writes:
Hi guys!
It's my first experience, and util now I acquired a null pointer dereference,
which kicks my kernel off! :)
This is the patch ... I know for sure I'm doing something horrible!
I'm a newbie !! XD
diff --git a/drivers/net/usb/cdc_ncm.c
On Mon, Jul 1, 2013 at 9:27 PM, Clemens Ladisch clem...@ladisch.de wrote:
Ming Lei wrote:
On Mon, Jul 1, 2013 at 9:06 PM, Clemens Ladisch clem...@ladisch.de wrote:
Ming Lei wrote:
I understand the latency is effected by packet count in one URB,
and it shouldn't be related with URB count,
Pratyush Anand wrote:
On 7/1/2013 4:48 PM, Clemens Ladisch wrote:
There is no meaning of submitting an URB for expired time slot.
Of course there is. The HCD cannot exactly know whether the current
slot will expire before the URB is enqueued, so it is not always
possible to label the slot
On Mon, 1 Jul 2013, Felipe Balbi wrote:
bInterval must be within the range 1 - 16,
That's true only for high speed and SuperSpeed. For low speed and full
speed, bInterval is allowed to range from 1 to 255. See p. 271 in the
USB-2 spec.
in order to catch drivers passing a too
large
Ming Lei wrote:
On Mon, Jul 1, 2013 at 9:27 PM, Clemens Ladisch clem...@ladisch.de wrote:
Ming Lei wrote:
On Mon, Jul 1, 2013 at 9:06 PM, Clemens Ladisch clem...@ladisch.de wrote:
Ming Lei wrote:
I understand the latency is effected by packet count in one URB,
and it shouldn't be related
Hi,
On Mon, Jul 01, 2013 at 09:56:37AM -0400, Alan Stern wrote:
On Mon, 1 Jul 2013, Felipe Balbi wrote:
bInterval must be within the range 1 - 16,
That's true only for high speed and SuperSpeed. For low speed and full
speed, bInterval is allowed to range from 1 to 255. See p. 271 in
On Mon, 1 Jul 2013, Felipe Balbi wrote:
Hi,
On Mon, Jul 01, 2013 at 09:56:37AM -0400, Alan Stern wrote:
On Mon, 1 Jul 2013, Felipe Balbi wrote:
bInterval must be within the range 1 - 16,
That's true only for high speed and SuperSpeed. For low speed and full
speed, bInterval
On Sun, 30 Jun 2013, Clemens Ladisch wrote:
Alan Stern wrote:
[...]
This means that the HCD will have trouble telling the difference
between an underrun and a normal restart of a stopped I/O stream. In
both cases it will see an URB being submitted to an empty queue.
Here's where the
On Mon, 1 Jul 2013, ZhenHua wrote:
Let's make it clear:
I said I don't have a machine that this makes action different,
it does not mean my patch did not make the machine act different .
Of course.
There are many kinds of machines, I have never said my patch does
not make ALL of them act
Hi,
On Mon, Jul 01, 2013 at 10:19:28AM -0400, Alan Stern wrote:
On Mon, Jul 01, 2013 at 09:56:37AM -0400, Alan Stern wrote:
On Mon, 1 Jul 2013, Felipe Balbi wrote:
bInterval must be within the range 1 - 16,
That's true only for high speed and SuperSpeed. For low speed and
On Mon, 1 Jul 2013, Ming Lei wrote:
Currently, URB might be probably submitted to HCD too even after
usb_hcd_flush_endpoint() completes since both accesses to
dev-ep_in[epnum]
and ep-enabled aren't protected by effective locks.
The urb_list_lock in hcd.c serves to synchronize
On Mon, 1 Jul 2013, Ming Lei wrote:
On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern st...@rowland.harvard.edu
wrote:
Clement and Laurent:
The two of you seem to be the people who make the most use of
isochronous USB transfers. Since the ehci-hcd driver is being changed
to use a tasklet
On Mon, 1 Jul 2013, Victor Yeo wrote:
Yes, UDC driver has bug. After modifying it, it can receive Set-Config
request with a config value of 0. However, the device descriptor test
- addressed state still fails.
Please see the attached log. The Set-Config request with a config
value of 0 is
On Mon, 1 Jul 2013, Pratyush Anand wrote:
On 6/30/2013 8:32 PM, Alan Stern wrote:
There are several possible things the HCD could do when an underrun
occurs:
I do not have much experience in working with ISOC host.But by the
experience of device side I can say that, There could be
I use this medium to inform you that you are a beneficiary of 3.8 million
pounds willed to you by my late client Mr James Campbell. i advise you get in
touch with me.
Barr Colin Lee
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to
On Mon, 1 Jul 2013, Laurent Pinchart wrote:
That's correct. Unlike the UAC driver, the UVC driver doesn't care too much
about exact timings. Avoiding packet loss is my main concern. As video frames
are not delivered to userspace before they are fully transmitted, and given
the large number
On Mon, 1 Jul 2013, Felipe Balbi wrote:
It makes sense to drop the Full/Low speed check, I'll do that and resend
:-)
Should I add your Reviewed-by or Acked-by ?
If you want to, sure... This isn't a big deal.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb
Hi all guys!
I discovered osmething very funny, something I wasn't expecting.
And when you'll read the story, for sure you will be in my same position! Let
me know.
Relying on the immense knowledge and kindness of Bjorn and you all, I gathered
some infos about the device who made my life
On Mon, Jul 01, 2013 at 05:24:18PM +0300, Felipe Balbi wrote:
Hi,
On Mon, Jul 01, 2013 at 10:19:28AM -0400, Alan Stern wrote:
On Mon, Jul 01, 2013 at 09:56:37AM -0400, Alan Stern wrote:
On Mon, 1 Jul 2013, Felipe Balbi wrote:
bInterval must be within the range 1 - 16,
On Mon, Jul 1, 2013 at 10:44 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 1 Jul 2013, Ming Lei wrote:
Currently, URB might be probably submitted to HCD too even after
usb_hcd_flush_endpoint() completes since both accesses to
dev-ep_in[epnum]
and ep-enabled aren't protected
A sighted person confirmed me that:
- the device has a blue intermittent led when in stand-by mode
- when i connect it, with ndisdup, the led changes to blue, allways on.
And dsflowrpt messages starts.
So - yes, it works.
Now the hard part - wwan interfacing.
--
To unsubscribe from this list:
Clemens:
I'm working with James Stone on a bug report, and maybe you can help.
The main problem seems to be connected with how snd-usb-audio decides
to package its USB transfers. The details are all available at
https://bugs.launchpad.net/bugs/1191603
Here's the quick summary.
James
On Mon, 1 Jul 2013, Ming Lei wrote:
On Mon, Jul 1, 2013 at 10:44 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 1 Jul 2013, Ming Lei wrote:
Currently, URB might be probably submitted to HCD too even after
usb_hcd_flush_endpoint() completes since both accesses to
On Mon, Jul 01, 2013 at 08:31:38AM -0700, Greg KH wrote:
On Mon, Jul 01, 2013 at 05:24:18PM +0300, Felipe Balbi wrote:
Hi,
On Mon, Jul 01, 2013 at 10:19:28AM -0400, Alan Stern wrote:
On Mon, Jul 01, 2013 at 09:56:37AM -0400, Alan Stern wrote:
On Mon, 1 Jul 2013, Felipe Balbi
Hi,
Yes, UDC driver has bug. After modifying it, it can receive Set-Config
request with a config value of 0. However, the device descriptor test
- addressed state still fails.
Please see the attached log. The Set-Config request with a config
value of 0 is the second last USB request sent
On Mon, 1 Jul 2013, Roger Quadros wrote:
On 06/28/2013 10:06 PM, Alan Stern wrote:
On Fri, 28 Jun 2013, Roger Quadros wrote:
That's not what I meant. Never mind the pinctrl; I was asking about
the EHCI controller itself. Under what circumstances does the
controller assert its wakeup
Enrico Mioso mrkiko...@gmail.com writes:
Hi all guys!
I discovered osmething very funny, something I wasn't expecting.
And when you'll read the story, for sure you will be in my same position! Let
me know.
Relying on the immense knowledge and kindness of Bjorn and you all, I
gathered
On Tue, Jul 2, 2013 at 12:02 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 1 Jul 2013, Ming Lei wrote:
On Mon, Jul 1, 2013 at 10:44 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Mon, 1 Jul 2013, Ming Lei wrote:
Currently, URB might be probably submitted to HCD too even
On Tue, 2 Jul 2013, Victor Yeo wrote:
This looks like another bug in the UDC driver. It performs the Status
stage of the Set-Config request before the gadget driver has finished
carrying out the request.
Notice that the USB_REQ_SET_CONFIGURATION case in standard_setup_req()
returns
On Tue, 2 Jul 2013, Ming Lei wrote:
I am wondering if holding the lock in usb_hcd_flush_endpoint() can
avoid the race completely. Suppose usb_hcd_link_urb_to_ep() in submit
path runs on CPU1 just when usb_hcd_flush_endpoint()(called from
usb_disable_endpoint()) completes on CPU0, there is
On Mon, Jul 01, 2013 at 07:12:07PM +0300, Felipe Balbi wrote:
On Mon, Jul 01, 2013 at 08:31:38AM -0700, Greg KH wrote:
On Mon, Jul 01, 2013 at 05:24:18PM +0300, Felipe Balbi wrote:
Hi,
On Mon, Jul 01, 2013 at 10:19:28AM -0400, Alan Stern wrote:
On Mon, Jul 01, 2013 at 09:56:37AM
On Mon, Jul 01, 2013 at 12:24:07PM -0400, Alan Stern wrote:
On Mon, 1 Jul 2013, Roger Quadros wrote:
On 06/28/2013 10:06 PM, Alan Stern wrote:
On Fri, 28 Jun 2013, Roger Quadros wrote:
That's not what I meant. Never mind the pinctrl; I was asking about
the EHCI controller
On Mon, Jul 1, 2013 at 10:44 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 1 Jul 2013, Ming Lei wrote:
However, this does still leave one possible race: On the first
submission to an isochronous endpoint, itd_submit() and sitd_submit()
will allocate a new ehci_iso_stream before
The following changes since commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d:
Linux 3.10-rc7 (2013-06-22 09:47:31 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
tags/usb-3.11-rc1
for you to fetch changes up to
On Mon, Jul 01, 2013 at 09:32:13AM +0300, Kyösti Mälkki wrote:
Hi
Is someone actively working on or maintaining the EHCI debug device
gadget driver? I would like to see some fixes and/or improvements to it
but do not know the gadget framework and some of the required hardware
is not yet on
On Mon, Jul 01, 2013 at 10:45:27AM +0200, Martin van Es wrote:
On Mon, Jul 1, 2013 at 12:17 AM, Greg KH gre...@linuxfoundation.org wrote:
On Sun, Jun 30, 2013 at 09:35:59PM +0200, Martin van Es wrote:
3.9.8 brought a tiny improvement!
scanimage -L now succesfully reports the scanner, but
Ah - I didn't knew there where other devices with an embedded AT channel - I
really don't imagine what could hide on those devices! :)
I can't find the function call you're referrint to, sorry. :(
And - another question. how can the cdc_ncm driver handle notifications if it
has no control over
Enrico Mioso mrkiko...@gmail.com writes:
Ah - I didn't knew there where other devices with an embedded AT channel - I
really don't imagine what could hide on those devices! :)
Yes, but I did not think of it because in the case of the E367 this is a
highly optional feature. MBIM has a
Hi!
I read your mail from the wwan0 interface :) .
This time I was able to understand the netif thing by re-reading the code.
The device works in ncm mode - the wdm device has became inaccessible, and any
attempt to write to it results in a LOT of unknown notifications, obviously.
My dmesg:
...
Hi Alan,
On Monday 01 July 2013 11:08:33 Alan Stern wrote:
On Mon, 1 Jul 2013, Laurent Pinchart wrote:
That's correct. Unlike the UAC driver, the UVC driver doesn't care too
much about exact timings. Avoiding packet loss is my main concern. As
video frames are not delivered to userspace
Here's the usbmon log on bus 01
worflow:
1. cat /sys/kernel/debug/usb/usbmon/1u 1u.mon.out
2. plug scanner
3. scanimage -L
4. unplug scanner
5. stop cat
Regards,
Martin
On Mon, Jul 1, 2013 at 7:34 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Jul 01, 2013 at 10:45:27AM +0200, Martin
Enrico Mioso mrkiko...@gmail.com writes:
Hi!
I read your mail from the wwan0 interface :) .
This time I was able to understand the netif thing by re-reading the code.
The device works in ncm mode - the wdm device has became inaccessible, and
any
attempt to write to it results in a LOT of
On Mon, 1 Jul 2013, Laurent Pinchart wrote:
What about error recovery for insane systems? If we do get a 50-ms gap in
the data stream, what's the best way for the UVC driver to learn this has
happens and attempt to carry on?
When isochronous packets are lost video frames get corrupted.
On Mon, 1 Jul 2013, Martin van Es wrote:
Here's the usbmon log on bus 01
worflow:
1. cat /sys/kernel/debug/usb/usbmon/1u 1u.mon.out
2. plug scanner
3. scanimage -L
4. unplug scanner
5. stop cat
The problems start here:
88023423db40 1844894429 S Bo:1:004:3 -115 4 = 01070001
Alan Stern wrote:
(1) Reject the submission with -EXDEV -- this is what we do now.
(2) Accept the submission, but have the URB complete immediately
with urb-status and all the packet statuses set to -EXDEV.
(3) Accept the submission, but have the URB complete immediately
On Thu, 27 Jun 2013, William Gulland wrote:
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it's necessary to send
two HUB_CLEAR_TT_BUFFER requests to the hub.
Signed-off-by: William Gulland wgull...@google.com
---
On 06/26/2013 05:58 AM, Mikko Perttunen wrote:
Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
The series,
Tested-by: Stephen Warren swar...@nvidia.com
I'll at least apply the *.dtsi changes once the merge window is over,
and prepare a branch so they can be pulled into the USB tree as a
On Mon, 1 Jul 2013, Felipe Balbi wrote:
I don't know what Pad wakeup is. The wakeup signal has to originate
from the EHCI controller, doesn't it? If not, how does the Pad know
when a wakeup is needed?
That's really an OMAP thing, I guess. Pad wakeup sits in the PRCM (IIRC)
inside
On 06/28/2013 06:33 AM, Mikko Perttunen wrote:
This patchset removes the ehci-tegra device tree property nvidia,vbus-gpio
and adds support for the vbus-supply property to phy-tegra-usb.
With bug-fix patch ARM: tegra: fix VBUS regulator GPIO polarity in DT
(which I just sent) applied first, this
On 06/28/2013 03:37 PM, Tuomas Tynkkynen wrote:
USB-related platform data is not used anymore in the Tegra USB drivers,
so remove all of it.
Acked-by: Stephen Warren swar...@nvidia.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to
On 06/28/2013 03:37 PM, Tuomas Tynkkynen wrote:
Register the Tegra PHY device instances with the PHY subsystem so that
the Tegra EHCI driver can locate a PHY via the standard APIs.
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
+ err =
On 06/28/2013 03:37 PM, Tuomas Tynkkynen wrote:
Use the new of_usb_get_dr_mode helper function for parsing dr_mode
from the device tree. Also replace the usage of the custom
tegra_usb_phy_mode enum with the standard enum.
diff --git a/drivers/usb/phy/phy-tegra-usb.c
On 06/28/2013 03:36 PM, Tuomas Tynkkynen wrote:
Hi,
Here's a few cleanup patches for the Tegra USB drivers, to be applied on top
of Mikko's two patch sets. It mostly deals with removing all usage of platform
data and using standard helpers and enums instead of Tegra-specific ones.
With the
Adds the USB device ID (0x12ab) to the ipheth network-over-USB-tethering
driver for iOS devices. Applied and tested against mainline tag v3.10
(as well as 3.8.x and 3.6.y kernel for Raspbian on Raspberry pi)
Signed-off-by: Aaron Marburg amarb...@notetofutureself.org
---
diff -upr -X
1 - 100 of 125 matches
Mail list logo
