hi,
(According to Alan Stern, "as far as I know, all") SD card readers send
MEDIA_CHANGED unit attention notification on (runtime) resume. We cannot
use runtime PM with these devices as I/O always fails in that case.
This fixes runtime PM for SD cardreaders. I'd appreciate any feedback.
To enable runtime PM for an SD cardreader number 0:0:0:0, do:
echo 0 > /sys/module/block/parameters/events_dfl_poll_msecs
echo 1000 > /sys/bus/scsi/devices/0:0:0:0/power/autosuspend_delay_ms
echo auto > /sys/bus/scsi/devices/0:0:0:0/power/control
thank you,
martin
revision history
----------------
v5: (thank you Bart)
* simplify the sense request itself and remove unnecessary code
v4: (thank you Bart and Alan)
* send SENSE REQUEST in sd instead of adding a global scsi error flag.
https://lore.kernel.org/linux-scsi/[email protected]/T/#t
v3: (thank you Bart)
* create a new BLIST entry to mark affected devices instead of the
sysfs module parameter for sd only. still, only sd implements handling
the flag for now.
* cc linux-pm list
https://lore.kernel.org/linux-scsi/[email protected]/
v2:
https://lore.kernel.org/linux-scsi/[email protected]/
* move module parameter to sd
* add Documentation
v1:
https://lore.kernel.org/linux-scsi/[email protected]/T/
For the full background, the discussion started in June 2020 here:
https://lore.kernel.org/linux-scsi/[email protected]/
Martin Kepplinger (3):
scsi: devinfo: add new flag BLIST_MEDIA_CHANGE
scsi: sd: send REQUEST SENSE for BLIST_MEDIA_CHANGE devices in
runtime_resume()
scsi: devinfo: add BLIST_MEDIA_CHANGE for Ultra HS-SD/MMC usb
cardreaders
drivers/scsi/scsi_devinfo.c | 1 +
drivers/scsi/sd.c | 26 +++++++++++++++++++++++++-
include/scsi/scsi_devinfo.h | 6 +++---
3 files changed, 29 insertions(+), 4 deletions(-)
--
2.30.2
For SD cardreader devices that have the BLIST_MEDIA_CHANGE flag set,
a MEDIA CHANGE unit attention is received after resuming from runtime
suspend. Send a REQUEST SENSE to avoid that.
The "downside" is that for these devices we now rely on users not to
really change the medium (SD card) *during* a runtime suspend/resume
cycle, i.e. when not unmounting.
To enable runtime PM for an SD cardreader (device number 0:0:0:0), do:
echo 0 > /sys/module/block/parameters/events_dfl_poll_msecs
echo 1000 > /sys/bus/scsi/devices/0:0:0:0/power/autosuspend_delay_ms
echo auto > /sys/bus/scsi/devices/0:0:0:0/power/control
Signed-off-by: Martin Kepplinger <[email protected]>
---
drivers/scsi/sd.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 6d2d63629a90..b02378f40620 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -63,6 +63,7 @@
#include <scsi/scsi_cmnd.h>
#include <scsi/scsi_dbg.h>
#include <scsi/scsi_device.h>
+#include <scsi/scsi_devinfo.h>
#include <scsi/scsi_driver.h>
#include <scsi/scsi_eh.h>
#include <scsi/scsi_host.h>
@@ -114,6 +115,7 @@ static void sd_shutdown(struct device *);
static int sd_suspend_system(struct device *);
static int sd_suspend_runtime(struct device *);
static int sd_resume(struct device *);
+static int sd_resume_runtime(struct device *);
static void sd_rescan(struct device *);
static blk_status_t sd_init_command(struct scsi_cmnd *SCpnt);
static void sd_uninit_command(struct scsi_cmnd *SCpnt);
@@ -608,7 +610,7 @@ static const struct dev_pm_ops sd_pm_ops = {
.poweroff = sd_suspend_system,
.restore = sd_resume,
.runtime_suspend = sd_suspend_runtime,
- .runtime_resume = sd_resume,
+ .runtime_resume = sd_resume_runtime,
};
static struct scsi_driver sd_template = {
@@ -3720,6 +3722,28 @@ static int sd_resume(struct device *dev)
return ret;
}
+static int sd_resume_runtime(struct device *dev)
+{
+ struct scsi_disk *sdkp = dev_get_drvdata(dev);
+ struct scsi_device *sdp = sdkp->device;
+ int timeout, res;
+
+ timeout = sdp->request_queue->rq_timeout * SD_FLUSH_TIMEOUT_MULTIPLIER;
+
+ if (sdp->sdev_bflags & BLIST_MEDIA_CHANGE) {
+ /* clear the devices' sense data */
+ static const u8 cmd[10] = { REQUEST_SENSE };
+
+ res = scsi_execute(sdp, cmd, DMA_NONE, NULL, 0, NULL,
+ NULL, timeout, 1, 0, RQF_PM, NULL);
+ if (res)
+ sd_printk(KERN_NOTICE, sdkp,
+ "Failed to clear sense data\n");
+ }
+
+ return sd_resume(dev);
+}
+
/**
* init_sd - entry point for this driver (both when built in or when
* a module).
--
2.30.2
These cardreader devices issue a MEDIA CHANGE unit attention not only
when actually a medium changed but also simply when resuming from suspend.
Setting the BLIST_MEDIA_CHANGE flag enables using runtime pm for SD cardreaders.
Signed-off-by: Martin Kepplinger <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
---
drivers/scsi/scsi_devinfo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index d33355ab6e14..8ac0a11ac541 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -171,6 +171,7 @@ static struct {
{"FUJITSU", "ETERNUS_DXM", "*", BLIST_RETRY_ASC_C1},
{"Generic", "USB SD Reader", "1.00", BLIST_FORCELUN | BLIST_INQUIRY_36},
{"Generic", "USB Storage-SMC", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36}, /* FW: 0180 and 0207 */
+ {"Generic", "Ultra HS-SD/MMC", "2.09", BLIST_MEDIA_CHANGE | BLIST_INQUIRY_36},
{"HITACHI", "DF400", "*", BLIST_REPORTLUN2},
{"HITACHI", "DF500", "*", BLIST_REPORTLUN2},
{"HITACHI", "DISK-SUBSYSTEM", "*", BLIST_REPORTLUN2},
--
2.30.2
On 6/30/21 1:44 AM, Martin Kepplinger wrote:
> For SD cardreader devices that have the BLIST_MEDIA_CHANGE flag set,
> a MEDIA CHANGE unit attention is received after resuming from runtime
> suspend. Send a REQUEST SENSE to avoid that.
Reviewed-by: Bart Van Assche <[email protected]>
On Wed, Jun 30, 2021 at 10:44:52AM +0200, Martin Kepplinger wrote:
> + struct scsi_disk *sdkp = dev_get_drvdata(dev);
> + struct scsi_device *sdp = sdkp->device;
> + int timeout, res;
> +
> + timeout = sdp->request_queue->rq_timeout * SD_FLUSH_TIMEOUT_MULTIPLIER;
Is REQUEST SENSE reqlly a so slow operation on these devices that
we need to override the timeout?
Am Donnerstag, dem 01.07.2021 um 15:49 +0100 schrieb Christoph Hellwig:
> On Wed, Jun 30, 2021 at 10:44:52AM +0200, Martin Kepplinger wrote:
> > + struct scsi_disk *sdkp = dev_get_drvdata(dev);
> > + struct scsi_device *sdp = sdkp->device;
> > + int timeout, res;
> > +
> > + timeout = sdp->request_queue->rq_timeout *
> > SD_FLUSH_TIMEOUT_MULTIPLIER;
>
> Is REQUEST SENSE reqlly a so slow operation on these devices that
> we need to override the timeout?
using SD_TIMEOUT works equally fine for me. Is that what you'd rather
like to see?
Bart, is SD_TIMEOUT equally ok for you? If so, I'll resend with your
reviewed-by.
thank you for reviewing!
martin
On 7/2/21 1:04 AM, Martin Kepplinger wrote:
> Am Donnerstag, dem 01.07.2021 um 15:49 +0100 schrieb Christoph Hellwig:
>> On Wed, Jun 30, 2021 at 10:44:52AM +0200, Martin Kepplinger wrote:
>>> + struct scsi_disk *sdkp = dev_get_drvdata(dev);
>>> + struct scsi_device *sdp = sdkp->device;
>>> + int timeout, res;
>>> +
>>> + timeout = sdp->request_queue->rq_timeout *
>>> SD_FLUSH_TIMEOUT_MULTIPLIER;
>>
>> Is REQUEST SENSE reqlly a so slow operation on these devices that
>> we need to override the timeout?
>
> using SD_TIMEOUT works equally fine for me. Is that what you'd rather
> like to see?
>
> Bart, is SD_TIMEOUT equally ok for you? If so, I'll resend with your
> reviewed-by.
Hi Martin,
I prefer sdp->request_queue->rq_timeout instead of SD_TIMEOUT since the
former is configurable via sysfs.
Thanks,
Bart.