On Saturday 04 November 2006 10:24 am, Till Harbaum wrote: > Hi, > > Am Samstag, 4. November 2006 18:51 schrieb David Brownell: > > On Saturday 04 November 2006 9:04 am, Alan Stern wrote: > > > [libusb can send control messages with appropriate USB_RECIP_* values] > > > > > > There is no way to prevent libusb from being used to send these kinds of > > > messages. If they interfere with the proper operation of the device, > > > that's an indication the device wasn't designed very carefully. > > > > Read that last as: "that indicates the device design is buggy". :) > > Hmm, please explain this a little further since i am the one who built the > device and i can still change these things.
If you've designed it so that the unrestricted requests can change device state, that's the design problem. Classic examples include stuff like reading standard descriptors or status, which are allowed at any time, causing some other operation to misbehave. We've seen some cheap USB peripherals where reading a configuration or device descriptor (using a control request) corrupts a completely unrelated operation using bulk descriptors. That's a design bug: accessing the one functionality shouldn't affect the other one. > My device does all its communication via its control endpoint. Is this already > a bad idea? Not necessarily, but you need to take reasonable care to split out the different functional state machines so they don't interfere with each other. So for example the "USB spec chapter 9" functionality is always active ... and is independent of any other functionality that the device performs. (Except, obviously, that SET_CONFIGURATION is used to activate or deactivate that other functionality.) And if you're using _only_ control requests it should be easy to do this right. You'll only get one control request at a time, unless the host aborts one (maybe the firmware was too slow?) and starts a new one ... easy enough to detect that case. > This is a device based on a software bitbanginf usb on an avr > microcontroller Along the lines of http://www.obdev.at/products/avrusb/index.html I presume ... maybe even http://www.harbaum.org/till/lcd2usb/ :) Given that it's low speed, you do have the technical option to use interrupt IN and OUT transfers. I'd not think that lcd2usb would benefit from that, but other device types might. > and doing it this way since this makes the firmware > significant easier. I have implemented these as vendor specific control > messages. You can use USB_RECIP_INTERFACE to a vendor-specific interface, and that would get filtered out by usbfs. That would in fact be the preferred design style, in terms of following USB spec in spirit while taking minimal liberties with design options. I'm not entirely sure how libusb on Win32 or MacOS (or BSD, etc) would handle such stuff. It may not be possible to "prevent" such access on all platforms. - Dave ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
