[U-Boot-Users] PXA27x usbtty start up sequence

[Bryan O'Donoghue]

On Mon, 21 May 2007 00:11:58 +0100
Bryan O'Donoghue <bodonoghue at codehermit.ie> wrote:

> On Mon, 21 May 2007 00:23:42 +0200
> Rodolfo Giometti <giometti at enneenne.com> wrote:
>  
> > The problem is that the defice __is__ into configured state (USB
> > cable is connected and /dev/ttyUSB0 is running) but nobody has
> > opened the serial line (no minicom/kermit running).
> > 
> > So, I suppose, the above modification is useless...

For some reason I seem to fail to parse English occasionally I
thought you'd said your device was in the configured state but, not
physically connected to the HOST ! oops !

You are of course right checking for state configured would not fix
your stall problem if the cable is connected to your PC but, this
pseudo-code below would be a better improvement still... since we
wouldn't even bother _trying_ to send unless the bus was in the
configured state... which is what my warped mind was in fact
attempting to get at.

if(data && state == STATE_CONFIGURED && retries < 10000L){
	/* Blah */
}

You're still wrong about not having to deal with EP0 control requests
after host enumeration, though. g_serial might let you away with it
but, that's just g_serial's oddities I guess. There's no reason a host
couldn't or wouldn't send you periodic get_status requests using
g_serial or any other high level USB protocol and so theoretically if
you don't respond to EP0 control requests the host can reset you ! I
doubt any other driver then g_serial would let you away with this
either !

I still think the fix is #1 above but, having re-read your email

#2
If on TX timeout you propagate an error code upwards to write_buffer,
it should be sufficient I think. write_buffer should be
smart enough to retry tx on the data that didn't get sent and
eventually the __puts() function itself should just give-up !