Re: [linux-usb-devel] Q for g_file_storage

On Fri, Sep 01, 2006 at 10:55:45PM -0400, Alan Stern wrote: > On Fri, 1 Sep 2006, Marc Singer wrote: > > > I'd like to use g_file_storage without loading it as a module. If I > > can pass something like g_file_storage:g_removable=1 on the command > > line, then I ca

[linux-usb-devel] Q for g_file_storage

I'd like to use g_file_storage without loading it as a module. If I can pass something like g_file_storage:g_removable=1 on the command line, then I can load the backing store once the kernel is loaded. Is there a way to make this work? I suppose I could set the removable bit to 1 by default by

Re: [linux-usb-devel] lh7_udc+g_ether vs WinXP

On Wed, Aug 02, 2006 at 03:18:30PM -0400, Jamie Guinan wrote: > On Thu, 6 Jul 2006, Marc Singer wrote: > > > On Mon, May 15, 2006 at 03:23:29PM -0400, Jamie Guinan wrote: > > > On Thu, 20 Apr 2006, Marc Singer wrote: > > > > > > > Let me know of this

Re: [linux-usb-devel] LH7A404 usb-storage problem

On Tue, Jul 11, 2006 at 11:28:27PM +0800, sinkin wrote: > > > > > It is not a problem with usb-storage. It could be a problem with the > > LH7A404 host driver. > > It could not a problem with LH7A404 host driver, because usblp can work > normally. Well, I wouldn't be so sure about that. >

Re: [linux-usb-devel] lh7_udc+g_ether vs WinXP

On Mon, May 15, 2006 at 03:23:29PM -0400, Jamie Guinan wrote: > On Thu, 20 Apr 2006, Marc Singer wrote: > > > Let me know of this works better for you when connecting to a Windows > > host using RNDIS. > > > > <ftp://ftp.buici.com/pub/arm/gadget> > >

Re: [linux-usb-devel] lh7_udc+g_ether vs WinXP

On Fri, Apr 28, 2006 at 09:56:26AM -0400, Alan Stern wrote: > On Thu, 27 Apr 2006, Marc Singer wrote: > > > I may have been a little hasty. This new driver *does* work properly > > on the lh79524. It still fails test 14 on the lh7a404. I am now very > > suspicious that

Re: [linux-usb-devel] lh7_udc+g_ether vs WinXP

On Thu, Apr 27, 2006 at 02:29:55PM -0700, Marc Singer wrote: > > Let me know of this works better for you when connecting to a Windows > > host using RNDIS. > > > > <ftp://ftp.buici.com/pub/arm/gadget/lh7_udc.c> > > > > I've successfully passe

Re: [linux-usb-devel] lh7_udc+g_ether vs WinXP

> Let me know of this works better for you when connecting to a Windows > host using RNDIS. > > > I've successfully passed all of the USB tests with this driver. There were a couple of buglets as well as a serious logic error. All of the previou

Re: [linux-usb-devel] lh7_udc+g_ether vs WinXP

On Thu, Apr 06, 2006 at 03:27:39PM -0400, Jamie Guinan wrote: > > Hi, > > While the new lh7_udc driver performs great when plugged into a > Linux host, I found that plugging into WinXP with g_ether doesn't > quite work. On the gadget side I see, I've found a couple of buglets in the lh7_udc dr

Re: [linux-usb-devel] lh7_udc+g_ether vs WinXP

On Fri, Apr 07, 2006 at 05:19:49PM -0700, David Brownell wrote: > On Thursday 06 April 2006 12:57 pm, Marc Singer wrote: > > > Suspicious. I won't be able to look at this for at least a week. > > And, it's disappointing that the USB tests weren't enough to vet t

Re: [linux-usb-devel] lh7_udc+g_ether vs WinXP

On Thu, Apr 06, 2006 at 03:27:39PM -0400, Jamie Guinan wrote: > > Hi, > > While the new lh7_udc driver performs great when plugged into a > Linux host, I found that plugging into WinXP with g_ether doesn't > quite work. On the gadget side I see, > > usb0: full speed config #2: 100 mA, Ethern

Re: [linux-usb-devel] ARM problem with a kernel tree commit 329af28b141ab4ae847aff1362864c4cc332641f

On Sat, Mar 25, 2006 at 01:21:00PM -0800, Marc Singer wrote: > The change of the zero_unbind and eth_unbind calls to use __exit > breaks the driver on ARM. It causes a difficult to locate error: > > LD .tmp_vmlinux1 > local symbol 0: discarded in section `.exit.tex

[linux-usb-devel] ARM problem with a kernel tree commit 329af28b141ab4ae847aff1362864c4cc332641f

The change of the zero_unbind and eth_unbind calls to use __exit breaks the driver on ARM. It causes a difficult to locate error: LD .tmp_vmlinux1 local symbol 0: discarded in section `.exit.text' from drivers/built-in.o drivers/built-in.o(.init.text+0x3880): In function `release_mem':

