Hi,
I'm developing an embedded device with USB support. I'm using a 2.4.31 USB
kernel for printer and mass storage support. I have some trouble with UHCI
devices behind an external HUB (it works on the root hub). The problem is, that
the USB device won't be enumerated if it reports a max
On Fri, 14 Jul 2006 14:50:16 -0400 (EDT)
Alan Stern [EMAIL PROTECTED] wrote:
On Fri, 14 Jul 2006, Andrew Morton wrote:
On Fri, 14 Jul 2006 16:54:25 +0100
Andy Chittenden [EMAIL PROTECTED] wrote:
So I guess there's something awry with the USB
controller driver?
Hi,all
Now,i have been testing my udc driver at windowsXP host.
But,i find there are different phenomena at the WindowsXP host
Both hosts are XP Service Pack2.Marked C1(computer 1) and
C2(computer 2).
1.
C1. When finish function of done() for SETUP 80.06 v0300 i
Helow list. I am tryin to install the driver spca5xx, but I need to now how
to compile the driver.
tank you for any heelp!
_
Charla con tus amigos en línea mediante MSN Messenger:
http://messenger.latam.msn.com/
Hi,
On 7/17/06, wagner corrales madrigal [EMAIL PROTECTED] wrote:
Helow list. I am tryin to install the driver spca5xx, but I need to now how
to compile the driver.
tank you for any heelp!
Which webcam you are using? Give its USB IDs from /sbin/lsusb
output. Which Os you are using? If you
On Mon, 17 Jul 2006, Aras Vaichas wrote:
Eventually they ran the test with the laptop disconnected and then
reconnected
our device to see if it still worked after each type of test. It took a while
longer, but we passed.
That's good.
* Is there something in the USB host management code
Everybody:
I wanted to get this onto the public lists before heading out to OLS,
so here it is.
Following is a series of four patches implementing autosuspend and
autoresume for USB. The only interface drivers altered are the hub
driver and usb-skeleton, so most of the features will be visible
This patch (as739) adds the basic infrastructure for USB autosuspend
and autoresume. The main features are:
PM usage counters added to struct usb_device and struct
usb_interface, indicating whether it's okay to autosuspend
them or they are currently in use.
Flag
This patch (as740) removes the existing support for autosuspend of
root hubs. That support fit in rather awkwardly with the rest of
usbcore and it was used only by ohci-hcd. It won't be needed any more
since the hub driver will take care of autosuspending all hubs, root
or external.
This patch (as741) makes the non-hub parts of usbcore actually use the
autosuspend facilities added by an earlier patch.
Devices opened through usbfs are autoresumed and then
autosuspended upon close.
Likewise for usb-skeleton.
Devices are autoresumed for
This patch (as742) adds autosuspend/autoresume support to the USB hub
driver. The largest aspect of the change is that we no longer need a
special flag for root hubs that want to be resumed. Now every hub is
autoresumed whenever khubd needs to access it.
Signed-off-by: Alan Stern [EMAIL
On Jul 14, 2006, at 11:21 AM, Li Yang wrote:
On 7/14/06, Kumar Gala [EMAIL PROTECTED] wrote:
Nack, my expectation is this is all setup by the boot loader.
That's a good wish. ;) However, USB is not required by bootloader. So
it is not likely to be initialized there. And if we put it in
On Mon, 2006-07-17 at 14:16 -0500, Kumar Gala wrote:
On Jul 14, 2006, at 11:21 AM, Li Yang wrote:
On 7/14/06, Kumar Gala [EMAIL PROTECTED] wrote:
Nack, my expectation is this is all setup by the boot loader.
That's a good wish. ;) However, USB is not required by bootloader. So
it is
On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote:
I disagree. You are coming from this from a board that does
everything under the sun. I'd like to avoid having this type of
initialization in the kernel. There is a whole additional kitchen
sink that could move into the kernel as well.
Well,
A few days back, I reported that my Anydata ADU-E100A CDMA/EV-DO modem
works better with the option driver than with the anydata driver. I
now understand better why.
Using the option driver fixed a bug which forced me to cycle power
between closing a ppp connection and opening it again. It also
On Jul 17, 2006, at 3:17 PM, Dan Malek wrote:
On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote:
I disagree. You are coming from this from a board that does
everything under the sun. I'd like to avoid having this type of
initialization in the kernel. There is a whole additional kitchen
On Jul 17, 2006, at 5:39 PM, Kumar Gala wrote:
Well, I think there is a coupling that exists between whatever your
boot rom is and the kernel.
There shouldn't be, I've always said that, but Freescale
seems to want to insist on it :-) The problem is people
creating this evaluation/demo
On Mon, 17 Jul 2006 14:35:21 -0700, Benjamin Cherian [EMAIL PROTECTED] wrote:
I'm skipping the discussion of the spec, but going further, here's
what we have:
It is really looking like you are backing me into a corner to make the change
myself. However, before doing so I'd like to say that I
On Monday 17 July 2006 1:08 pm, Hollis Blanchard wrote:
Seems to me that it's far better to have init code in the kernel than
firmware.
If there's a general Linux policy on the issue, I think that'd be it.
Plus, remember that boot firmware _can't_ always be changed/bugfixed;
sometimes it can,
19 matches
Mail list logo
