Well, I have a few free cycles today and a Clie that I just got syncing
and would love to get working as a usb_storage device, soooo.....
I'm compiling this up now, but I think this is the part of transport.c
that you were talking about, is it not?
/* was this a command-completion interrupt? */
if (us->irqbuf[0] && (us->subclass != US_SC_UFI)) {
US_DEBUGP("-- not a command-completion IRQ\n");
return;
}
I've commented this out and I'm rebuilding. How will this affect other
USB storage devices? Should things be okay without this check? Is
there any way to make it to only skip this check if the attached device
is a Clie (and maybe some other PDAs)?
I'll report back how things go once I reboot.
pete
On Wed, 28 Nov 2001, Matthew Dharm wrote:
> Okay, it looks like it's stuffing some extra status data in the interrupt
> data.
>
> I'm low on time right now... can you remind me next week to look at this?
> What you basically need to do is edit linux/drivers/usb/storage/transport.c
> in CBI_irq and comment out the test against the first byte of the interrupt
> data.
>
> Matt
>
> On Thu, Nov 29, 2001 at 10:52:42AM +0800, Stefan van der Eijk wrote:
> > Matt,
> >
> > >Well, it's violating the specification alright. It's returning bogus
> > >command-completion data.
> > >
> > hmmm... great.
> >
> > >Did this device come with it's own drivers? Or does it use the built-in
> > >drivers under windows?
> > >
> > It's got it's own drivers.
> >
> > >Feel like hacking the source code to try to make it work?
> > >
> > Sure, I'll do what I can. I must warn you that I'm not a programmer...
> > What I can do is help test. Or perhaps give you (root-) access to one of
> > my boxes, with the clie connected to it.
> >
> > Here's the output of usbsniffer on my windows box (snoopy.log.bz2).
> >
> > Stefan
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