[linux-usb-devel] Revised Sharp-LH7 UDC andriver

I've posted a first pass at a revised UDC driver to support the Sharp LH7 processors. At the moment, only the LH7A404 parts are tested. The hooks are in place for the LH79524 which has more endpoints and some shuffling of the registers. Before I finalize the driver, I'll add DMA support for all o

Re: [linux-usb-devel] Oops when connecting RNDIS gadget to workstation

On Wed, Mar 15, 2006 at 05:47:05PM -0500, Alan Stern wrote: > I don't know why g_ether would have a configuration with no interfaces. > A good question to ask the maintainer. Dave? I found out what the problem is. The ether.c file has explicit code to enable the CDC configuration for every UDC

Re: [linux-usb-devel] Oops when connecting RNDIS gadget to workstation

On Wed, Mar 15, 2006 at 05:47:05PM -0500, Alan Stern wrote: > On Wed, 15 Mar 2006, Marc Singer wrote: > > > > > Isn't that the responsibility of the gadget itself and not the UDC? > > > > > > Yes, it is. What gadget driver were you using for your test?

Re: [linux-usb-devel] Oops when connecting RNDIS gadget to workstation

On Wed, Mar 15, 2006 at 05:25:39PM -0500, Alan Stern wrote: > On Wed, 15 Mar 2006, Marc Singer wrote: > > > > Here Linux get the 9-byte header for descriptor 1. It says wTotalLength > > > = > > > 0x09, which means there are no interface or endpoint descrip

Re: [linux-usb-devel] Oops when connecting RNDIS gadget to workstation

On Wed, Mar 15, 2006 at 05:25:39PM -0500, Alan Stern wrote: > On Wed, 15 Mar 2006, Marc Singer wrote: > > > > Here Linux get the 9-byte header for descriptor 1. It says wTotalLength > > > = > > > 0x09, which means there are no interface or endpoint descrip

Re: [linux-usb-devel] Oops when connecting RNDIS gadget to workstation

On Wed, Mar 15, 2006 at 04:52:14PM -0500, Alan Stern wrote: > On Wed, 15 Mar 2006, Marc Singer wrote: > > > On Wed, Mar 15, 2006 at 01:23:58PM -0800, Marc Singer wrote: > > > On Wed, Mar 15, 2006 at 01:11:42PM -0800, Marc Singer wrote: > > > > I'm upgrad

Re: [linux-usb-devel] Oops when connecting RNDIS gadget to workstation

On Wed, Mar 15, 2006 at 01:23:58PM -0800, Marc Singer wrote: > On Wed, Mar 15, 2006 at 01:11:42PM -0800, Marc Singer wrote: > > I'm upgrading to a newer kernel, currently using 2.6.15, and > > investigating. > > > > EIP is at choose_configuration+0x31/0xa1 [usbc

Re: [linux-usb-devel] Oops when connecting RNDIS gadget to workstation

On Wed, Mar 15, 2006 at 01:11:42PM -0800, Marc Singer wrote: > I'm upgrading to a newer kernel, currently using 2.6.15, and > investigating. > > EIP is at choose_configuration+0x31/0xa1 [usbcore] The fault is here: /* heuristic: Linux is more lik

[linux-usb-devel] Oops when connecting RNDIS gadget to workstation

I'm upgrading to a newer kernel, currently using 2.6.15, and investigating. Unable to handle kernel NULL pointer dereference at virtual address 000d printing eip: f1937684 *pde = Oops: [#1] PREEMPT Modules linked in: usbmon nfs lockd sunrpc radeon drm agpgart vmnet parport_pc

Re: [linux-usb-devel] TEST 14 and USBMON

On Tue, Mar 14, 2006 at 09:44:10PM -0800, Pete Zaitcev wrote: > On Tue, 14 Mar 2006 19:33:19 -0800, Marc Singer <[EMAIL PROTECTED]> wrote: > > > e0865c40 984311403 S Co:057:00 s 01 0b 0 > > e0865c40 984318037 C Co:057:00 0 0 > > e0865c40 9843

[linux-usb-devel] TEST 14 and USBMON

On Tue, Mar 14, 2006 at 11:07:02AM -0800, Marc Singer wrote: > Test 14 is returnng an error 22, EINVAL. It looks like this is due to > the parameters used in that test: > > usbtest 2-2:3.0: TEST 14: 1000 ep0out, 1..512 vary 512 > > The call is being made with the param

