2021-01-13 01:27:40

by Martin Kepplinger

[permalink] [raw]
Subject: [PATCH v2 0/3] scsi: add runtime PM workaround for SD cardreaders

revision history
----------------
v2:
* move module parameter to sd
* add Documentation

v1:
https://lore.kernel.org/linux-scsi/[email protected]/T/#t



hi,

In short: there are SD cardreaders that send MEDIA_CHANGED on
runtime resume. We cannot use runtime PM with these devices as
I/O basically always fails. I'd like to discuss a way to fix this
or at least allow users to work around this problem:

For the full background, the discussion started in June 2020 here:
https://lore.kernel.org/linux-scsi/[email protected]/

and I sent the first of these patches in August, as a reference:
https://lore.kernel.org/linux-scsi/[email protected]/
so this is where I'm following up on.

I'm not sure whether maintaining an in-kernel quirk for specific devices
makes sense so here I suggest adding a userspace knob. This way there's at
least a chance to use runtime PM for sd cardreaders that send MEDIA_CHANGED.

I'd appreciate any feedback.

Martin Kepplinger (3):
scsi: add expecting_media_change flag to error path
scsi: sd: add ignore_resume_medium_changed disk setting
scsi: sd: Documentation: describe ignore_resume_medium_changed

Documentation/scsi/sd-parameters.rst | 14 ++++++++
drivers/scsi/scsi_error.c | 36 +++++++++++++++++---
drivers/scsi/sd.c | 50 +++++++++++++++++++++++++++-
drivers/scsi/sd.h | 1 +
include/scsi/scsi_device.h | 1 +
5 files changed, 96 insertions(+), 6 deletions(-)

--
2.20.1


2021-03-27 10:50:29

by Martin Kepplinger

[permalink] [raw]
Subject: Re: [PATCH v2 0/3] scsi: add runtime PM workaround for SD cardreaders

Am Dienstag, dem 12.01.2021 um 10:33 +0100 schrieb Martin Kepplinger:
> revision history
> ----------------
> v2:
>  * move module parameter to sd
>  * add Documentation
>
> v1:
> https://lore.kernel.org/linux-scsi/[email protected]/T/#t
>
>
>
> hi,
>
> In short: there are SD cardreaders that send MEDIA_CHANGED on
> runtime resume. We cannot use runtime PM with these devices as
> I/O basically always fails. I'd like to discuss a way to fix this
> or at least allow users to work around this problem:
>
> For the full background, the discussion started in June 2020 here:
> https://lore.kernel.org/linux-scsi/[email protected]/
>
> and I sent the first of these patches in August, as a reference:
> https://lore.kernel.org/linux-scsi/[email protected]/
> so this is where I'm following up on.
>
> I'm not sure whether maintaining an in-kernel quirk for specific
> devices
> makes sense so here I suggest adding a userspace knob. This way
> there's at
> least a chance to use runtime PM for sd cardreaders that send
> MEDIA_CHANGED.
>
> I'd appreciate any feedback.
>
> Martin Kepplinger (3):
>   scsi: add expecting_media_change flag to error path
>   scsi: sd: add ignore_resume_medium_changed disk setting
>   scsi: sd: Documentation: describe ignore_resume_medium_changed
>
>  Documentation/scsi/sd-parameters.rst | 14 ++++++++
>  drivers/scsi/scsi_error.c            | 36 +++++++++++++++++---
>  drivers/scsi/sd.c                    | 50
> +++++++++++++++++++++++++++-
>  drivers/scsi/sd.h                    |  1 +
>  include/scsi/scsi_device.h           |  1 +
>  5 files changed, 96 insertions(+), 6 deletions(-)
>

hi James, Bart and all,

since this is absolutely needed for runtime pm with the SD device we
use I assume there are others that would benefit from this too. Do you
have any concerns or thoughts about this (logic and interface)?

the patches still apply.

thanks a lot,

martin


2021-03-27 16:03:06

by Bart Van Assche

[permalink] [raw]
Subject: Re: [PATCH v2 0/3] scsi: add runtime PM workaround for SD cardreaders

On 3/27/21 3:48 AM, Martin Kepplinger wrote:
> since this is absolutely needed for runtime pm with the SD device we
> use I assume there are others that would benefit from this too. Do you
> have any concerns or thoughts about this (logic and interface)?

Hi Martin,

Since the issue addressed by this patch series concerns a controller
bug, please use the SCSI core BLIST mechanism instead of introducing a
new sysfs attribute. A sysfs attribute could be misconfigured. BLIST
attributes however are set from inside the kernel and hence do not need
help from userspace. See e.g. c360652006bb ("scsi: devinfo:
BLIST_RETRY_ASC_C1 for Fujitsu ETERNUS").

Thanks,

Bart.