On Tue, Oct 12, 2004 at 07:01:41PM -0700, David Brownell wrote:
> On Tuesday 12 October 2004 3:16 pm, Russell King wrote:
> > 3. bh discovers the device speed and enables SOFs
> > 4. some time later, the USB subsystem issues a reset, which disables SOFs
>
> Strictly speaking, speed isn't known unt
Hi,
Because of the new method of looking for a union descriptor to detect an ACM
device detection of several modems I have fails.
I have found out the problem is that the usb_parse_configuration
routine does not take account of descriptors which lie after the last
interface descriptor so the extral
whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.
At Wed Oct 13 14:43:49 2004 the content filters said:
Found dangerous IFrame tag in HTML message
Note to Help Desk: Look on the MailScanner in
/var/spool/MailScanner/q
Am Mittwoch, 13. Oktober 2004 14:10 schrieb Brian Murphy:
> Hi,
> Because of the new method of looking for a union descriptor to detect an ACM
> device detection of several modems I have fails.
>
> I have found out the problem is that the usb_parse_configuration
> routine does not take account of
On Tue, 12 Oct 2004, Pete Zaitcev wrote:
> On Tue, 12 Oct 2004 10:12:01 -0400 (EDT)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > > > Simply because there may be devices that work with the old scheme but not
> > > > with the new one.
> > >
> > > I considered this, and I see it as a textbook case
On Tue, 12 Oct 2004, David Brownell wrote:
> > There's already code in hub_port_init to scrub ep0 for full-speed devices
> > when the ep0 maxpacket value is different from the initial guess. I can
> > make that unconditional, for all devices. Would that be okay?
>
> Not needed. There are two
G'Morning,
On Wednesday 13 October 2004 6:51 am, Alan Stern wrote:
> On Tue, 12 Oct 2004, David Brownell wrote:
>
> > There are two cases where an HCD needs records
> > to be invalidated (unless it's UHCI or other hardware that doesn't
> > "know" such things:
> >
> > (a) HCD records en
On Tue, 12 Oct 2004, Laurent Riffard wrote:
> Hello,
>
> I posted the following bug to linux-usb-devel, and I did not receive
> any reply.
>
> As the problem still occurs with 2.6.9-rc4-mm1
> (optimize-profile-path-slightly.patch reverted), I decided to post
> it again.
>
> I cc Greg KH beca
On Wednesday 13 October 2004 1:59 am, Russell King wrote:
> On Tue, Oct 12, 2004 at 07:01:41PM -0700, David Brownell wrote:
> >
> > SOFs have to start within something like 3msec after
> > the reset finishes. What's with punting all this to a BH?
>
> The badly written SL811 driver code. 8)
:)
- Add support for Corega USB2-TX device.
Reported by Naoki Shibata <[EMAIL PROTECTED]>
Signed-off-by: David Hollis <[EMAIL PROTECTED]>
--
David Hollis <[EMAIL PROTECTED]>
- Add support for Corega USB2-TX device.
Reported by Naoki Shibata <[EMAIL PROTECTED]>
Signed-off-by: David Hollis <[EMA
David Brownell wrote:
On Wednesday 13 October 2004 5:10 am, Brian Murphy wrote:
I have found out the problem is that the usb_parse_configuration
routine does not take account of descriptors which lie after the last
interface descriptor so the extralen parameters are set to 0 even though
there *
On Tue, Oct 12, 2004 at 12:55:28PM -0800, leif wrote:
> > From: leif [mailto:[EMAIL PROTECTED]
> > Just a small patch to add support for the Microsoft branded
> > Pharos GPS-360.
> >
> > The device uses the same driver, just requires the additional
> > product_id of 0xaaa0
> >
> >
> > Please
On Wed, Oct 13, 2004 at 06:25:05PM +0200, Harald Dunkel wrote:
> Greg KH wrote:
> >Hi,
> >
> >Here are 5 USB fixes against the latest 2.6.9-rc4 tree. They do the
> >following:
> > - fix a oops in the digi_acceleport driver
> > - fix a SMP race in the ehci_hcd driver
> > - fix a lockup
On Tue, Oct 12, 2004 at 11:29:08AM -0700, Pete Zaitcev wrote:
> On Tue, 12 Oct 2004 10:12:01 -0400 (EDT)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > > > Simply because there may be devices that work with the old scheme but not
> > > > with the new one.
> > >
> > > I considered this, and I see i
Hi folks,
Kernel 2.6.9-rc4, amd64:
If I do insmod ehci_hcd (which triggers some hotplug
events), then I get these messages in kern.log:
:
ACPI: PCI interrupt :00:02.2[C] -> GSI 11 (level, low) -> IRQ 11
ehci_hcd :00:02.2: nVidia Corporation nForce3 USB 2.0
PCI: Setting latency timer of devi
On Wed, 13 Oct 2004, Greg KH wrote:
> I'm glad someone raised the point about speed, the "windows" way of
> enumerating a device is very slow compared to ours. Which is one nice
> comment that I hear all the time from users, "Linux is faster at
> recognizing my USB device!"
It depends on the dev
On Wednesday 13 October 2004 11:11 am, Brian Murphy wrote:
> OK. But I have a Lasat modem which is ~6 years old which puts all the
> class specific descriptors at the end after the *normal* descriptors
> and which has worked up to 2.6.7.
That's probably when the CDC descriptor parsing was added;
Greg:
This patch implements the Windows scheme for USB device initialization.
It also incorporates the change recently posted by David to scrub the
endpoint state following a SET-ADDRESS. Other noteworthy changes:
There is a #undef near the start of the source file which can
be
> OK but in 2.6.8.1 the endpoint extra info is not searched for class
> specific descriptors.
> It seems perfectly reasonable to me to put these descriptors after the
> endpoint
> descriptors.
That is a common (mis)reading. Therefore a fix is in the pipeline and
hopefully in 2.6.9.
> You find
On Fri, 1 Oct 2004, Jon Kåre Hellan wrote:
> I am seeing strange behaviour with my USB stick. I can mount it
> the first time it is inserted, but after unmounting, unplugging, and
> plugging in again, it can't be mounted.
>
> I have also seen one case where it was possible to mount it the second
Oliver Neukum wrote:
OK but in 2.6.8.1 the endpoint extra info is not searched for class
specific descriptors.
It seems perfectly reasonable to me to put these descriptors after the
endpoint
descriptors.
That is a common (mis)reading. Therefore a fix is in the pipeline and
hopefully in 2.6.9
Am Mittwoch, 13. Oktober 2004 22:23 schrieb David Brownell:
> > Is it then a good thing to rely on the existance
> > of a union descriptor to signal the validity of a CDC device?
>
> For devices that allegedly implement a class specification,
> there need to be limits on how much nonconformance a
The following 3 patches add support big-endian OHCI implementations.
This is version 3 of these patches. There are no substantive
changes from version 2. It has only been resynchronized with
the current linux-2.6 source tree.
These patches have been tested on IBM's stb04xxx and Freescale's
MPC5
Patch 1 of 3.
Replace little-endian-only constants in ohci.h with cpu-native
constants, so that they can be converted to little-endian or big-endian
depending on the OHCI controller being used.
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
diff -Nru a/drivers/usb/host/ohci-dbg.c b/drivers/u
Am Mittwoch, 13. Oktober 2004 23:17 schrieb Brian Murphy:
> >That is a common (mis)reading. Therefore a fix is in the pipeline and
> >hopefully in 2.6.9.
> >
> >
> >
> If you really believe this to be a misreading where in the standards do
> they give
> *any* indication of the order of descript
Patch 2 of 3.
This patch adds support to the OHCI code for big-endian controllers
while maintaining the existing support for little-endian controllers.
This is done primarily by applying the following transforms when
dealing with controller data:
ohci_readl(p) --> ohci_read(ohci, p)
Patch 3 of 3.
Adds support for the ohci controllers found on the IBM STB04xxx and
Freescale MPC52xx embedded chips. In addition to the low level hcd
support added in drivers/usb/host/ohci-ocp.c, it contains code for
2 quirks of these OHCI implementations.
Quirk 1: The IBM and Freescale implement
I posted this before, but didn't see any discussion.
This patch fixes a couple of places where the usb subsystem
DMAs to/from local (stack) variables. This doesn't work on
non-cache-coherent processors. I'm testing on PPC 4xx systems.
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
diff -Nr
This is a Dell Precision 650 running linux-2.4.28-pre3. It's got the
usb-uhci and echi-hcd modules loaded.
I've got a new error code showing up with this USB2 hub. On insertion,
I get:
Oct 13 15:35:55 tbolt kernel: hub.c: new USB device 00:1d.7-5, assigned
address 2
Oct 13 15:35:55 tbolt kerne
On Wednesday 13 October 2004 2:23 pm, Dale Farnsworth wrote:
> The following 3 patches add support big-endian OHCI implementations.
>
> This is version 3 of these patches. There are no substantive
> changes from version 2. It has only been resynchronized with
> the current linux-2.6 source tree.
I was wondering if you wouldn't mind giving me a brief heads up on the
state of OTG support in 2.6 I saw on the linux usb site that TI
provided some support for OTG. I was wondering what the actually
meant.
thanks
- kumar
---
This SF.net ema
On Wed, Oct 13, 2004 at 09:54:41PM +, David Brownell wrote:
> On Wednesday 13 October 2004 2:23 pm, Dale Farnsworth wrote:
> > The following 3 patches add support big-endian OHCI implementations.
> >
> > This is version 3 of these patches. There are no substantive
> > changes from version 2.
On Wednesday 13 October 2004 5:10 am, Brian Murphy wrote:
> I have found out the problem is that the usb_parse_configuration
> routine does not take account of descriptors which lie after the last
> interface descriptor so the extralen parameters are set to 0 even though
> there *is* extra informa
Alan Stern wrote:
There is a #undef near the start of the source file which can
be changed to #define to enable use of the old initialization
scheme. If the symbol is not defined then most of the old code
will be optimized away by the compiler.
Shouldn't this be a b
34 matches
Mail list logo
