Re: RFC: ti_usb-serial: userspace firmware, internal cfg. change, cleanup
Oleg Verych <[email protected]>
| Newsgroups | gmane.linux.usb.devel |
|---|---|
| Organization | Palacky University in Olomouc, experimental physics department |
| Message-ID | <[email protected]> |
On Wed, Nov 14, 2007 at 06:07:27PM +0000, Alan Cox wrote: > On Wed, 14 Nov 2007 16:47:55 +0100 > Oleg Verych <[email protected]> wrote: > > > Al, Greg. > > > > This is all-in-one patch for show. > > > > o File 'tiusb3410.i51' or 'tiusb5052.i51' is being requested from the > > userspace, usually '/lib/firmware/'. > > > > o Reconfiguration is done internally. > > > > o kmalloc() isn't used for copying-copying of the binary. Optimistic > > allocation always requires 4 pages for maximum 16k of data. > > Seems reasonable - is there any reason for not doing a page at a time. > Presumably firmware upload isnt that performance critical, and you may > not find a 16K block on some systems, especially embedded. Sure! I want to make this one as fallback. I've saved 32 bytes for that :) But this case is very rare in the desktops. Anyway, after only this comment it's worth doing! == What about specifying file-size limit on the request? I think it's a common parameter and can be dealt in the loading helper. Also, what about making attempt to allocate usual memory first and then doing virtual allocation? Same parameter can be used as size requesting/memory allocating status? ____ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel