[linux-usb-devel] Re: PATCH: USB transport support for openobex library

Hi Alex, > here's the patch that adds support for USB transport layer via libusb to > openobex library. The patch for the obex_test application is in the next > message. Specification for these USB OBEX interfaces is available at > http://www.usb.org/developers/devclass_docs > > Devices which su

Re: [linux-usb-devel] BUG in ehci_endpoint_disable (ehci-hcd.c)

On Thu, 10 Feb 2005 14:39:45 -0800, David Brownell <[EMAIL PROTECTED]> wrote: > Pete, if you were to do that it'd surely happen a lot quicker than if I did... > could you be persuaded? I strongly suspect this is the root cause of the only > 2.4 trouble report I've received recently; and the repor

Re: [linux-usb-devel] Re: Patch to change error code for "device not responding"

On Thursday 10 February 2005 12:08 pm, Alan Stern wrote: > >"Device not responding" means either that the device > isn't working right or that it's disconnected from the bus (or there's a > lot of interference on the line, or a hardware fault...). It's a > low-level problem. "Request tim

[linux-usb-devel] [patch 2.6.11-rc] ehci requeue revisit

Here's the patch for the issue Brian Murphy found. Please see if you can get this into the final 2.6.11; this could have some nasty consequences, and seems to be the root cause of two different (new) issues. - Dave This gets rid of a bug found in some IRQ handling logic, after tripping a debug as

Re: [linux-usb-devel] BUG in ehci_endpoint_disable (ehci-hcd.c)

On Thursday 10 February 2005 2:28 pm, Pete Zaitcev wrote: > On Thu, 10 Feb 2005 14:04:27 -0800, David Brownell <[EMAIL PROTECTED]> wrote: > > On Thursday 10 February 2005 1:46 pm, Brian Murphy wrote: > > > > Yes, this fixes the problem (has run through 100 reboots today without > > > problem). It

[linux-usb-devel] Re: [PATCH as460 (8/10)] USBcore: implement usb_add_hcd and usb_remove_hcd (SA1111)

On Thu, Feb 10, 2005 at 02:08:16PM -0800, Christopher Hoover wrote: > > Greg: > > > > This patch contains the changes to the ohci-sa driver. > > > > Alan Stern > > > This patch introduces several paths in the interrupt handler that return > IRQ_NONE. In the original code, we took care (in

Re: [linux-usb-devel] BUG in ehci_endpoint_disable (ehci-hcd.c)

On Thu, 10 Feb 2005 14:04:27 -0800, David Brownell <[EMAIL PROTECTED]> wrote: > On Thursday 10 February 2005 1:46 pm, Brian Murphy wrote: > > Yes, this fixes the problem (has run through 100 reboots today without > > problem). It would crash after 10-15 reboots before. > > Excellent, thanks. Th

Re: [linux-usb-devel] PATCH: USB transport support for openobex library

On Thursday 10 February 2005 2:10 pm, Alex Kanavin wrote: >Specification for these USB OBEX interfaces is available at > http://www.usb.org/developers/devclass_docs Specifically inside http://www.usb.org/developers/devclass_docs/cdc_wmc10.zip which doesn't have OBEX in the title or a

Re: [linux-usb-devel] [PATCH as467] usb-storage: Don't log expected signatures

On Thu, 10 Feb 2005 16:41:30 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote: > +++ edited/drivers/usb/storage/transport.c2005-02-10 16:31:57 -05:00 > @@ -1066,10 +1066,11 @@ >*/ > if (!us->bcs_signature) { > us->bcs_signature = bcs->Signature; > - US_

[linux-usb-devel] Re: PATCH: USB transport support for openobex library

Here's the supplementary patch for openobex-apps. -- Alexander Homepage: http://www.sensi.org/~ak/ diff -uNr -x INSTALL -x Makefile -x Makefile.in -x aclocal.m4 -x autom4te.cache -x config.cache -x config.h -x 'config.h*' -x config.log -x config.status -x configure -x depcomp -x install-sh -x

[linux-usb-devel] PATCH: USB transport support for openobex library

Hello, here's the patch that adds support for USB transport layer via libusb to openobex library. The patch for the obex_test application is in the next message. Specification for these USB OBEX interfaces is available at http://www.usb.org/developers/devclass_docs Devices which support this are

[linux-usb-devel] RE: [PATCH as460 (8/10)] USBcore: implement usb_add_hcd and usb_remove_hcd (SA1111)

> Greg: > > This patch contains the changes to the ohci-sa driver. > > Alan Stern This patch introduces several paths in the interrupt handler that return IRQ_NONE. In the original code, we took care (in usb_hcd_sa_hcim_irq) to always return IRQ_HANDLED, no matter what. I don't recall

Re: [linux-usb-devel] BUG in ehci_endpoint_disable (ehci-hcd.c)

On Thursday 10 February 2005 1:46 pm, Brian Murphy wrote: > David Brownell wrote: > > >>Did you mean something like this? > >> > > > >Yes, does that work OK for you? > > > > Yes, this fixes the problem (has run through 100 reboots today without > problem). > It would crash after 10-15 reboot

[linux-usb-devel] Re: Endpoint queues and URB unlinking

On Thursday 10 February 2005 12:42 pm, Alan Stern wrote: > On Thu, 10 Feb 2005, David Brownell wrote: > > > Right. Except that all the HCDs currently handle the single-URB > > unlink scenarios, so it's seemed like a low priority. If I saw a > > good fix (that didn't lose functionality) I'd be in

Re: [linux-usb-devel] BUG in ehci_endpoint_disable (ehci-hcd.c)

David Brownell wrote: Did you mean something like this? Yes, does that work OK for you? Yes, this fixes the problem (has run through 100 reboots today without problem). It would crash after 10-15 reboots before. /Brian --- SF email is sp

[linux-usb-devel] [PATCH as467] usb-storage: Don't log expected signatures

Greg: This fairly trivial patch makes three small changes: Correct a typo in a comment. Don't print a debugging message when a USB mass-storage device uses the standard signature (the one we would expect normally). Shorten a debugging message and add a newline.

Re: [linux-usb-devel] bulk urb transfer buffer size

On Thu, 10 Feb 2005, Joaquin Durand Gomez wrote: > Can the size of a bulk transfer buffer be grater than the max packet > size for the endpoint? Yes. > Consider the following: > > current_device->read_urb = usb_alloc_urb(0, mem_flags); > usb_fill_bulk_urb(current_device->read_urb, > curren

Re: [linux-usb-devel] Endpoint queues and URB unlinking

On Thu, 10 Feb 2005, Wolfgang Mües wrote: > My driver (auerswald) tries so send more than one URB to ep0 at a time! > But - I have learned that this does not work reliable, especially with > the UHCI hardware. This is mostly because of two facts: > > a) If there is a spike on the line, the retry

[linux-usb-devel] bulk urb transfer buffer size

Can the size of a bulk transfer buffer be grater than the max packet size for the endpoint? Consider the following: current_device->read_urb = usb_alloc_urb(0, mem_flags); usb_fill_bulk_urb(current_device->read_urb, current_device->usb_device, usb_rcvbulkpipe(current_device->usb_device, cu

[linux-usb-devel] Re: Endpoint queues and URB unlinking

On Thu, 10 Feb 2005, David Brownell wrote: > Right. Except that all the HCDs currently handle the single-URB > unlink scenarios, so it's seemed like a low priority. If I saw a > good fix (that didn't lose functionality) I'd be interested. It's a shame the hard parts were all written before anyo

[linux-usb-devel] [patch 2.6.11-rc] teach gadget drivers about s3c2410_udc

As used in various boards including the iPaq h1940; please merge. - Dave This patch makes gadget drivers recognize the UDC controller in the Samsung s3c2310 (ARMv4T). This is used in the iPaq H1940, partially supported by Linux, as well as various other devices. A controller driver is available,

Re: [linux-usb-devel] Re: Patch to change error code for "device not responding"

On Thu, 10 Feb 2005, David Brownell wrote: > > I still think it's a mistake to conflate "device not responding" with > > "request timed out". > > Make that "synchronous request timed out", and it'd be more accurate. > > But I have a hard time agreeing, since UNIX (and hence POSIX and Linux) >

Re: [linux-usb-devel] Endpoint queues and URB unlinking

On Thursday 10 February 2005 8:25 am, Alan Stern wrote: > > How does the design of the USB network class fit in with the notion that a > bulk pipe transmits a single, reliable, logical stream of data? Networks > aren't like that; they transmit unreliably many independent packets. Well, there isn

Re: [linux-usb-devel] Endpoint queues and URB unlinking

On Thu, 10 Feb 2005, Oliver Neukum wrote: > For simply net devices all outstanding packets are canceled. But are you > really sure that no interface at all needs selective unlinking? Have I checked all the in-kernel drivers to see if that's true? No. The statement was made from a theoretical p

Re: [linux-usb-devel] Endpoint queues and URB unlinking

Hello Alan, On Thursday 10 February 2005 16:41, Alan Stern wrote: > We've discussed in the past that the notion of unlinking a single URB > is unnatural. When a driver has multiple URBs queued for an endpoint > it will always want to unlink all of them together; it will never > want to unlink onl

[linux-usb-devel] Re: Endpoint queues and URB unlinking

On Thursday 10 February 2005 7:41 am, Alan Stern wrote: > > We've discussed in the past that the notion of unlinking a single URB is > unnatural. When a driver has multiple URBs queued for an endpoint it will > always want to unlink all of them together; it will never want to unlink > only some -

Re: [linux-usb-devel] Re: Patch to change error code for "device not responding"

On Thursday 10 February 2005 9:36 am, Alan Stern wrote: > On Thu, 10 Feb 2005, David Brownell wrote: > > > But just reverting that particular doc change would be simplest, since > > this doesn't update the various drivers that know ETIMEDOUT gets returned > > in various cases. > > I still think i

Re: [linux-usb-devel] Patch to change error code for "device not responding"

On Thu, 10 Feb 2005 11:13:40 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote: > /* Stall */ -EPIPE, > - /* DevNotResp */ -ETIMEDOUT, > + /* DevNotResp */ -EPROTO, > /* PIDCheck */ -EPROTO, > /* UnExpPID */

[linux-usb-devel] Re: Mapping between port and device file

On Thu, Feb 10, 2005 at 05:34:32PM +0530, [EMAIL PROTECTED] wrote: > > Hi, > > I could not out make out anything from this > Can you please tell me with more details. Did you look in /sys/block/ for your block device you cared about? See the device symlink back to the usb device that controls t

Re: [linux-usb-devel] Endpoint queues and URB unlinking

Am Donnerstag, 10. Februar 2005 17:25 schrieb Alan Stern: > On Thu, 10 Feb 2005, Oliver Neukum wrote: > > > Am Donnerstag, 10. Februar 2005 16:41 schrieb Alan Stern: > > > We've discussed in the past that the notion of unlinking a single URB is > > > unnatural.  When a driver has multiple URBs que

[linux-usb-devel] Re: Patch to change error code for "device not responding"

On Thu, 10 Feb 2005, David Brownell wrote: > I don't like the idea of discarding fault details like that; they've been > too useful for tracking down the root causes of bugs. I also think that > EPROTO is way overused. How about ETIME, to avoid discarding the details? > > But just reverting tha

Re: [linux-usb-devel] USBTest and the 2.4.26 kernel

The other main use of "usbtest" is to test peripheral controller drives ... when the "known good" device is the peripheral, the point is testing the host, and when the "known good" device is the host, the point is testing the peripheral. - Dave ---

Re: [linux-usb-devel] g_file_storage with device RAM

On Thu, 10 Feb 2005, Nemanja Popov wrote: > Hi, > > Is there a possibility to force g_file_storage to transfer captured data > directly from device's RAM instead of using file as a backing storage? > This should be used only for downloading data to host (but writing to id > will be good). Data

Re: [linux-usb-devel] USBTest and the 2.4.26 kernel

Hello from Gregg C Levine You asked, "So "age" is a prerequisite? What will convince you to use 2.6? Have you tried it out in your systems?" Not yet. What will convince me? Why nothing at all. I'll orobably try it out soonest. Gregg C Levine yodathejediknight atsign att dot net -

[linux-usb-devel] Re: [Linux-usb-users] [Long] Ehci, via cle 266, usb2 hard drives and test cases

On Thu, 10 Feb 2005, Samuel Colin wrote: > > It's not clear from what you said; did any of the patches you used > > include this one: > > > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110797162426830&w=2 > > > No, I did the tests before this patch appeared on linux-usb-devel (I > had wat

Re: [linux-usb-devel] lh7a404 USB gadget users?

On Thu, 10 Feb 2005, David Brownell wrote: > > [ Test 2: serial gadget <-> generic USB serial ] > > target# modprobe lh7a40x_udc > > target# modprobe g_serial > > > > host# modprobe usbserial vendor=0x0525 product=0xa4a6 > > I'd have thought by now that usbserial would have > been taught to unde

Re: [linux-usb-devel] g_file_storage with device RAM

On Thursday 10 February 2005 8:07 am, Nemanja Popov wrote: > > Is there a possibility to force g_file_storage to transfer captured data > directly from device's RAM instead of using file as a backing storage? Have you looked at using a ramdisk as the backing store?

[linux-usb-devel] Re: Patch to change error code for "device not responding"

On Thursday 10 February 2005 8:13 am, Alan Stern wrote: > On Wed, 9 Feb 2005, David Brownell wrote: > > > > Do you mind using a different error > > > code for no-response? > > > > I thought about it at one point, but didn't see a good choice about > > what a better code would be. Got a suggest

[linux-usb-devel] Re: [Linux-usb-users] [Long] Ehci, via cle 266, usb2 hard drives and test cases

The Thu, 10 Feb 2005 10:54:54 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > I'm forwarding this message to linux-usb-devel because that's where > many of the USB gurus hang out, not on linux-usb-users. > OK, from now on I will post on linux-usb-devel, I crosspost this message on linux-usb-u

Re: [linux-usb-devel] Endpoint queues and URB unlinking

On Thu, 10 Feb 2005, Oliver Neukum wrote: > Am Donnerstag, 10. Februar 2005 16:41 schrieb Alan Stern: > > We've discussed in the past that the notion of unlinking a single URB is > > unnatural.  When a driver has multiple URBs queued for an endpoint it will > > always want to unlink all of them to

Re: [linux-usb-devel] g_file_storage with device RAM

Hi again, I didn't finished my e-mail (pressed send accidentaly). Is there a way to map that dumy file to device's memory, and when getting is requested on the host side, whole memory is copied instead of that dummy file. Maybe my idea is crazy but I don't know how to approach to this problem. At

Re: [linux-usb-devel] lh7a404 USB gadget users?

On Wednesday 09 February 2005 11:03 pm, Jamie Guinan wrote: > Here is a summary of a few tests... > > [ Test 1: gadget_zero <-> testusb ] > target# modprobe usbtest > target# modprobe g_zero > target# modprobe lh7a40x_udc > > host# modprobe usbtest > host# ./testusb -a > unknown speed /proc/bus

[linux-usb-devel] Patch to change error code for "device not responding"

On Wed, 9 Feb 2005, David Brownell wrote: > > Do you mind using a different error > > code for no-response? > > I thought about it at one point, but didn't see a good choice about > what a better code would be. Got a suggested patch to catch up to > your doc change? Here's one. Admittedly, -

[linux-usb-devel] g_file_storage with device RAM

Hi, Is there a possibility to force g_file_storage to transfer captured data directly from device's RAM instead of using file as a backing storage? This should be used only for downloading data to host (but writing to id will be good). Data in the device's RAM is stored in raw format (no file sy

[linux-usb-devel] Re: [Linux-usb-users] [Long] Ehci, via cle 266, usb2 hard drives and test cases

I'm forwarding this message to linux-usb-devel because that's where many of the USB gurus hang out, not on linux-usb-users. Also, it would help a lot of us readers if you tell your mail client to wrap lines of text after ~70 columns. On Thu, 10 Feb 2005, Samuel Colin wrote: > Greetings list a

Re: [linux-usb-devel] Endpoint queues and URB unlinking

Am Donnerstag, 10. Februar 2005 16:41 schrieb Alan Stern: > We've discussed in the past that the notion of unlinking a single URB is > unnatural.  When a driver has multiple URBs queued for an endpoint it will > always want to unlink all of them together; it will never want to unlink > only some --

Re: [linux-usb-devel] usb driver crashing other apps

Thank you Alan for answering. I had already checked all memory allocation and deallocation but its worth a double and triple check, I'll do that again today. The tasklet_buffer is deallocated inside the process_data() function, thats because I don't know the exact time when the tasklet gets exec

[linux-usb-devel] Endpoint queues and URB unlinking

David: I had an idea this morning. We've discussed in the past that the notion of unlinking a single URB is unnatural. When a driver has multiple URBs queued for an endpoint it will always want to unlink all of them together; it will never want to unlink only some -- that wouldn't make any sense

Re: [linux-usb-devel] 2.6.11-rc3-bk5, oops in scsi_try_bus_reset

On Thu, 10 Feb 2005, Olaf Hering wrote: > I see a few refcount handling bugs in the scsi and/or usb layer. > With a vanilla kernel, plugging an usb stick in , and remove it a few > times: > > > usb 2-1: USB disconnect, address 4 > Oops: kernel access of bad area, sig: 11 [#1] > NIP: CDD3E424 LR:

Re: [linux-usb-devel] usb driver crashing other apps

On Wed, 9 Feb 2005, Joaquin Durand Gomez wrote: > Hello! > > I'm developing a linux driver for a USB fingerprint sensor. > Right now the driver is working correctly, capturing fingerprint images > from the sensor and sending them to a user-space application. > The problem I'm having is that afte

[linux-usb-devel] Re: at91rm9200 udc driver; contributors, bugfinders and testers needed.

Guys: I'd like to have a working driver soon as the crunch point for whether we are able to choose Linux for our embedded platform is fast approaching. I've also noticed a increase in the level of interest from others with regard to this driver. Finally, if any professional feels that they could

[linux-usb-devel] at91rm9200 udc driver; contributors, bugfinders and testers needed.

Hi All, This is an update on the rather slow progress of the at91rm9200 usb device controller's driver. After several months of development we have a driver for the 2.6 kernel which will pass usbtest tests 0-8,11,12. Unfortunately the driver fails at passing the USBCV chapter 9 tests. All four

[linux-usb-devel] RE: Mapping between port and device file

Hi, I could not out make out anything from this Can you please tell me with more details. Regards Shalini G -Original Message- From: Greg KH [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 1:39 PM To: Shalini Rao (WT01 - TELECOM SOLUTIONS) Cc: [EMAIL PROTECTED]; linux-u

RE: [linux-usb-devel] shameless self promotion

Hi Gregh, Its great!!! Thank very much for all who involved in this work. Regards, Shalini G -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg KH Sent: Thursday, February 10, 2005 3:39 PM To: [email protected] Subject: [linux

[linux-usb-devel] 2.6.11-rc3-bk5, oops in scsi_try_bus_reset

I see a few refcount handling bugs in the scsi and/or usb layer. With a vanilla kernel, plugging an usb stick in , and remove it a few times: usb 2-1: USB disconnect, address 4 Oops: kernel access of bad area, sig: 11 [#1] NIP: CDD3E424 LR: CDD05398 SP: C9713F40 REGS: c9713e90 TRAP: 0300Not t

[linux-usb-devel] shameless self promotion

The Third Edition of the Linux Device Drivers book is available this month, and the chapter about USB drivers is on the web site at: http://www.oreilly.com/catalog/linuxdrive3/chapter/ch13.pdf if anyone wants a primer on how to write a USB drive

Re: [linux-usb-devel] USBTest and the 2.4.26 kernel

On Wed, Feb 09, 2005 at 08:25:40PM +, [EMAIL PROTECTED] wrote: > As for "bugs", he's convinced, but I am not, that the 2,6 family is > not as stable as the later releases of the 2,4 series, because it is > still too new. So "age" is a prerequisite? What will convince you to use 2.6? Have yo

Re: [linux-usb-devel] [PATCH 9/63] usb/hub: change parameters of usb_{control,bulk}_msg() to msecs

On Wed, Feb 09, 2005 at 02:09:29PM -0800, Nishanth Aravamudan wrote: > On Wed, Feb 09, 2005 at 09:25:31PM +0100, Oliver Neukum wrote: > > Am Mittwoch, 9. Februar 2005 20:39 schrieb Greg KH: > > > > For maintainability, code needs to have a few basic accommodations > > > > for newcomers -- or semi-f

[linux-usb-devel] Re: Mapping between port and device file

On Wed, Feb 09, 2005 at 01:19:09PM +0530, [EMAIL PROTECTED] wrote: > > Hi, > > > Can you please tell me, is there any way to map between actual USB port > and device files. Its something like > port 1 ->devicefile1 > port 2 ->devicefile2 > port 3 ->devicefile3 > etc > > can you please

[linux-usb-devel] Re: Kernel 2.4.28 PL2303 clocal is not implemented

On Tue, Jan 11, 2005 at 04:11:48PM +0100, Gernot Fink wrote: > On Tue, 11 Jan 2005, Greg KH wrote: > > On Mon, Jan 10, 2005 at 02:24:22PM -0800, Pete Zaitcev wrote: > > > The 2.4 version looks sane, but I would like someone who has a > > > known-working > > > pl2303 to test the patch below against