On Mon, May 03, 2004 at 05:36:47PM -0400, Rita Lin wrote: > > Igh - that sounds like a very bad device design then. > > There would have been lots a ways to do in a clean way without > > additional pipes - such as transfering 0 sized packets to trigger a > > status inquiry or by adding status bytes in each packet. > > For what purpose do you need to poll the status in case for this device? > I would not say it's a very bad device design. However, I do agree with you > that there are numerous way to implement it. Most devices generate > interrupts > when there is a modem status change. This particular device does > not support interrupts.
That is what I call a bad design. You waste resources because the device designer did not take the features he had available. > > Yes that's possible as long a you have separate pipes for each channel. > > But if you have separate pipes for each channel then the device could > > use separate USB interfaces as well so you can attach seprate instances > > of your driver as well without doing special handling. > > > That is correct provided that xxx_softc is handled correctly, otherwise, you > will end up handling wrong ucom_softc each time when driver specific > routines are called. I didn't do any special handling in my driver methods. > > As I mentioned earlier, I only did a trick in declaring the xxx_softc. > ucom_attach() attaches one instance of my driver. I made this comment > because I saw some earlier posts about ucom needed modification to support > multiple ports. If this is a device level driver yes. But I still think that a device with multiple ports and separate pipes per port should also offer multiple USB interfaces. -- B.Walter BWCT http://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
