Hello Greg Kroah-Hartman:
in drivers/usb/renesas_usbhs/mod_host.c, in function usbhsh_queue_done:
get ureq from pkt, by using the macro usbhsh_pkt_to_ureq (at line 637)
pkt is the sub-object of ureq (line 73..76, line 157..158)
free ureq, by calling function usbhsh_ureq_free (at
-Original Message-
From: Jassi Brar [mailto:jassisinghb...@gmail.com]
Sent: Thursday, December 06, 2012 10:21 PM
Subject: Re: Random MAC address from smsc75xx: How to permanently set?
On Fri, Dec 7, 2012 at 12:21 AM, Dan Williams d...@redhat.com wrote:
On Thu, 2012-12-06 at 12:44
On Fri, Dec 07, 2012 at 08:42:25PM +0800, Chen Gang wrote:
Hello Greg Kroah-Hartman:
in drivers/usb/renesas_usbhs/mod_host.c, in function usbhsh_queue_done:
get ureq from pkt, by using the macro usbhsh_pkt_to_ureq (at line 637)
pkt is the sub-object of ureq (line 73..76, line
On Fri, 2012-12-07 at 14:13 +, Cunningham, Robert wrote:
-Original Message-
From: Jassi Brar [mailto:jassisinghb...@gmail.com]
Sent: Thursday, December 06, 2012 10:21 PM
Subject: Re: Random MAC address from smsc75xx: How to permanently set?
On Fri, Dec 7, 2012 at 12:21 AM,
On Fri, 7 Dec 2012, Chen Gang wrote:
but I still not quite be sure, please help checking (total 3 steps, below).
thanks.
--
Step 1:
in drivers/usb/core/sysfs.c:
for the same device, can
On Fri, 7 Dec 2012, Lan Tianyu wrote:
Maybe you really need two flags. Do whatever is best; I'm sure you can
figure out a good scheme.
Yeah. Two flags maybe good. In this situation, it should be call
power_is_on, right? power_is_on can be used to avoid to sending
redundant PORT_POWER
From: Dan Williams [mailto:d...@redhat.com]
Sent: Friday, December 07, 2012 7:17 AM
Subject: Re: Random MAC address from smsc75xx: How to permanently set?
On Fri, 2012-12-07 at 14:13 +, Cunningham, Robert wrote:
-Original Message-
From: Jassi Brar
On Fri, 2012-12-07 at 15:27 +, Cunningham, Robert wrote:
From: Dan Williams [mailto:d...@redhat.com]
Sent: Friday, December 07, 2012 7:17 AM
Subject: Re: Random MAC address from smsc75xx: How to permanently set?
On Fri, 2012-12-07 at 14:13 +, Cunningham, Robert wrote:
Currently we're allocating an entire page to
serve as our event buffer. Provided our events
are 4 bytes long, it's very unlikely we will
even trigger 1k events at once.
Even in the worst case scenario where every
endpoint triggers one event and we still have
a couple of error events, that would
From: Dongjin Kim tobet...@gmail.com
This patch adds new driver of SMSC USB3503 USB 2.0 hub controller with HSIC
upstream connectivity and three USB 2.0 downstream ports. The specification
can be found from 'http://www.smsc.com/index.php?tid=295pid=325'.
The current version have been tested very
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday, December 06, 2012 04:28:08 PM Sarah Sharp wrote:
On Thu, Dec 06, 2012 at 01:43:32AM +0100, Rafael J. Wysocki wrote:
On Wednesday, December 05, 2012 04:33:44 PM Sarah Sharp wrote:
Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2. I
haven't fully bisected yet.
On Wed, Dec 05, 2012 at 11:55:59AM -0500, Alan Stern wrote:
On Tue, 4 Dec 2012, Sarah Sharp wrote:
+static int hub_set_port_link_state(struct usb_hub *hub, int port1,
+ unsigned int link_status)
+{
+ return set_port_feature(hub-hdev,
+ port1 |
On Wed, Dec 05, 2012 at 12:14:07PM -0500, Alan Stern wrote:
On Tue, 4 Dec 2012, Sarah Sharp wrote:
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
On Wed, Dec 05, 2012 at 01:50:46PM -0500, Alan Stern wrote:
On Tue, 4 Dec 2012, Sarah Sharp wrote:
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
This comes handy when hacking with different cross
compilers, some of which may or may not have
_FORTIFY_SOURCE turned on by default. This patch
allows us to turn _FORTIFY_SOURCE on by specifying
--with-fortify option at configuration time (or
to turn it off by specifying --without-fortify).
If
File doc/usbip_bind_driver.8 does not exist any more but it is
listed in dist_man_MANS. This breaks the build of the userspace.
Remove the file from the list.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/staging/usbip/userspace/Makefile.am | 2 +-
1 file changed, 1
On Wed, Dec 05, 2012 at 02:41:11PM -0500, Alan Stern wrote:
On Tue, 4 Dec 2012, Sarah Sharp wrote:
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
There are a bunch of automatically generated files that git
should not care about.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/staging/usbip/userspace/.gitignore | 28
1 file changed, 28 insertions(+)
create mode 100644
If mkdir() of VHCI_STATE_PATH fails because the directory
already exists, that's not an error. This patch fixes
annoying record connection errors that would typically
come up on attach.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
On Fri, 7 Dec 2012, Sarah Sharp wrote:
2. It doesn't consider a connect status change to be a failed reset. If
multiple warm resets needed to be issued, the connect status may have
changed, so we need to ignore that and look at the port link state
instead. hub_port_reset will now do
Hey Guys,
Sorry I missed this for a while. I'll make a couple of inline
comments, and then I'll summarize my (incomplete) thoughts at the
bottom.
On Wed, Nov 28, 2012 at 02:50:13PM +0100, Sebastian Andrzej Siewior wrote:
On 11/28/2012 02:05 PM, Michal Nazarewicz wrote:
On 11/27/2012
22 matches
Mail list logo
