On Thu, Dec 20, 2001 at 11:04:40AM -0500, [EMAIL PROTECTED] wrote: > > t do all of that processing beforehand, and create a large > > binary image in a .h file of your memory map. Then you have a static > > variable that is your memory map. So when the DSP asks for "swap page > > 'Cause the manufacturer of this modem wants to provide DSP firmware > upgrades by delivering new SRecord-style files, without having to > provide new driver binaries. These are the same files > used across all OS'es for their drivers, which is why they want us to > stick with this format.
Ah, so you're going to be reading this file from kernel space? Not a recommended thing to do. If you are compiling the SRecord file into your driver, it doesn't make sense to not preprocess it ahead of time. > > Or do everything in userspace (as this is where all of the firmware > > download is going in the near future.) Use usbdevfs (or libusb to > > make > > things easier for you.) The linux-hotplug project already has a EZUSB > > firmware downloader in userspace for an example of how to do this. I > > think the Actel DSL modem driver is another example. > > Well, there are many factors. We're working with a codebase that has > been ported from Windows, Macintosh, BSD, etc., attempting to share as > much code as possible across OS'es, and keeping a similar structure. For > this reason we're doing an ethernet driver that encapsulates ethernet > over ATM in the driver, instead of doing an ATM driver - 'cause we've > already got lots of proven code for doing SAR, multiprotocol > encapsulation, etc. The DSP code loading is tightly coupled to a > host-side modem state machine that other parts of the driver use to > determine what they can/can't do (based on the state). So, moving this > to a combination user and kernel driver would require lots of > reengineering at this point. The goal right now is to prove the core > driver code under Linux. Once that is done, we can rework the state > machine/firmware stuff. Thanks for explaining it better. There was a reason some of us created the Device Firmware Upgrade USB spec (to keep people from reinventing the wheel all the time...) > > What's going to be the license for this driver? > > Proprietary - they manufacturer currently has no plans to release the > source. Heh, I wish you and your lawyers the best of luck. Remember not to use any GPLed header files, or cut and paste from any of the existing kernel USB drivers. Also have fun trying to support all of the different kernel versions from all distros (and even versions of those distros.) greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
