From: Alan Stern <email@example.com> To: James Bottomley <James.Bottomley@hansenpartnership.com> Cc: Martin Kepplinger <firstname.lastname@example.org>, Bart Van Assche <email@example.com>, Can Guo <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH] scsi: sd: add runtime pm to open / release Date: Wed, 29 Jul 2020 12:17:23 -0400 [thread overview] Message-ID: <20200729161723.GB1575761@rowland.harvard.edu> (raw) In-Reply-To: <1596037774.4356.42.camel@HansenPartnership.com> On Wed, Jul 29, 2020 at 08:49:34AM -0700, James Bottomley wrote: > On Wed, 2020-07-29 at 11:40 -0400, Alan Stern wrote: > > On Wed, Jul 29, 2020 at 07:53:52AM -0700, James Bottomley wrote: > > > On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote: > [...] > > > > That sense code means "NOT READY TO READY CHANGE, MEDIUM MAY HAVE > > > > CHANGED" so it sounds like it something we should be > > > > ignoring. Usually this signals a problem, like you changed the > > > > medium manually (ejected the CD). But in this case you can tell > > > > us to expect this by setting > > > > > > > > sdev->expecting_cc_ua > > > > > > > > And we'll retry. I think you need to set this on all resumed > > > > devices. > > > > > > Actually, it's not quite that easy, we filter out this ASC/ASCQ > > > combination from the check because we should never ignore medium > > > might have changed events on running devices. We could ignore it > > > if we had a flag to say the power has been yanked (perhaps an > > > additional sdev flag you set on resume) but we would still miss the > > > case where you really had powered off the drive and then changed > > > the media ... if you can regard this as the user's problem, then we > > > might have a solution. > > > > Indeed, I was going to make the same point. > > > > The only reasonable conclusion is that suspending these SD card > > readers isn't safe unless they don't contain a card -- or maybe just > > if the device file isn't open or mounted. > > For standard removable media, I could see issuing an eject before > suspend to emphasize the point. That's not a workable approach in general. For example, you wouldn't want to eject a CD just because it hadn't been used for a couple of minutes and the drive was therefore about to be suspended. > However, sd cards don't work like that > ... they're not ejectable except manually and mostly used as the HDD of > embedded, so the 99% use case is that the user will suspend and resume > the device with the same sdd insert. It does sound like a use case we > should support. Agreed. > > Although support for this sort of thing could be added to the > > kernel, for now it's best to rely on userspace doing the right > > thing. The kernel doesn't even know which devices suffer from this > > problem. > > Can we solve from userspace the case where the user hasn't changed the > media and the resume fails because we don't know? The difficulty is recognizing situations where the media really was changed while the device was suspended. Most devices, AFAIK, don't have any problem with this, but card readers often do. I suppose the kernel could just rely on users not to change media in drives while they are mounted. Then any problems that arise would be the users' fault. Yes, this is nothing more than passing the buck, but it's hard to come up with any better approach. Doesn't Windows do something like this? Alan Stern
next prev parent reply other threads:[~2020-07-29 16:17 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-23 11:10 Martin Kepplinger 2020-06-24 13:33 ` Bart Van Assche 2020-06-25 8:16 ` Martin Kepplinger 2020-06-25 14:52 ` Alan Stern 2020-06-26 3:53 ` Bart Van Assche 2020-06-26 15:07 ` Bart Van Assche 2020-06-26 15:44 ` Alan Stern 2020-06-28 2:37 ` Bart Van Assche 2020-06-28 13:10 ` Alan Stern 2020-06-29 9:42 ` Martin Kepplinger 2020-06-29 16:15 ` Alan Stern 2020-06-29 16:56 ` Bart Van Assche 2020-06-29 17:40 ` Alan Stern 2020-06-30 3:33 ` Martin Kepplinger 2020-06-30 13:38 ` Alan Stern 2020-06-30 15:59 ` Bart Van Assche 2020-06-30 18:02 ` Alan Stern 2020-06-30 19:23 ` Bart Van Assche 2020-06-30 19:38 ` Alan Stern 2020-06-30 23:31 ` Bart Van Assche 2020-07-01 0:49 ` Alan Stern 2020-07-06 16:41 ` Alan Stern 2020-07-28 7:02 ` Martin Kepplinger 2020-07-28 20:02 ` Alan Stern 2020-07-29 14:12 ` Martin Kepplinger 2020-07-29 14:32 ` Alan Stern 2020-07-29 14:44 ` Martin K. Petersen 2020-07-29 14:56 ` Alan Stern 2020-07-29 14:46 ` James Bottomley 2020-07-29 14:53 ` James Bottomley 2020-07-29 15:40 ` Martin Kepplinger 2020-07-29 15:44 ` James Bottomley 2020-07-29 16:43 ` Martin Kepplinger 2020-07-29 18:25 ` Alan Stern 2020-07-29 18:29 ` James Bottomley 2020-07-30 8:52 ` Martin Kepplinger 2020-07-30 8:54 ` Martin Kepplinger 2020-07-30 15:10 ` Alan Stern 2020-08-04 9:39 ` Martin Kepplinger 2020-08-07 9:51 ` Martin Kepplinger 2020-08-07 14:30 ` Alan Stern 2020-08-08 6:59 ` Martin Kepplinger 2020-08-08 15:05 ` Alan Stern 2020-08-09 9:20 ` Martin Kepplinger 2020-08-09 15:26 ` Alan Stern 2020-08-10 12:03 ` Martin Kepplinger 2020-08-10 14:13 ` Alan Stern 2020-08-11 7:55 ` Martin Kepplinger 2020-08-11 13:48 ` Alan Stern 2020-08-23 14:57 ` [PATCH] block: Fix bug in runtime-resume handling Alan Stern 2020-08-24 17:48 ` Bart Van Assche 2020-08-24 20:13 ` Alan Stern 2020-08-26 7:48 ` Martin Kepplinger 2020-08-27 17:42 ` Martin Kepplinger 2020-08-27 20:29 ` Alan Stern 2020-08-29 7:24 ` Martin Kepplinger 2020-08-29 15:26 ` Alan Stern 2020-08-29 16:33 ` Martin Kepplinger 2020-08-29 18:56 ` Alan Stern 2020-08-30 0:38 ` Bart Van Assche 2020-08-30 1:06 ` Alan Stern 2020-07-29 15:40 ` [PATCH] scsi: sd: add runtime pm to open / release Alan Stern 2020-07-29 15:49 ` James Bottomley 2020-07-29 16:17 ` Alan Stern [this message] 2020-07-29 15:52 ` Martin Kepplinger 2020-07-29 18:10 ` Douglas Gilbert 2020-07-30 8:05 ` Martin Kepplinger 2020-07-30 15:14 ` Alan Stern
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200729161723.GB1575761@rowland.harvard.edu \ --email@example.com \ --cc=James.Bottomley@hansenpartnership.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] scsi: sd: add runtime pm to open / release' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.