[linux-usb-devel] TEST 14

Test 14 is returnng an error 22, EINVAL. It looks like this is due to the parameters used in that test: usbtest 2-2:3.0: TEST 14: 1000 ep0out, 1..512 vary 512 The call is being made with the parameters (dev, param->iterations, param->length, param->vary) and in the code, it checks for va

Re: [linux-usb-devel] UDC failing test 2 and all read tests

On Fri, Mar 10, 2006 at 10:33:45AM -0500, Alan Stern wrote: > On Thu, 9 Mar 2006, Marc Singer wrote: > > > My gadget driver is failing all of the read tests. The trace from > > usbmon looks like this: > > > > ea9379c0 3948991485 S Co:022:00 s 01 0b

[linux-usb-devel] USB 2.0 CardBus adapter

So...I bought a CardBus USB adapter...and it SAID that it is an OHCI compatible adapter, but it isn't. In fact, it doesn't even seem to be properly supported by the UHCI driver. But, that isn't the issue. Can someome recommend a PCMCIA USB 2.0 adapter that uses the OHCI/EHCI driver? -

[linux-usb-devel] UDC failing test 2 and all read tests

My gadget driver is failing all of the read tests. The trace from usbmon looks like this: ea9379c0 3948991485 S Co:022:00 s 01 0b 0 ea9379c0 3948999578 C Co:022:00 0 0 e21dcf40 3949000502 S Bi:022:01 -115 512 < e21dcf40 3949001572 C Bi:022:01 -121 0 My cooked version 0

Re: [linux-usb-devel] Re: Could USBMON be reversing the order of protocol elements?

On Thu, Mar 02, 2006 at 10:35:06AM -0500, Alan Stern wrote: > On Wed, 1 Mar 2006, Marc Singer wrote: > > > What's missing is some semblence of a proper output from the USB > > tests. I'm looking to find out where in the conversation the UDC goes > > awry so th

Re: [linux-usb-devel] usbmon from a connect and a start of test 10

On Wed, Mar 01, 2006 at 08:51:19PM -0800, Pete Zaitcev wrote: > On Wed, 1 Mar 2006 19:30:16 -0800, David Brownell <[EMAIL PROTECTED]> wrote: > > On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote: > > > On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer &

Re: [linux-usb-devel] usbmon from a connect and a start of test 10

On Wed, Mar 01, 2006 at 07:30:16PM -0800, David Brownell wrote: > The thing to understand about test #10 is that it's _trying_ to do things > that UDC drivers often get wrong. Trying to trigger races ("both events > in one IRQ"), trying to issue back-to-back faults so that improper cleanup > of on

Re: [linux-usb-devel] Re: Could USBMON be reversing the order of protocol elements?

On Wed, Mar 01, 2006 at 07:16:26PM -0800, Pete Zaitcev wrote: > On Wed, 1 Mar 2006 18:44:11 -0800, Marc Singer <[EMAIL PROTECTED]> wrote: > > > e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400 > > 0002ff00 00fa0705 02024000 00070581 0240 > >

[linux-usb-devel] Re: Could USBMON be reversing the order of protocol elements?

On Wed, Mar 01, 2006 at 07:16:26PM -0800, Pete Zaitcev wrote: > On Wed, 1 Mar 2006 18:44:11 -0800, Marc Singer <[EMAIL PROTECTED]> wrote: > > > e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400 > > 0002ff00 00fa0705 02024000 00070581 0240 > >

[linux-usb-devel] Could USBMON be reversing the order of protocol elements?

I have this: e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400 0002ff00 00fa0705 02024000 00070581 0240 e2372840 1612603151 S Ci:009:00 s 80 06 0200 0400 1024 < which says to me that the callback was received before the submission. There is not another e2372840 URB af

[linux-usb-devel] Better sample UDC

I've been using the pxa2xx_udc driver as a basis for comparison. Is this the best we have at the moment? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Atten

Re: [linux-usb-devel] usbmon from a connect and a start of test 10

On Wed, Mar 01, 2006 at 06:07:47PM -0800, Pete Zaitcev wrote: > On Wed, 1 Mar 2006 18:00:31 -0800, Marc Singer <[EMAIL PROTECTED]> wrote: > > > > Why don't you enable tracing in UDC or whatever that thing is? > > > I gather that you are hacking

Re: [linux-usb-devel] usbmon from a connect and a start of test 10

On Wed, Mar 01, 2006 at 05:53:14PM -0800, Pete Zaitcev wrote: > On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote: > > > Its response to #11 is what is > > broken. It may be getting confused by the second status request *or* > > it may have s

