Dear Sir/Madam,
Good day would you like to Work online from home and gets paid weekly?
Microlinks Inc. needs a Book-Keeper in the United State, so I want to know if
you will like to work Online from home and getting paid weekly without leaving
or affecting your present Job.
It's just that I
On Thu, 6 Oct 2005 15:20:47 +0530 AnsumanTapan Satpathy wrote:
> Hi,
>
> I am quite new to USB device drivers. I have Linux device which I
> want to publish as a video device. So, basically i want to write a USB
> camera function driver. But I am not able to find any specific
> documents on this
From: Jon Nettleton <[EMAIL PROTECTED]>
To: Steve Calfee <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] ehci_hcd proper negotiation down to usb 1.1
Date: Thu, 06 Oct 2005 20:58:01 -0400
On Thu, 2005-10-06 at 15:39 -0700, Steve Calfe
On Thu, 2005-10-06 at 15:39 -0700, Steve Calfee wrote:
> At 01:51 PM 10/4/2005 -0400, Alan Stern wrote:
>
> >On Tue, 4 Oct 2005, Jon Nettleton wrote:
>
> >> > > Unloading the
> > >> > ehci_hcd with this cable and just using uhci_hcd produced a
> >functioning
> > > >> device. Using a USB 2.0 ca
On Thu, 6 Oct 2005 20:31:54 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> > Is there a particular scenario which this patch fixes?
>
> Yes, at least in part. See kernel bug 4916.
> If the problem is caused by the HID driver spamming the log and
> monopolizing the CPU when a disconnect oc
On Thu, 6 Oct 2005, Pete Zaitcev wrote:
> On Thu, 6 Oct 2005 16:19:40 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > Attached is a patch we may be shipping as a hotfix for RHEL 4 U2 and
> > > which is going to be shipped in U3 by normal means.
> >
> > Why add the error count? Mainline doesn'
On Fri, 7 Oct 2005, Vojtech Pavlik wrote:
> On Thu, Oct 06, 2005 at 04:43:44PM -0400, Alan Stern wrote:
> > Vojtech:
> >
> > This patch (as576) removes some mistaken tests for disconnection from the
> > HID driver. -EILSEQ refers to an arbitrary low-level protocol error, not
> > necessarily a
On Thu, 6 Oct 2005, Pete Zaitcev wrote:
> On Thu, 6 Oct 2005 16:43:44 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > This patch (as576) removes some mistaken tests for disconnection from the
> > HID driver. -EILSEQ refers to an arbitrary low-level protocol error, not
> > necessarily
On Thu, Oct 06, 2005 at 04:07:47PM -0700, Pete Zaitcev wrote:
> On Thu, 6 Oct 2005 16:43:44 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > This patch (as576) removes some mistaken tests for disconnection from the
> > HID driver. -EILSEQ refers to an arbitrary low-level protocol error,
On Thu, Oct 06, 2005 at 04:43:44PM -0400, Alan Stern wrote:
> Vojtech:
>
> This patch (as576) removes some mistaken tests for disconnection from the
> HID driver. -EILSEQ refers to an arbitrary low-level protocol error, not
> necessarily a disconnection. Also, a completion routine will never s
On Thu, Oct 06, 2005 at 04:50:21PM -0400, Alan Stern wrote:
> Vojtech:
>
> This patch (as577) adds a Clear-Halt call on the Interrupt-in endpoint
> during configuration. I'm not entirely sure that it's a good idea, and I
> haven't been able to test it on a wide variety of devices.
>
> However
At 01:51 PM 10/4/2005 -0400, Alan Stern wrote:
On Tue, 4 Oct 2005, Jon Nettleton wrote:
> > Unloading the
>> > ehci_hcd with this cable and just using uhci_hcd produced a
functioning
> >> device. Using a USB 2.0 cable with the ehci_hcd driver also produced
a
> > functioning device. > > >
On Thu, 6 Oct 2005 16:43:44 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> This patch (as576) removes some mistaken tests for disconnection from the
> HID driver. -EILSEQ refers to an arbitrary low-level protocol error, not
> necessarily a disconnection. Also, a completion routine will n
On Thu, 6 Oct 2005 16:19:40 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> > Attached is a patch we may be shipping as a hotfix for RHEL 4 U2 and
> > which is going to be shipped in U3 by normal means.
>
> Why add the error count? Mainline doesn't do it that way.
Yes, mainline stops resubmitting a
On Fri, Oct 07, 2005 at 01:08:56AM +0200, Vojtech Pavlik wrote:
> On Thu, Oct 06, 2005 at 04:43:44PM -0400, Alan Stern wrote:
> > Vojtech:
> >
> > This patch (as576) removes some mistaken tests for disconnection from the
> > HID driver. -EILSEQ refers to an arbitrary low-level protocol error, no
On Thu, 6 Oct 2005, Greg KH wrote:
> On Mon, Oct 03, 2005 at 04:36:29PM -0400, Alan Stern wrote:
> >
> > P.S.: I'm puzzled by the quirk_piix3_usb routine at the start of the
> > pci-quirks.c file. Doesn't that handle UHCI controllers?
>
> Yes, it does, for only a specific pci device.
>
> >
On Thu, 6 Oct 2005, Greg KH wrote:
> On Mon, Oct 03, 2005 at 04:36:29PM -0400, Alan Stern wrote:
> > Greg:
> >
> > This patch (as574) updates the PCI BIOS usb-handoff code for UHCI
> > controllers, making it work like the reset routines in uhci-hcd. This
> > allows uhci-hcd to drop its own routi
On Mon, Oct 03, 2005 at 04:36:29PM -0400, Alan Stern wrote:
>
> P.S.: I'm puzzled by the quirk_piix3_usb routine at the start of the
> pci-quirks.c file. Doesn't that handle UHCI controllers?
Yes, it does, for only a specific pci device.
> Is there some reason to have a separate routine, or
On Mon, Oct 03, 2005 at 04:36:29PM -0400, Alan Stern wrote:
> Greg:
>
> This patch (as574) updates the PCI BIOS usb-handoff code for UHCI
> controllers, making it work like the reset routines in uhci-hcd. This
> allows uhci-hcd to drop its own routines in favor of the new ones
> (code-sharing).
>
Vojtech:
This patch (as577) adds a Clear-Halt call on the Interrupt-in endpoint
during configuration. I'm not entirely sure that it's a good idea, and I
haven't been able to test it on a wide variety of devices.
However I do have an HP keyboard that won't work without it. More
accurately, the
Vojtech:
This patch (as576) removes some mistaken tests for disconnection from the
HID driver. -EILSEQ refers to an arbitrary low-level protocol error, not
necessarily a disconnection. Also, a completion routine will never see a
status of -EPERM; that's used only to indicate a failure during
Greg:
This patch (as575) fixes an unlikely race in the g_file_storage driver.
The problem can occur only when the driver is unbound before its
initialization routine has finished.
I also took the opportunity to replace kmalloc/memset with kzalloc.
Alan Stern
Signed-off-by: Alan Stern <[EMA
Hi,
I have a Pegasus USB to Ethernet adapter. In the 2.6.9 kernel the link
status was broken. I upgraded to FC4, and now the link status has
improved, and is half working, meaning that ethtool reports the correct
link status, but the /sys/class/net/eth1/carrier reports "1" all the time,
and Networ
Undiscovered Gem St0ck_Report
Company Profile:
+
CEO AMERICA INC.
Symbol: CEOA . pk
Recent Price: $3.00
Expected Trading Range: $5.50 - $6.00 (post split)
Shares Outstanding: 35M (est.)
Float (est.): 5M
++
On Wed, Oct 05, 2005 at 03:47:28PM -0700, Pete Zaitcev wrote:
> A user complains that "cat /proc/bus/usb/devices" hangs. This happens
> after plugging a particular storage device. Anyone is interested?
> Apparently, happens on stock kernel as well.
> https://bugzilla.redhat.com/bugzilla/show_bug.c
On Thu, Oct 06, 2005 at 01:02:19PM +0200, Freaky wrote:
> Can't check now, but what I mean is that syslog will only give one line,
> that an USB device is inserted. Nothing more. I can find the device in
> /sys/usb... so the system sees it, it just doesn't know what to do with
> it.
There is no su
Can't check now, but what I mean is that syslog will only give one line,
that an USB device is inserted. Nothing more. I can find the device in
/sys/usb... so the system sees it, it just doesn't know what to do with
it.
Will checkup on libusb, I'm not a programmer though. Know a little C++
syntax,
Hi,
I am quite new to USB device drivers. I have Linux device which I
want to publish as a video device. So, basically i want to write a USB
camera function driver. But I am not able to find any specific
documents on this.
Please suggest me some documents.
Regards.
Ansuman
Am Donnerstag, 6. Oktober 2005 10:30 schrieb Eric Piel:
> Did it, nothing to agree or to sign. FWIW, the document converted to
> PDF, only with opensource software, is available here (supprisingly,
> inside the document it's written that it's a draft):
> http://pieleric.free.fr/MTP_Enhanced.pdf
Am Donnerstag, 6. Oktober 2005 10:08 schrieb Freaky:
> Sorry if this is the wrong place to ask. But I figured it needs kernel
> support first, because the USB device isn't recognized at all. MTP has a
> general USB interface like mass storage from what I understand, so we'll
> need drivers for
[ second half ]
> All right. Having said all of that, I'll respond to some of your
> comments.
I'll shrink this response by removing most points of agreement. :)
> > A different driver controls the
> > upstream link ... maybe a different instance of the hub driver (for
> > USB links)
[ Your post was quite long and my response will be ]
[ split in the middle at a natural break ... ]
> To begin with, let's agree that we're considering only runtime PM. For
> system PM none of this matters, because during a system sleep _all_
> devices get suspended and afterward
32 matches
Mail list logo
