Dear Matthew:
> -Original Message-
> From: Matthew Dharm [mailto:mdharm-...@one-eyed-alien.net]
> Sent: Wednesday, December 19, 2012 11:41 PM
> To: Sebastian Andrzej Siewior
> Cc: Fangxiaozhi (Franko); linux-usb@vger.kernel.org;
> linux-ker...@vger.kernel.org; Xueguiying (Zihan); Linlei (
On 01/04/2013 10:45 AM, Anil Nair wrote:
> Hello Greg,
>
> I tried using the usip in Linux kernel version 2.6.34 but wasn't
> successful. I could't load the driver properly. That was a year ago i
> had to use it for my project, i instead used usb-vhci.
Hi Anil,
I have used the USBIP source for 2.6
On Thu, Jan 3, 2013 at 11:53 AM, Chirkut Daruwalla
wrote:
> Hi,
>
> I've spent quite a bit of time googling for this but came up with very
> little. So I'm hoping someone on this forum can help.
>
> I'm trying to write an open source application for USB redirection
> that will allow users to plug
Hi,
On Fri, Dec 28, 2012 at 2:43 PM, Vivek Gautam wrote:
> Adding support to parse device node data in order to get
> required properties to set pmu isolation for usb-phy.
>
> Signed-off-by: Vivek Gautam
> ---
>
Any further comments on this ? Or does this seem fine ?
--
Thanks & Regards
Viv
Hello Greg,
I tried using the usip in Linux kernel version 2.6.34 but wasn't
successful. I could't load the driver properly. That was a year ago i
had to use it for my project, i instead used usb-vhci.
Anyways Chirkut if you get it working please mention the steps you
followed.And i would also li
On Thu, Jan 3, 2013 at 10:34 AM, Alan Stern wrote:
> On Wed, 2 Jan 2013, Shawn Lewis wrote:
>
>> Am I understanding ehci correctly here? It looks like we only get an
>> interrupt every 8ms even though the isochronous period is 1ms. That's
>> because we can schedule 8 isochronous transactions at a
On Thu, Jan 03, 2013 at 02:21:34PM -0800, Chirkut Daruwalla wrote:
> Hello,
>
> a big thank you for all your responses. Will look into usbip and usb-vhci.
>
> The usbip project states that for kernel vers >= 2.6.28 try linux
> staging. Not sure what this means. Do kernel versions >= 2.6.28 have
>
From: Javier Martinez Canillas
The union xhci_trb *trb variable is defined and assigned
inside the xHCI IRQ handler function but is never used.
Signed-off-by: Javier Martinez Canillas
Signed-off-by: Sarah Sharp
---
drivers/usb/host/xhci-ring.c |2 --
1 files changed, 0 insertions(+), 2 de
Refactor hub_port_wait_reset into a small loop to wait for the port
reset to be complete, and then a larger block to deal with the final
port status. This patch should not change any current behavior.
Signed-off-by: Sarah Sharp
Acked-by: Alan Stern
---
drivers/usb/core/hub.c | 73 +++
Change the code that manually issues a Set Port Feature(Link State) to
use the new helper function hub_set_port_link_state().
Signed-off-by: Sarah Sharp
Acked-by: Alan Stern
---
drivers/usb/core/hub.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/co
When a hot reset fails on a USB 3.0 port, the current port reset code
recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
ideal, since we should avoid recursive calls in the kernel, and it also
doesn't allow us to issue multiple warm resets on reset failures.
Rip out the recur
A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit
transition fails. The current code in hub_events simply issues a warm
reset, but does not call any pre-reset or post-reset driver methods (or
unbind/rebind drivers without them). Therefore the drivers won't know
their device
The next patch will refactor the hub port code to rip out the recursive
call to hub_port_reset on a failed hot reset. In preparation for that,
make sure all code paths can deal with being called with a NULL udev.
The usb_device will not be valid if warm reset was issued because a port
transitioned
The USB core hub thread (khubd) is designed with external USB hubs in
mind. It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.
The xHCI host controlle
The following changes since commit c52804a472649b2e5005342308739434cbd51119:
xhci: Avoid "dead ports", add roothub port polling. (2013-01-03 14:10:29
-0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
for-usb-next-2013-01-03
for you
The EHCI host controller needs to prevent EHCI initialization when the
UHCI or OHCI companion controller is in the middle of a port reset. It
uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under
an EHCI host controller, so it makes no sense to down the semaphore for
USB 3.0 hubs.
The port reset code bails out early if the current connect status is
cleared (device disconnected). If we're issuing a hot reset, it may
also look at the link state before the reset is finished.
Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the
Error state or Resetting state,
An empty port can transition to either Inactive or Compliance Mode if a
newly connected USB 3.0 device fails to link train. In that case, we
issue a warm reset. Some devices, such as John's Roseweil eusb3
enclosure, slip back into Compliance Mode after the warm reset.
The current warm reset code
USB 3.0 hubs and roothubs will automatically transition a failed hot
reset to a warm (BH) reset. In that case, the warm reset change bit
will be set, and the link state change bit may also be set. Change
hub_port_finish_reset to unconditionally clear those change bits for USB
3.0 hubs. If these
John's NEC 0.96 xHCI host controller needs a longer timeout for a warm
reset to complete. The logs show it takes 650ms to complete the warm
reset, so extend the hub reset timeout to 800ms to be on the safe side.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75
When the USB core finishes reseting a USB device, the xHCI driver sends
a Reset Device command to the host. The xHC then updates its internal
representation of the USB device to the 'Default' device state. If the
device was already in the Default state, the xHC will complete the
command with an e
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to p
A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK. If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).
The xHCI code to compute the NAK interval does not handle the special
case of zero properly. The current code un
The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
for-usb-linus-2013-01-03
for you to fetch changes up to c52804a472649b
Hello,
a big thank you for all your responses. Will look into usbip and usb-vhci.
The usbip project states that for kernel vers >= 2.6.28 try linux
staging. Not sure what this means. Do kernel versions >= 2.6.28 have
built in drivers that this project uses?
thanks
Chirkut
On Thu, Jan 3, 2013 at
The attached patch fixes the symptom.
The NULL dereference is caused by "chase_port" in
drivers/usb/serial/io_ti.c as tty == NULL.
Unfortunately I'm not familiar with the usb-serial system.
I guess the tty is already cleaned up and chase_port shouldn't be called
at this point.
It works for me but
On Thu, 3 Jan 2013, Octavio Alvarez wrote:
> I just wanted to mention the following link to this FAQ on the Asus
> website. They blame the OS (Vista) for this, but they don't provide any
> workaround information, except what we already know: either switch to
> +5VSB or disable wakeups.
>
> http:/
On 01/03/2013 12:29 AM, Venu Byravarasu wrote:
> Tegra USB host driver is using port instance number,
> to handle some of the hardware issues on SOC e.g. reset PORT0
> twice etc. As instance number based handling looks ugly,
> making use of information passed through DT for achieving this.
>
> Sig
On Thu, 03 Jan 2013 11:22:19 -0800, Alan Stern
wrote:
On Thu, 3 Jan 2013, [ISO-8859-1] Frank Sch�fer wrote:
Ok, I tried switching the ports to +5VSB.
That makes S3 work (no immediate wakeups).
The problem is, that with this setting, the USB ports are powered ALWAYS
(even when the computer is
On Thu, 3 Jan 2013, [ISO-8859-1] Frank Sch�fer wrote:
> Ok, I tried switching the ports to +5VSB.
> That makes S3 work (no immediate wakeups).
> The problem is, that with this setting, the USB ports are powered ALWAYS
> (even when the computer is switched off completely).
> Great, especially when
Hello.
On 01/03/2013 10:24 PM, Sergei Shtylyov wrote:
>>> MUSB driver has been spoiling kernel output since 3.0 and nobody noticed --
>>> I wonder how good it's actually tested (especially given the face that
>>> loading DaVinci glue as module just hangs DM6446 EVM board).
>Now I'm getting s
This patch fixes the following:
WARNING: vmlinux.o(.text+0x1e709c): Section mismatch in reference from the funct
ion dma_controller_create() to the function .init.text:cppi_controller_start()
The function dma_controller_create() references
the function __init cppi_controller_start().
This is often
Am 28.12.2012 01:10, schrieb Alan Stern:
> On Wed, 26 Dec 2012, Octavio Alvarez wrote:
>
It can't hurt to try the test. Does the patch below make any
difference?
>>> Thank you for the patch, but it makes no difference. :(
> Too bad.
>
>> I looked for more instances of "linux immediate wa
On Wed, 2 Jan 2013, Shawn Lewis wrote:
> Am I understanding ehci correctly here? It looks like we only get an
> interrupt every 8ms even though the isochronous period is 1ms. That's
> because we can schedule 8 isochronous transactions at a time, meaning
> the host controller hardware takes over fo
Hello.
On 11/14/2012 10:09 PM, Sergei Shtylyov wrote:
>> MUSB driver has been spoiling kernel output since 3.0 and nobody noticed --
>> I wonder how good it's actually tested (especially given the face that
>> loading DaVinci glue as module just hangs DM6446 EVM board).
Now I'm getting specta
I've been trying to get the OTG port on my headless embedded OMAP4460 Linux
system into Host mode for months, with no success (dead port) until yesterday,
when I learned that loading any gadget driver makes the Host mode accessible by
pulling the ID line low. Well, sort of, some of the time, wi
On Thu, 3 Jan 2013, victor yeo wrote:
> Hi,
>
> >
> > I use the USBlyzer software on host PC, i can see that SCSI inquiry is
> > sent out by the host PC, but the gadget device does not receive it,
> > due to the mis-match bulk out endpoint. Bulk out endpoint is
> > auto-configured to 2, whereas g
Hello Sebastian,
Please see below
On Thursday, January 03, 2013 4:38 PM I wrote:
> Subject: RE: [PATCH 06/30] usb/gadget: add some infracture to
> register/unregister functions
>
> > +#define DECLARE_USB_FUNCTION(_name, _inst_alloc, _func_alloc)
> > \
> > + static struct usb_f
Hello Sebastian,
On Sunday, December 23, 2012 9:10 PM Sebastian Andrzej Siewior wrote:
> Subject: [PATCH 06/30] usb/gadget: add some infracture to
> register/unregister functions
>
> This patch provides an infrastructure to register & unregister a USB
> function. This allows to turn a function i
Hello.
On 02-01-2013 19:00, Roger Quadros wrote:
Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
but they have different number of ports i.e. 2 and 3 respectively.
So we can't rely on REVISION register for number of ports on OMAP5
and depend on platform data (or device tr
Use more preferable function name which implies using a pseudo-random
number generator.
Signed-off-by: Akinobu Mita
Cc: linux-usb@vger.kernel.org
---
No change from v1
drivers/uwb/rsv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/uwb/rsv.c b/drivers/uwb/rsv.
Hello,
Also do take a look at the following project,
"http://sourceforge.net/projects/usb-vhci/";
A concept little different from USBIP. For the time being its code is
limited to Linux kernels 2.6, it has not be ported to Linux kernel
version 3.0+.
--
Regards,
Anil Nair
--
To unsubscribe from t
On Fri, 28 Dec 2012, Nicholas Santos wrote:
> Patch to add the Formosa Industrial Computing, Inc. Infrared Receiver
> [IR605A/Q] to
> hid-ids.h and hid-quirks.c. This IR receiver causes about a 10 second
> timeout when the
> usbhid driver attempts to initialze the device. Adding this device to
43 matches
Mail list logo
