On Mon, 08 Aug 2011 02:22:14 +0200, Per Forlin wrote:
There may not be one optimal number for all boards. That is the reason for adding the number to Kconfig,
2011/8/8 Michal Nazarewicz mina86@mina86.com:
It could actually be turned into a run-time configuration, but that's a bit more intrusive,
On Mon, 08 Aug 2011 12:50:01 +0200, Per Forlin wrote:
I consider this too but couldn't see how this would be done nicely.
In f_mass_storage.c, the buffers are stored in fsg_common structure as an fixed size array. Instead, this could be replaced by a pointer and buffhds_count field with number of buffers.
The buffhds_count would have to initialised in fsg_common_init() from a (new) field stored in fsg_config structure, which in turn in most cases is filled by values from fsg_module_parameters which correspond to module parameters defined in FSG_MODULE_PARAMATERS() macro.
The buffers are allocated in fsg_common_init() (see line 2815). All that would need to be change is to use value stored in fsg_common instead of FSG_NUM_BUFFERS and first allocate space for the common->buffhds array.
Similarly, fsg_common_realese() would have to get the number of buffers from fsg_common structure and free common->buffhds after freeing each individual buffers.
As far as I can tell, other places where FSG_NUM_BUFFERS is used would be a simple s/FSG_NUM_BUFFERS/common->buffhds_count/g.
If you also care about file_storage.c, almost the same expect the module parameter juggling is a bit easier.
But as I've said previously, it's not like I'm saying that's the way it should be done right now. I'm just describing how it could be done should someone need to be able to change number of buffers via module parameter rather then recompiling the module.