What's the status of this? Do I still need to test it? I won't have access to the Nook that triggered it the first time for a couple weeks, but I could try to find another device like that. --Andy On Fri, Aug 2, 2013 at 7:18 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2 Aug 2013, Oliver Neukum wrote: > >> On Fri, 2013-08-02 at 09:54 -0400, Alan Stern wrote: >> > On Fri, 2 Aug 2013, Oliver Neukum wrote: >> > >> > > On Thu, 2013-08-01 at 11:53 -0400, Alan Stern wrote: >> > > > On Thu, 1 Aug 2013, Oliver Neukum wrote: >> > > > >> > > > > On Wed, 2013-07-31 at 11:13 -0400, Alan Stern wrote: >> > > > > >> > > > > > More importantly, if we already know that the medium is not present or >> > > > > > has been changed since it was last used, then there's no reason to call >> > > > > > sd_sync_cache() at all. >> > > > > >> > > > > Like this? >> > > > >> > > > Yes, I like this a lot better, except I would put the test for >> > > > !sdkp->media_present in sd_suspend_common() -- no need to print the >> > > >> > > But your observation that it makes no sense while no medium is present >> > > is valid whatever be the reason for wanting to flush. >> > >> > So do the test in both places. >> >> Code duplication for what reasons? > > Like I said before, to avoid printing a misleading line in the kernel > log. > > If you prefer, just get rid of the log message. Or make it KERN_DEBUG > instead of KERN_NOTICE, along with the "Stopping disk" message. Those > two things might get pretty annoying when people start using > block-layer runtime PM. > > Alan Stern > -- Andy Lutomirski AMA Capital Management, LLC -- 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
