On Thu, 4 Sep 2014, Peter Chen wrote: > > > Alan, this problem seems not to be existed at g_mass_storage, g_mass_storage > > > has not .disconnect API and only fsg_disable will be called when bus reset > > > occurs. > > > > That sounds like a bug. Shouldn't there be a disconnect callback? > > Don't we want to flush the dirty buffers when a disconnect occurs? > > > > Maybe the dirty buffers are expected to discard if it is a sudden > disconnect. I tried at add debug message before fsg_lun_fsync_sub > at f_mass_storage, below are some findings: > > Windows7: > - click cancel button during the transfer: > [ 766.500854] do_prevent_allow:1383 > [ 766.569848] do_prevent_allow:1383 > [ 766.587965] do_synchronize_cache:957 > - sudden disconnect > fsg_lun_fsync_sub is not called > > linux pc (Linux version 3.16.0-031600-generic) > - click cancel button during the transfer: > fsg_lun_fsync_sub is not called > - sudden disconnect > fsg_lun_fsync_sub is not called > > I think Linux should be improved for the behaviour when click cancel > during the transfer. Maybe, but that means changing the host code, not the gadget code. In general, I think Linux tends to flush caches less often than Windows (at least, for VFAT filesystems). fsg_lun_fsync_sub is probably quite fast if there are no dirty buffers, so adding extra calls won't hurt. The real question is what should the gadget do if the cable gets unplugged _during_ a transfer. I think in that case we really do want to flush the dirty buffers. 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
