| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: John Garry <[email protected]>
Reviewed-by: Martin Wilck <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: John Garry <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Reviewed-by: Martin Wilck <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: John Garry <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Reviewed-by: Martin Wilck <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Mike Christie <[email protected]> says:
The following patches were made over Linus's tree but apply over
Martin's branches. They allow userspace to configure how fabric
drivers submit cmds to backend drivers.
Right now loop and vhost use a worker thread, and the other drivers
submit from the contexts they receive/process the cmd from. For
multiple LUN cases where the target can queue more cmds than the
backend can handle then deferring to a worker thread is safest because
the backend driver can block when doing things like waiting for a free
request/tag. Deferring also helps when the target has to handle
transport level requests from the recv context.
For cases where the backend devices can queue everything the target
sends, then there is no need to defer to a workqueue and you can see a
perf boost of up to 26% for small IO workloads. For a nvme device and
vhost-scsi I can see with 4K IOs:
fio jobs 1 2 4 8 10
--------------------------------------------------
workqueue
submit 94K 190K 394K 770K 890K
direct
submit 128K 252K 488K 950K -
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In some cases, like with multiple LUN targets or where the target has to
respond to transport level requests from the receiving context it can be
better to defer cmd submission to a helper thread. If the backend driver
blocks on something like request/tag allocation it can block the entire
target submission path and other LUs and transport IO on that session.
In other cases like single LUN targets with storage that can support all
the commands that the target can queue, then it's best to submit the cmd
to the backend from the target's cmd receiving context.
Subsequent commits will allow the user to config what they prefer, but
drivers like loop can't directly submit because they can be called from a
context that can't sleep. And, drivers like vhost-scsi can support direct
submission, but need to keep their default behavior of deferring execution
to avoid possible regressions where the backend can block.
Make the drivers tell LIO core if they support direct submissions and their
current default, so we can prevent users from misconfiguring the system and
initialize devices correctly.
Signed-off-by: Mike Christie <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Hannes Reinecke <[email protected]> says:
Hi all,
(taking up an old thread:) here's the first batch of patches for my EH
rework. It modifies the reset callbacks for SCSI drivers such that
the final conversion to drop the 'struct scsi_cmnd' argument and use
the entity in question (host, bus, target, device) as the argument to
the SCSI EH callbacks becomes possible. The first part covers drivers
which just requires minor tweaks.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
SCSI EH host reset is the final callback in the escalation chain; once we
reach this we need to reset the controller. As such it defeats the purpose
to skip controller reset if no I/Os are pending and the RAID device is to
be reset; especially after kexec there might be stale commands pending in
firmware for which we have no reference whatsoever. So this patch splits
off the check for pending I/O into a 'bus_reset' function, and leaves the
actual controller reset to the host reset.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Kashyap Desai <[email protected]>
Cc: Sathya Prakash Veerichetty <[email protected]>
Cc: Sumit Saxena <[email protected]>
Cc: Sreekanth Reddy <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The reset code requires a device to be selected, but we shouldn't rely on
the command to provide a device for us. So select the first device on the
target when sending down a target reset.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The reset code requires a device to be selected, but we shouldn't rely on
the command to provide a device for us. So select the first device on the
bus when sending down a bus reset.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
There's not much in common between host reset and all other error handlers,
so use a separate function here.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Split off the combined abort and device reset handling into distinct
functions. And rename the current device reset handler into a target reset
handler, seeing that it really is a target reset.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The current handler does both, bus reset and host reset. So split them off
into two distinct functions.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Matthew Wilcox <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The code for aborting an outstanding command is a copy of the functionality
from command abort. As we already have called this function once we reach
host reset there's no point in trying to do so again.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Adaptec OEM Raid Solutions <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When calling a host reset we shouldn't rely on the command triggering the
reset, so allow megaraid_abort_and_reset() to be called with a NULL scb.
And drop the pointless 'bus_reset' and 'target_reset' handlers, which just
call the same function as host_reset.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
For target reset we need a device to send the target reset to, so open-code
the loop in target reset to send the target reset TMF to the correct
device.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Tyrel Datwyler <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When sending a device reset we should not take a reference to the SCSI
command.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Convert BUILD_SCSIID() into a function and add a scsi_device argument.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Johannes Thumshirn <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When sending a device reset we should not take a reference to the SCSI
command.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Convert BUILD_SCSIID() into a function and add a scsi_device argument.
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Johannes Thumshirn <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When a LUN or target reset is issued, we should not rely on a SCSI command
to be present; we'll have to reset the entire device or target anyway.
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Saurav Kashyap <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When sending a TMF we're only concerned with the rport and the LUN ID, so
use struct fc_rport as argument for qedf_initiate_tmf().
Signed-off-by: Hannes Reinecke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Saurav Kashyap <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
ibmvfc_host'
Clang warns (or errors with CONFIG_WERROR=y) several times along the
lines of:
drivers/scsi/ibmvscsi/ibmvfc.c:650:17: warning: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion]
650 | vhost->reinit = 1;
| ^ ~
A single-bit signed integer bitfield only has possible values of -1 and
0, not 0 and 1 like an unsigned one would. No context appears to check
the actual value of these bitfields, just whether or not it is zero.
However, it is easy enough to change the type of the fields to 'unsigned
int', which keeps the same size in memory and resolves the warning.
Fixes: 5144905884e2 ("scsi: ibmvfc: Use a bitfield for boolean flags")
Signed-off-by: Nathan Chancellor <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
fc_lport_ptp_setup() did not check the return value of fc_rport_create()
which can return NULL and would cause a NULL pointer dereference. Address
this issue by checking return value of fc_rport_create() and log error
message on fc_rport_create() failed.
Signed-off-by: Wenchao Hao <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix 'generated' typo.
Signed-off-by: Muhammad Muzammil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https://lore.kernel.org/all/ZO5Yx5JFogGi%[email protected]/)
Remove sentinel from scsi_table and sg_sysctls.
Signed-off-by: Joel Granados <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
|
|
Instead of "if" conditions with line splits, use the usual error handling
pattern with a separate variable to improve readability.
No functional changes intended.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: "Martin K. Petersen" <[email protected]>
|
|
Use the provided topology helper.
Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Juergen Gross <[email protected]>
Tested-by: Sohil Mehta <[email protected]>
Tested-by: Michael Kelley <[email protected]>
Tested-by: Peter Zijlstra (Intel) <[email protected]>
Tested-by: Zhang Rui <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Rename it to pkg_id which is the terminology used in the kernel.
No functional change.
Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Juergen Gross <[email protected]>
Tested-by: Sohil Mehta <[email protected]>
Tested-by: Michael Kelley <[email protected]>
Tested-by: Peter Zijlstra (Intel) <[email protected]>
Tested-by: Zhang Rui <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Commit ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices")
modified scsi_rescan_device() to avoid attempting rescanning a suspended
device. However, the modification added a check to verify that a SCSI
device is in the running state without checking if the device request
queue (in the case of block device) is also running, thus allowing the
exectuion of internal requests. Without checking the device request
queue, commit ff48b37802e5 fix is incomplete and deadlocks on resume can
still happen. Use blk_queue_pm_only() to check if the device request
queue allows executing commands in addition to checking the SCSI device
state.
Reported-by: Petr Tesarik <[email protected]>
Fixes: ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices")
Cc: [email protected]
Tested-by: Petr Tesarik <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Signed-off-by: Damien Le Moal <[email protected]>
|
|
Tyrel Datwyler <[email protected]> says:
This series includes a couple minor fixes, generalization of some code
that is not protocol specific, and a reworking of the way event pool
buffers are accounted for by the driver. This is a precursor to a
series to follow that introduces support for NVMeoF protocol with
ibmvfc.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Use DEFINE_SHOW_STORE_ATTRIBUTE() helper for read-write file to reduce some
duplicated code.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Luo Jiaxing <[email protected]>
Co-developed-by: Xingui Yang <[email protected]>
Signed-off-by: Xingui Yang <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Animesh Manna <[email protected]>
Cc: Anshuman Gupta <[email protected]>
Cc: Damien Le Moal <[email protected]>
Cc: Felipe Balbi <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Himanshu Madhani <[email protected]>
Cc: James Bottomley <[email protected]>
Cc: John Garry <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Cc: Uma Shankar <[email protected]>
Cc: Xiang Chen <[email protected]>
Cc: Zeng Tao <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
Use DEFINE_SHOW_STORE_ATTRIBUTE() helper for read-write file to reduce some
duplicated code.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Luo Jiaxing <[email protected]>
Co-developed-by: Xingui Yang <[email protected]>
Signed-off-by: Xingui Yang <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Animesh Manna <[email protected]>
Cc: Anshuman Gupta <[email protected]>
Cc: Damien Le Moal <[email protected]>
Cc: Felipe Balbi <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Himanshu Madhani <[email protected]>
Cc: James Bottomley <[email protected]>
Cc: John Garry <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Cc: Uma Shankar <[email protected]>
Cc: Xiang Chen <[email protected]>
Cc: Zeng Tao <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Three fixes, all in drivers.
The fnic one is the most extensive because the little used user
initiated device reset path never tagged the command and adding a tag
is rather involved. The other two fixes are smaller and more obvious"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: zfcp: Fix a double put in zfcp_port_enqueue()
scsi: fnic: Fix sg_reset success path
scsi: target: core: Fix deadlock due to recursive locking
|
|
The scsi device flag no_start_on_resume is not set by any scsi low
level driver. Remove it. This reverts the changes introduced by commit
0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume").
Signed-off-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Tested-by: Chia-Lin Kao (AceLan) <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
Pull ATA fixes from Damien Le Moal:
"A larger than usual set of fixes for 6.6-rc4 due to the unexpected
number of fixes needed to address ATA disks suspend/resume issues.
In more detail:
- Add missing additionalProperties on child nodes to the pata-common
DT bindings (Rob)
- Fix handling of the REPORT SUPPORTED OPERATION CODES command to
ignore reserved bits (Niklas)
- Increase port multiplier soft reset timeout to accomodate slow
devices and avoid issues on wakeup (Matthias)
- A couple of minor code fixes to avoid compilation warnings in
libata-core and libata-eh (me)
- Many patches from me to address suspend/resume issues, and in
particular a potential deadlock on resume due to the SCSI disk
driver resume operation not being synchronized with libata EH port
resume handling.
This is addressed by changing the scsi disk driver disk start/stop
control to allow libata to execute disk suspend (spin down) and
resume (spin up) on its own during system suspend/resume. Runtime
suspend/resume control remains with the SCSI disk driver.
Other fixes include:
- Fix libata power management request issuing to avoid races
- Establish a link between ATA ports and SCSI devices to order PM
operations
- Fix device removal to avoid issues with driver rmmod removal
- Fix synchronization of libata device rescan and SCSI disk resume
operation
- Remove libsas PM operations as suspend/resume is handled
directly by the sas controller resume
- Fix the SCSI disk driver to not issue commands to suspended
disks, thus avoiding potential system lock-up on resume"
* tag 'ata-6.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata:
ata: libata-eh: Fix compilation warning in ata_eh_link_report()
ata: libata-core: Fix compilation warning in ata_dev_config_ncq()
scsi: sd: Do not issue commands to suspended disks on shutdown
ata: libata-core: Do not register PM operations for SAS ports
ata: libata-scsi: Fix delayed scsi_rescan_device() execution
scsi: Do not attempt to rescan suspended devices
ata: libata-scsi: Disable scsi device manage_system_start_stop
scsi: sd: Differentiate system and runtime start/stop management
ata: libata-scsi: link ata port and scsi device
ata: libata-core: Fix port and device removal
ata: libata-core: Fix ata_port_request_pm() locking
ata: libata-sata: increase PMP SRST timeout to 10s
ata: libata-scsi: ignore reserved bits for REPORT SUPPORTED OPERATION CODES
dt-bindings: ata: pata-common: Add missing additionalProperties on child nodes
|
|
If an error occurs when resuming a host adapter before the devices
attached to the adapter are resumed, the adapter low level driver may
remove the scsi host, resulting in a call to sd_remove() for the
disks of the host. This in turn results in a call to sd_shutdown() which
will issue a synchronize cache command and a start stop unit command to
spindown the disk. sd_shutdown() issues the commands only if the device
is not already runtime suspended but does not check the power state for
system-wide suspend/resume. That is, the commands may be issued with the
device in a suspended state, which causes PM resume to hang, forcing a
reset of the machine to recover.
Fix this by tracking the suspended state of a disk by introducing the
suspended boolean field in the scsi_disk structure. This flag is set to
true when the disk is suspended is sd_suspend_common() and resumed with
sd_resume(). When suspended is true, sd_shutdown() is not executed from
sd_remove().
Cc: [email protected]
Signed-off-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
|
|
scsi_rescan_device() takes a scsi device lock before executing a device
handler and device driver rescan methods. Waiting for the completion of
any command issued to the device by these methods will thus be done with
the device lock held. As a result, there is a risk of deadlocking within
the power management code if scsi_rescan_device() is called to handle a
device resume with the associated scsi device not yet resumed.
Avoid such situation by checking that the target scsi device is in the
running state, that is, fully capable of executing commands, before
proceeding with the rescan and bailout returning -EWOULDBLOCK otherwise.
With this error return, the caller can retry rescaning the device after
a delay.
The state check is done with the device lock held and is thus safe
against incoming suspend power management operations.
Fixes: 6aa0365a3c85 ("ata: libata-scsi: Avoid deadlock on rescan after device resume")
Cc: [email protected]
Signed-off-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Niklas Cassel <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
|
|
The underlying device and driver of a SCSI disk may have different
system and runtime power mode control requirements. This is because
runtime power management affects only the SCSI disk, while system level
power management affects all devices, including the controller for the
SCSI disk.
For instance, issuing a START STOP UNIT command when a SCSI disk is
runtime suspended and resumed is fine: the command is translated to a
STANDBY IMMEDIATE command to spin down the ATA disk and to a VERIFY
command to wake it up. The SCSI disk runtime operations have no effect
on the ata port device used to connect the ATA disk. However, for
system suspend/resume operations, the ATA port used to connect the
device will also be suspended and resumed, with the resume operation
requiring re-validating the device link and the device itself. In this
case, issuing a VERIFY command to spinup the disk must be done before
starting to revalidate the device, when the ata port is being resumed.
In such case, we must not allow the SCSI disk driver to issue START STOP
UNIT commands.
Allow a low level driver to refine the SCSI disk start/stop management
by differentiating system and runtime cases with two new SCSI device
flags: manage_system_start_stop and manage_runtime_start_stop. These new
flags replace the current manage_start_stop flag. Drivers setting the
manage_start_stop are modifed to set both new flags, thus preserving the
existing start/stop management behavior. For backward compatibility, the
old manage_start_stop sysfs device attribute is kept as a read-only
attribute showing a value of 1 for devices enabling both new flags and 0
otherwise.
Fixes: 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume")
Cc: [email protected]
Signed-off-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
|
|
No functional modification involved.
drivers/scsi/fnic/fnic_fcs.c:152 fnic_handle_link() warn: inconsistent indenting.
Reported-by: Abaci Robot <[email protected]>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6678
Signed-off-by: Jiapeng Chong <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"A single fix for libata: older devices don't support command duration
limits (CDL) and some don't support report opcodes, meaning there's no
way to tell if they support the command or not.
Reduce the problems of incorrectly using CDL commands on older devices
by checking SCSI spec compliance at SPC-5 (the spec which introduced
the command) before turning on CDL"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: core: ata: Do no try to probe for CDL on old drives
|
|
sg_reset performs a target or LUN reset. Since the command is issued by the
user, it does not come into the driver with a tag or a queue id. Fix the
fnic driver to create an io_req and use a SCSI command tag. Fix the ITMF
path to special case the sg_reset response.
Reviewed-by: Sesidhar Baddela <[email protected]>
Reviewed-by: Arulprabhu Ponnusamy <[email protected]>
Tested-by: Karan Tilak Kumar <[email protected]>
Signed-off-by: Karan Tilak Kumar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add a per target protocol field so target code can determine correct
protocol specific actions as well as identify the correct channel group
target list.
Signed-off-by: Tyrel Datwyler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The target discovery buffer that the VIOS populates with targets is
currently a host adapter field. To facilitate the discovery of NVMe targets
as well as SCSI another discovery buffer is required. Move the discovery
buffer out of the host struct and into the ibmvfc_channels struct so that
each channels instance for a given protocol has its own discovery buffer.
Signed-off-by: Tyrel Datwyler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
There are cases in the generic code where protocol specific configuration
or actions may need to be taken. Add a protocol field to struct
ibmvfc_channels and initial IBMVFC_PROTO_[SCSI/NVME] definitions.
Signed-off-by: Tyrel Datwyler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
With the coming of NVMeoF support the driver will need to also allocate
channels for NVMe. Implement generic channel allocation wrappers that can
be used for both SCSI and NVMeoF protocol setup.
Signed-off-by: Tyrel Datwyler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add fields for desired and max number of queues to ibmvfc_channels. With
support for NVMeoF protocol coming these sorts of values should be tracked
in the protocol specific channel struct instead of the overarching host
adapter.
Signed-off-by: Tyrel Datwyler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
There is nothing scsi specific about the ibmvfc_scsi_channels struct. It is
meant to encapsulate a set of channels regardless of protocol.
Remove _scsi from the struct name to reflect this genric nature.
Signed-off-by: Tyrel Datwyler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
There are currently 9 binary flag fields in the ibmvfc host
structure. Converting each of these to a single bitfield reduces the foot
print of the structure by 32 bytes.
Signed-off-by: Tyrel Datwyler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Commit 0217a272fe13 ("scsi: ibmvfc: Store return code of H_FREE_SUB_CRQ
during cleanup") wrongly changed the busy loop check to use
rtas_busy_delay() instead of H_BUSY and H_IS_LONG_BUSY(). The busy return
codes for RTAS and hypercalls are not the same.
Fix this issue by restoring the use of H_BUSY and H_IS_LONG_BUSY().
Fixes: 0217a272fe13 ("scsi: ibmvfc: Store return code of H_FREE_SUB_CRQ during cleanup")
Signed-off-by: Tyrel Datwyler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
An LPAR could potentially be configured with a small logical cpu count that
is less then the default hardware queue max. Ensure that we don't allocate
more hw queues than available cpus.
Signed-off-by: Tyrel Datwyler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|