Subject: Re: ucycom driver
To: Bill Studenmund <wrstuden@netbsd.org>
From: Nick Hudson <nick.hudson@dsl.pipex.com>
List: tech-kern
Date: 05/12/2005 21:49:14
On Thursday 12 May 2005 18:33, Bill Studenmund wrote:
> On Thu, May 12, 2005 at 01:11:09PM -0400, Nathan J. Williams wrote:
> > Bill Studenmund <wrstuden@NetBSD.org> writes:
> > > On Thu, May 12, 2005 at 03:31:35PM +0200, Quentin Garnier wrote:
> > > > Of course, I'm really no expert of the USB code, so I might be
> > > > missing something.
> > >
> > > I too have to ask why not have this attach as some sort of ucom. I know
> > > very little about the USB code, but as a naive user, I'd expect a
> > > USB<->Serial thingie to use the ucom device node. :-) So if you can do
> > > it, please do. :-)
> >
> > The ucom layer is not, in fact, a universal "usb serial" layer; it
> > just happens to be a convenient abstraction for some devices. It makes
> > some pretty strong assumptions about how the underlying USB device
> > exposes its serial stream (for example, that there's exactly one bulk
> > pipe each way). Thus, it's entirely reasonable that a device that
> > doesn't line up with ucom's assumptions shouldn't use it.
> >
> > If you think ucom *should* be a universal "usb serial" layer, I'd like
> > to know why we should have more than one tty device node/major number
> > anywhere in the tree.
>
> Did you miss the "naive user" part above? :-)
>
> If shoving this driver into ucom would end up bulldozing both, then let's
> not do it. However Quentin's comments indicated that it might be adding a
> few simple abstractions to make it all work. And it sounded like Nick
> hadn't explored that possibility. All I'm asking is "Please explore that
> possibility."

This naive driver hacker 

 - bought a USB RS232 frob which didn't work with any of the ucom drivers
 - tried to hack a ucom driver, but wait this device wants HID reports
 - tried to hack a uhidev driver, but wait this device wants interrupt out
   transfers not bulk.
 - tried to hack the uhidev layer to use interrupt out transfers, but wait
   they don't work
 - fixed a bug in uhci to allow interrupt out transfers

It's still not perfect in that hw flow control is missing. It does get me to 
where I wanted to be which is talking to a Cisco console from my laptop. :)

Nick