Re: [coldsync-hackers] New snapshot: 2.2.0

[Greg KH <greg@kroah.com>]

On Wed, Aug 08, 2001 at 06:53:25PM +0200, Koen Deforche wrote:
> Greg KH wrote:
> > Is this:
> >         01ff 0000 0016
> > the bytes that you are talking about?
> 
> That's it! Did you get the linux kernel to print these bytes
> somehow?

No, I copied them from the USBSnoopy dump of a windows machine :)

> > It looks like they get sent from the bulk endpoint like you said.  But
> > they get sent _right_ after initialization.  The visor driver doesn't
> > submit that endpoint until the port is opened.  Which is a lot later in
> > time than the Windows driver.  That might be why there is a difference.
> 
> What do you mean with 'submit that endpoint'? Submit this data
> to user-space? That never seems to happens. In fact, tracing
> usb-serial.c and visor.c, I don't see these 6 bytes at all getting
> even there.

I don't see them either.
For USB, the host has to ask the device if it has any data.  Then the
device can respond.  The device can't respond on its own.  So on Windows
it looks like they do a bulk read _right_ after doing the other
connection negoation.  That is when that data gets sent.

> What happens with these bytes then? Where do they go?

It doesn't look like they get sent by the device.  So I'm guessing the
palm drops them internally.

> So why is this bulk request sent so early? If the driver would
> wait until the serial port gets open()'ed, would it then work
> correctly?

Why does the Windows driver do this?  I have no idea.

The Linux driver currently sends that request when the port gets
open()'ed.  The data never gets sent from the device at that time.  I am
guessing that it doesn't have the data anymore, and has moved on to
other things.  Only a guess though.

> > >  - the first handshaking is different in timing and little
> > >    details from the windows handshaking, and the palm acts
> > >    funny.
> > 
> > I think this is it.
> 
> I am not sure. And if so, what can we do about it?

I have no idea.  Start up our read urb right when the driver connects?
But if we do that, where do we store the data we receive?  We don't have
a tty connection to put the data at that point in time (it gets created
when open() gets called.

And is this data really necessary?  What does this 6 bytes mean?
Ah, to only have a spec...

> [1] Actually, I am a very wanna-be kernel hacker, and I set my-
>     self to get the Palm USB cradle to work with linux to earn
>     my eternal fame with my own kernel driver, and I even got
>     the palm.o module up and running with linux 2.4.5, until I
>     noticed that it was already in the latest kernel, by *you* :)

Does your version of the driver work better than the visor one?  I have
no problem dumping mine if yours works better.  Or just merge them
together.  I'm all for working together, and getting it to all work
properly than for the "eternal fame" :)

thanks,

greg k-h
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.