linux.git/drivers/scsi/sd.c, branch v6.7

scsi: sd: Fix system start for ATA devices

2023-11-25T01:44:21+00:00

It is not always possible to keep a device in the runtime suspended state
when a system level suspend/resume cycle is executed. E.g. for ATA devices
connected to AHCI adapters, system resume resets the ATA ports, which
causes connected devices to spin up. In such case, a runtime suspended disk
will incorrectly be seen with a suspended runtime state because the device
is not resumed by sd_resume_system(). The power state seen by the user is
different than the actual device physical power state.

Fix this issue by introducing the struct scsi_device flag
force_runtime_start_on_system_start. When set, this flag causes
sd_resume_system() to request a runtime resume operation for runtime
suspended devices. This results in the user seeing the device runtime_state
as active after a system resume, thus correctly reflecting the device
physical power state.

Fixes: 9131bff6a9f1 ("scsi: core: pm: Only runtime resume if necessary")
Cc: 
Signed-off-by: Damien Le Moal 
Link: https://lore.kernel.org/r/20231120225631.37938-3-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen

Merge branch '6.7/scsi-staging' into 6.7/scsi-fixes

2023-11-14T16:40:40+00:00

Pull in queued fixes for 6.7

Signed-off-by: Martin K. Petersen

scsi: sd: Fix sshdr use in sd_suspend_common()

2023-11-09T02:46:58+00:00

If scsi_execute_cmd() returns < 0, it doesn't initialize the sshdr, so we
shouldn't access the sshdr. If it returns 0, then the cmd executed
successfully, so there is no need to check the sshdr. sd_sync_cache() will
only access the sshdr if it's been setup because it calls
scsi_status_is_check_condition() before accessing it. However, the
sd_sync_cache() caller, sd_suspend_common(), does not check.

sd_suspend_common() is only checking for ILLEGAL_REQUEST which it's using
to determine if the command is supported. If it's not it just ignores the
error. So to fix its sshdr use this patch just moves that check to
sd_sync_cache() where it converts ILLEGAL_REQUEST to success/0.
sd_suspend_common() was ignoring that error and sd_shutdown() doesn't check
for errors so there will be no behavior changes.

Signed-off-by: Mike Christie 
Link: https://lore.kernel.org/r/20231106231304.5694-2-michael.christie@oracle.com
Reviewed-by: Christoph Hellwig 
Reviewed-by: Martin Wilck 
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen

Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2023-11-03T01:13:50+00:00

Pull SCSI updates from James Bottomley:
 "Updates to the usual drivers (ufs, megaraid_sas, lpfc, target, ibmvfc,
  scsi_debug) plus the usual assorted minor fixes and updates.

  The major change this time around is a prep patch for rethreading of
  the driver reset handler API not to take a scsi_cmd structure which
  starts to reduce various drivers' dependence on scsi_cmd in error
  handling"

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (132 commits)
  scsi: ufs: core: Leave space for '\0' in utf8 desc string
  scsi: ufs: core: Conversion to bool not necessary
  scsi: ufs: core: Fix race between force complete and ISR
  scsi: megaraid: Fix up debug message in megaraid_abort_and_reset()
  scsi: aic79xx: Fix up NULL command in ahd_done()
  scsi: message: fusion: Initialize return value in mptfc_bus_reset()
  scsi: mpt3sas: Fix loop logic
  scsi: snic: Remove useless code in snic_dr_clean_pending_req()
  scsi: core: Add comment to target_destroy in scsi_host_template
  scsi: core: Clean up scsi_dev_queue_ready()
  scsi: pmcraid: Add missing scsi_device_put() in pmcraid_eh_target_reset_handler()
  scsi: target: core: Fix kernel-doc comment
  scsi: pmcraid: Fix kernel-doc comment
  scsi: core: Handle depopulation and restoration in progress
  scsi: ufs: core: Add support for parsing OPP
  scsi: ufs: core: Add OPP support for scaling clocks and regulators
  scsi: ufs: dt-bindings: common: Add OPP table
  scsi: scsi_debug: Add param to control sdev's allow_restart
  scsi: scsi_debug: Add debugfs interface to fail target reset
  scsi: scsi_debug: Add new error injection type: Reset LUN failed
  ...

Merge tag 'ata-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata

2023-11-01T22:50:12+00:00

Pull ATA updates from Damien Le Moal:

 - Modify the AHCI driver to print the link power management policy used
   on scan, to help with debugging issues (Niklas)

 - Add support for the ASM2116 series adapters to the AHCI driver
   (Szuying)

 - Prepare libata for the coming gcc and Clang __counted_by attribute
   (Kees)

 - Following the recent estensive fixing of libata suspend/resume
   handling, several patches further cleanup and improve disk power
   state management (me)

 - Reduce the verbosity of some error messages for non-fatal temporary
   errors, e.g. slow response to device reset when scanning a port, and
   warning messages that are in fact normal, e.g. disabling a device on
   suspend or when removing it (me)

 - Cleanup DMA helper functions (me)

 - Fix sata_mv drive handling of potential errors durring probe (Ma)

 - Cleanup the xgene and imx drivers using the functions
   of_device_get_match_data() and device_get_match_data() (Rob)

 - Improve the tegra driver device tree (Rob)

