On 04/18/2011 05:30 PM, ext Alan Stern wrote:
On Mon, 18 Apr 2011, Roger Quadros wrote:
I was busy with other things last week. I did play with a few things though.
Don't have a fully working solution yet.
I don't see the DELAYED_STATUS mechanism fitting well with the composite
framework, because, for control transfers like SET_CONFIG, the composite
framework is responsible for the status phase, unlike in file_storage.c where it
is responsible for everything.
This sounds like a design flaw in the composite framework. Maybe there
should be a control_complete() framework routine that the function
drivers can call when they have finished all processing needed for a
control transfer.
Yes I agree. Non standard setup requests are fine and it is upto the function
drivers to complete it, however for standard setup requests like SET_CONFIG,
there is no way the function drivers can prevent it from being completed without
blocking.
So, implementing this behavior into composite.c looks to be a better way than
hacking the mass_storage driver design to suite the composite framework limitations.
One way to make it work would be to split the endpoint resetting mechanism and
the FSG state machine's reset mechanism. Currently both are done in
handle_exception.
We could do the endpoint resetting synchronously in fsg_set_alt() and
fs_disable() and leave the state machine resetting to be done in the thread
(handle_exception) at leisure. This way we can ensure that we don't reset the
endpoints again midway when the thread schedules.
I'm not sure that is possible. The setup callback occurs in_interrupt,
so it probably is not able to do things like fsg_set_alt().
The approach I mentioned starts to get ugly, since f_mass_storage was not
designed for SET_CONFIG like operations to be done synchronously.
I was able to get all tests passed with this approach, but it spoils the design
of mass_storage function driver.
--
regards,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
