mbox series

[v2,0/3] scsi: add runtime PM workaround for SD cardreaders

Message ID 20210112093329.3639-1-martin.kepplinger@puri.sm (mailing list archive)
Headers show
Series scsi: add runtime PM workaround for SD cardreaders | expand

Message

Martin Kepplinger Jan. 12, 2021, 9:33 a.m. UTC
revision history
----------------
v2:
 * move module parameter to sd
 * add Documentation

v1:
https://lore.kernel.org/linux-scsi/20210111152029.28426-1-martin.kepplinger@puri.sm/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/20200623111018.31954-1-martin.kepplinger@puri.sm/

and I sent the first of these patches in August, as a reference:
https://lore.kernel.org/linux-scsi/20200824190400.12339-1-martin.kepplinger@puri.sm/
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(-)

Comments

Martin Kepplinger March 27, 2021, 10:48 a.m. UTC | #1
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/20210111152029.28426-1-martin.kepplinger@puri.sm/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/20200623111018.31954-1-martin.kepplinger@puri.sm/
> 
> and I sent the first of these patches in August, as a reference:
> https://lore.kernel.org/linux-scsi/20200824190400.12339-1-martin.kepplinger@puri.sm/
> 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
Bart Van Assche March 27, 2021, 4:01 p.m. UTC | #2
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.