Re: [linux-usb-devel] usbmon from a connect and a start of test 10

On Wed, Mar 01, 2006 at 04:56:51PM -0800, Pete Zaitcev wrote: > On Wed, 1 Mar 2006 16:27:56 -0800, Marc Singer <[EMAIL PROTECTED]> wrote: > > > 0:15.261198 # 10 S Ci 009:00 s 80 00 0002 ( DtH st dv GET_STATUS > > ) --- 2 < > > 0:15.261201 # 11 S Ci 00

Re: [linux-usb-devel] usbmon from a connect and a start of test 10

I performed a second capture using the driver as present in the kernel archive with a couple of changes so that it would compile. The results are similar. What isn't clear to me is what this apparent error code means and who is sending it. My annotated capture has these entries: 0:15.261198 #

[linux-usb-devel] usbmon from a connect and a start of test 10

I'd appreciate some feedback about this. I'm attaching the raw log as well as showing the output of a simple parser. There are a couple of things that I don't know of they should bother me. In the following output, the time stamps lead the line and are computed as offsets from the first value.

[linux-usb-devel] Folks, please please please use the standard patch format

Patches should apply-able with -p1 when applied at the top-level of the source tree. I know that SVN doesn't do this and it's a big PITA. I've switched to git and found that a) it's a lot better suited to kernel hacking since it handles branching properly, b) it has the right sorts of c

[linux-usb-devel] Starting at the beginning

It looks like I'm going to have to go all the way back to the beginning. I'm seeing a STALL on the device side when I connect the USB cable between the host and device. I don't know if this is an issue, but I suspect that there may be several things going on. I think that the debug messages in t

Re: [linux-usb-devel] Reviving lh7a40x_udc driver

Jamie, The patch changes the behavior, but it still fails test 10. Now, though, I get a bonafide error. [EMAIL PROTECTED] ~/z/usb > sudo ./testusb -a -t 10 unknown speed /proc/bus/usb/002/012 /proc/bus/usb/002/012 test 10 --> 32 (error 32) EPIPE? Since this works for you, I'm going t

Re: [linux-usb-devel] Reviving lh7a40x_udc driver

On Wed, Mar 01, 2006 at 03:34:12PM -0500, Jamie Guinan wrote: > Marc, > > Below is a patch against 2.6.16-rc5, which works with CONFIG_USB_ETH > and CONFIG_USB_ETH_RNDIS. It looks like you found the same thing tha I did, the portc bits were set incorrectly. I was kind of hoping that you hadn't

Re: [linux-usb-devel] Reviving lh7a40x_udc driver

On Wed, Mar 01, 2006 at 10:04:48AM -0800, David Brownell wrote: > On Wednesday 01 March 2006 9:27 am, Marc Singer wrote: > > > > Test #10 taking a few minutes? Sounds troublesome. If this is using > > > an OHCI or EHCI host controller and you've compiled with USB_DE

Re: [linux-usb-devel] Reviving lh7a40x_udc driver

What would be handy is if there was a log of the packets being sent by the usbtest code, and whether or not those packets had the expected result. Is there such a log somewhere? Does the dmesg output show this? There is nothing in async when my test10 goes awry. There is a lot in dmesg, but I'l

Re: [linux-usb-devel] Reviving lh7a40x_udc driver

On Wed, Mar 01, 2006 at 07:39:06AM -0800, David Brownell wrote: > On Wednesday 01 March 2006 1:09 am, Marc Singer wrote: > > On Tue, Feb 28, 2006 at 10:29:03PM -0800, David Brownell wrote: > > > > > > http://www.linux-usb.org/usbtest/#gadgets > > ... > >

Re: [linux-usb-devel] Reviving lh7a40x_udc driver

On Wed, Mar 01, 2006 at 02:50:25PM +0100, Oliver Nittka wrote: > > Marc Singer wrote: > > > The only oddity I've seen so far is that the gadget wasn't detected > > when the target (gadget) rebooted. I know that the driver has an > > error in the USB power

Re: [linux-usb-devel] Reviving lh7a40x_udc driver

On Tue, Feb 28, 2006 at 10:29:03PM -0800, David Brownell wrote: > On Tuesday 28 February 2006 9:48 pm, Marc Singer wrote: > > > The question is this: what is the simplest gadget to use for debugging > > a UDC driver? I started with the serial gadget because I figured it &g

Re: [linux-usb-devel] Reviving lh7a40x_udc driver

