Re: RFC: ti_usb-serial: userspace firmware, internal cfg. change, cleanup

== Wed, Nov 14, 2007 at 11:33:11PM +0000, Alan Cox ==
> > 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
> 
> The assumption is that firmware is sane and also arbitary size limits
> will need updating as firmware and hardware revs change.

Well, i think adding more SRAM, or extending width of the data-bus and to
have same driver, isn't that frequent and easy thing to do. Updating
device ID tables is much more common case.

> You can check the size after request_firmware returns and reject it.
> 
> > making attempt to allocate usual memory first and then doing virtual
> > allocation? Same parameter can be used as size requesting/memory
> > allocating status?
> 
> Very very few callers care about this. I don't think that aspect is
> worthwhile. You can just grab a page and use that as an intermediate case
> in your specific special case instance

Is it possible to have address of a particular mapped page (from the
virtually allocated region) and to work with it, without copying data
unnecessarily? (Sorry if question is stupid, but i didn't have that much
mm experience yet.)

Thanks, appreciated!
____

-------------------------------------------------------------------------
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