* tag 'ata-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata: (22 commits)
  dt-bindings: ata: tegra: Disallow undefined properties
  ata: libata-core: Improve ata_dev_power_set_active()
  ata: libata-eh: Spinup disk on resume after revalidation
  ata: imx: Use device_get_match_data()
  ata: xgene: Use of_device_get_match_data()
  ata: sata_mv: aspeed: fix value check in mv_platform_probe()
  ata: ahci: Add Intel Alder Lake-P AHCI controller to low power chipsets list
  ata: libata: Cleanup inline DMA helper functions
  ata: libata-eh: Reduce "disable device" message verbosity
  ata: libata-eh: Improve reset error messages
  ata: libata-sata: Improve ata_sas_slave_configure()
  ata: libata-core: Do not resume runtime suspended ports
  ata: libata-core: Do not poweroff runtime suspended ports
  ata: libata-core: Remove ata_port_resume_async()
  ata: libata-core: Remove ata_port_suspend_async()
  ata: libata-core: Detach a port devices on shutdown
  ata: libata-core: Synchronize ata_port_detach() with hotplug
  ata: libata-scsi: Cleanup ata_scsi_start_stop_xlat()
  scsi: Remove scsi device no_start_on_resume flag
  ata: libata: Annotate struct ata_cpr_log with __counted_by
  ...

scsi: sd: Introduce manage_shutdown device flag

2023-10-27T01:00:19+00:00

Commit aa3998dbeb3a ("ata: libata-scsi: Disable scsi device
manage_system_start_stop") change setting the manage_system_start_stop
flag to false for libata managed disks to enable libata internal
management of disk suspend/resume. However, a side effect of this change
is that on system shutdown, disks are no longer being stopped (set to
standby mode with the heads unloaded). While this is not a critical
issue, this unclean shutdown is not recommended and shows up with
increased smart counters (e.g. the unexpected power loss counter
"Unexpect_Power_Loss_Ct").

Instead of defining a shutdown driver method for all ATA adapter
drivers (not all of them define that operation), this patch resolves
this issue by further refining the sd driver start/stop control of disks
using the new flag manage_shutdown. If this new flag is set to true by
a low level driver, the function sd_shutdown() will issue a
START STOP UNIT command with the start argument set to 0 when a disk
needs to be powered off (suspended) on system power off, that is, when
system_state is equal to SYSTEM_POWER_OFF.

Similarly to the other manage_xxx flags, the new manage_shutdown flag is
exposed through sysfs as a read-write device attribute.

To avoid any confusion between manage_shutdown and
manage_system_start_stop, the comments describing these flags in
include/scsi/scsi.h are also improved.

Fixes: aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop")
Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218038
Link: https://lore.kernel.org/all/cd397c88-bf53-4768-9ab8-9d107df9e613@gmail.com/
Signed-off-by: Damien Le Moal 
Reviewed-by: Niklas Cassel 
Reviewed-by: Hannes Reinecke 
Reviewed-by: James Bottomley 
Acked-by: Martin K. Petersen

scsi: core: Handle depopulation and restoration in progress

2023-10-17T01:02:23+00:00

The default handling of the NOT READY sense key is to wait for the device
to become ready. The "wait" is assumed to be relatively short. However
there is a sub-class of NOT READY that have the "... in progress" phrase in
their additional sense code and these can take much longer.  Following on
from commit 505aa4b6a883 ("scsi: sd: Defer spinning up drive while SANITIZE
is in progress") we now have element depopulation and restoration that can
take a long time.  For example, over 24 hours for a 20 TB, 7200 rpm hard
disk to depopulate 1 of its 20 elements.

Add handling of ASC/ASCQ: 0x4,0x24 (depopulation in progress)
and ASC/ASCQ: 0x4,0x25 (depopulation restoration in progress)
to sd.c . The scsi_lib.c has incomplete handling of these
two messages, so complete it.

Signed-off-by: Douglas Gilbert 
Link: https://lore.kernel.org/r/20231015050650.131145-1-dgilbert@interlog.com
Signed-off-by: Martin K. Petersen

scsi: sd: Fix sshdr use in cache_type_store

2023-10-13T20:36:20+00:00

If scsi_execute_cmd returns < 0, it doesn't initialize the sshdr, so we
shouldn't access the sshdr. If it returns 0, then the cmd executed
successfully, so there is no need to check the sshdr. This has us access
the sshdr when we get a return value > 0.

Signed-off-by: Mike Christie 
Link: https://lore.kernel.org/r/20231004210013.5601-12-michael.christie@oracle.com
Reviewed-by: Christoph Hellwig 
Reviewed-by: John Garry 
Reviewed-by: Martin Wilck 
Signed-off-by: Martin K. Petersen

scsi: sd: Fix scsi_mode_sense caller's sshdr use

2023-10-13T20:36:20+00:00

The sshdr passed into scsi_execute_cmd is only initialized if
scsi_execute_cmd returns >= 0, and scsi_mode_sense will convert all non
good statuses like check conditions to -EIO. This has scsi_mode_sense
callers that were possibly accessing an uninitialized sshdrs to only
access it if we got -EIO.

Signed-off-by: Mike Christie 
Link: https://lore.kernel.org/r/20231004210013.5601-9-michael.christie@oracle.com
Reviewed-by: Christoph Hellwig 
Reviewed-by: Martin Wilck 
Signed-off-by: Martin K. Petersen

scsi: sd: Fix sshdr use in sd_spinup_disk

2023-10-13T20:36:19+00:00

If scsi_execute_cmd returns < 0, it doesn't initialize the sshdr, so we
shouldn't access the sshdr. If it returns 0, then the cmd executed
successfully, so there is no need to check the sshdr. This has us access
the sshdr when we get a return value > 0.

Signed-off-by: Mike Christie 
Link: https://lore.kernel.org/r/20231004210013.5601-3-michael.christie@oracle.com
Reviewed-by: Christoph Hellwig 
Reviewed-by: John Garry 
Reviewed-by: Bart Van Assche 
Reviewed-by: Martin Wilck 
Signed-off-by: Martin K. Petersen