On Tue, 21 Aug 2012, Michal Nazarewicz wrote: > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > > This patch (as1598) adds support for the new "reset" callback to the > > g_file_storage driver. Resets are handled slightly differently from > > disconnects, in that the driver doesn't sync the backing storage file > > during a reset but does during a disconnect. > > > > The problem is that a file sync can take a long time if there are many > > dirty pages, which can cause the driver's main thread to miss other > > USB events if they arrive too quickly. After a disconnect we > > generally don't expect to see other events in the near future, whereas > > after a reset we do. > > > > Unfortunately the driver already contains an FSG_STATE_RESET symbol. > > The patch renames it to FSG_STATE_CLASS_RESET, because it refers to a > > class-specific reset event rather than a general USB port reset, and > > uses FSG_STATE_RESET for port resets. The g_mass_storage driver > > shares a source file with g_file_storage; therefore it had to be > > modified accordingly. > > > > Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > > Reported-by: Chen Peter-B29397 <B29397@xxxxxxxxxxxxx> > > Looks good to me. > > Even though it makes me wonder whether f_mass_storage isn't missing > something in its original code. I wondered about that too. The difference is that f_mass_storage uses the composite framework. How does composite handle disconnects and port resets? The framework might need to be modified to pass these events down to the function drivers in separate ways. Alan Stern -- 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