On Tue, Feb 28, 2006 at 10:29:03PM -0800, David Brownell wrote: > On Tuesday 28 February 2006 9:48 pm, Marc Singer wrote: > > > The question is this: what is the simplest gadget to use for debugging > > a UDC driver? I started with the serial gadget because I figured it &g

[linux-usb-devel] Reviving lh7a40x_udc driver

Thought I'd turn on the lh7a40x driver for grins and see what happens. Turns out that it didn't even compile. Once that was fixed, it still wouldn't connect using the serial gadget driver. The first error I see, on connecting the USB cable, is -> ERROR: gadget setup FAILED (stalling), setup re

[linux-usb-devel] Re: [PATCH] lh7a404 USB host against 2.6.7-rc2

On Mon, Jun 07, 2004 at 07:56:02PM -0700, David Brownell wrote: > Marc Singer wrote: > > >BTW, I have a USB question that has been vexing me. When I insert a > >USB storage device, the usb-storage.ko module automatically loads. Is > >there a way to supress that behav

[linux-usb-devel] Re: [PATCH] lh7a404 USB host against 2.6.7-rc2

On Mon, Jun 07, 2004 at 07:13:27PM -0700, David Brownell wrote: > > >Ah. Now I remember the issue. Sorry I missed those. Do you need > >anything more from me? Aside from testing once it's in? > > Not that I know of. Unless suspend/resume works on the LH7A404? > > That bus glue might be able

[linux-usb-devel] Re: [PATCH] lh7a404 USB host against 2.6.7-rc2

On Mon, Jun 07, 2004 at 04:37:25PM -0700, David Brownell wrote: > Marc Singer wrote: > >David, this patch comes from applying my original patch and making a > >couple of changes to clean it up. Almost all of it applied cleanly. > >It isn't clear to me what changes you ma

[linux-usb-devel] [PATCH] lh7a404 USB host against 2.6.7-rc2

to just > sanity check it and forward ... the only issue with the previous > one was conflicts with patches I'd just sent myself. Please > send it as a patch with that new "Signed-off-by:" line. Signed-off-by: Marc Singer <[EMAIL PROTECTED]> PATCH diff -Nru a/drivers/u

Re: [linux-usb-devel] [PATCH] lh7a404 Host OHCI driver

On Tue, May 11, 2004 at 12:50:06PM -0700, David Brownell wrote: > Marc Singer wrote: > >Russell King prefers that you, David, upload this patch. Is it all > >good with you? > > Looks basically good at a first scan, but your timing is maybe > a bit off since I'm sub

[linux-usb-devel] [PATCH] lh7a404 Host OHCI driver

temp; - rdata = readl (®s->lsthresh); + rdata = ohci_readl (®s->lsthresh); temp = scnprintf (next, size, "lsthresh 0x%04x\n", rdata & 0x3fff); size -= temp; Index: drivers/usb/host/ohci-hcd.c

[linux-usb-devel] USB host crashing on init-failure

I've found that the ohci-hcd driver may crash if there is a problem while it is initializing. In the implementation(s) I'm looking at, the probe code will call the usb_hcd_x_remove function if there is a problem with the driver starting. The remove call will attempt to dereference ohci->regs whic

Re: [linux-usb-devel] [PATCH & Question] lh7a404 Host OHCI driver

On Wed, Apr 07, 2004 at 12:20:05PM -0700, David Brownell wrote: > >OK. Here's where I stand with this. Someone else made this work. > >For the time being, I'd like to leave it as it is. There are several > >implementations of ohci. All but one is ARM platform specific. IMHO, > >the work necess

Re: [linux-usb-devel] [PATCH & Question] lh7a404 Host OHCI driver

On Wed, Apr 07, 2004 at 10:46:10AM -0700, David Brownell wrote: > > >>and move that to the end of ohci.h? Also: the comments assuming PCI > >>should go; so should the dbg() macros (use pr_debug or ohci_dbg); > >>didn't apply on 2.6.5-mm. > > > > > >This doesn't make sense to me. Can you try agai

Re: [linux-usb-devel] [PATCH & Question] lh7a404 Host OHCI driver

On Wed, Apr 07, 2004 at 10:02:48AM -0700, David Brownell wrote: > Marc Singer wrote: > >I've got a patch that adds OHCI support for a new SoC. I'd say it is > >all good except that it requires a work-around for accessing OHCI > >registers. The code needs to hijack

[linux-usb-devel] [PATCH & Question] lh7a404 Host OHCI driver

readl (®s->fmremaining); + rdata = OHCI_readl (®s->fmremaining); temp = scnprintf (next, size, "fmremaining 0x%08x %sFR=0x%04x\n", rdata, (rdata >> 31) ? " FRT" : "", rdata & 0x3fff); si