| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/92114604fd1274073915e515cae15003ff07aa4a.1701619134.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/8242c07f617fc946aab857c9357f540598fe964e.1701619134.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/1d16e93a498831abd64df8b8cf54fd8872cdd1cd.1701619134.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/89ce161dad52d99df07135531512ccecb7f25d14.1701619134.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/9013c84059b8ccd6a5c8305aa35cfdfa314ba74c.1701619134.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/f71efbe17973c97fd2a1e78f8d7fcf456644510b.1701619134.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/63294479a4e745210c078859afa88904fa0b3be8.1701619134.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/27a2b133b1b88a9baf51353c511e93a5027f9602.1701619134.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/c15ffc57efebc5da3f7e6dd558d69181e129cafe.1701619134.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/811d180950b76c2d95cd080e3c251757ca011380.1701619134.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Two driver updates from Chandrakanth patil at Broadcom:
scsi: mpi3mr: Update driver version to 8.5.1.0.0
scsi: mpi3mr: Support for preallocation of SGL BSG data buffers part-3
scsi: mpi3mr: Support for preallocation of SGL BSG data buffers part-2
scsi: mpi3mr: Support for preallocation of SGL BSG data buffers part-1
scsi: mpi3mr: Fetch correct device dev handle for status reply descriptor
scsi: mpi3mr: Block PEL Enable Command on Controller Reset and Unrecoverable State
scsi: mpi3mr: Clean up block devices post controller reset
scsi: mpi3mr: Refresh sdev queue depth after controller reset
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Update driver version to 8.5.1.0.0
Signed-off-by: Chandrakanth patil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver acquires the required NVMe SGLs from the pre-allocated
pool.
Co-developed-by: Sathya Prakash <[email protected]>
Signed-off-by: Sathya Prakash <[email protected]>
Signed-off-by: Chandrakanth patil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver acquires the required SGLs from the pre-allocated pool.
Co-developed-by: Sathya Prakash <[email protected]>
Signed-off-by: Sathya Prakash <[email protected]>
Signed-off-by: Chandrakanth patil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver now supports SGLs for BSG data transfer. Upon loading, the
driver pre-allocates SGLs in chunks of 8k, results in a total of 256 * 8k,
equal to 2MB. These pre-allocated SGLs are reserved for handling BSG
commands and are deallocated during driver unload.
Co-developed-by: Sathya Prakash <[email protected]>
Signed-off-by: Sathya Prakash <[email protected]>
Signed-off-by: Chandrakanth patil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The current dev handle for the status reply is 0xFFFF, which is invalid.
So fetch the correct value.
Co-developed-by: Sumit Saxena <[email protected]>
Signed-off-by: Sumit Saxena <[email protected]>
Signed-off-by: Chandrakanth patil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
State
If a controller reset is underway or the controller is in an unrecoverable
state, the PEL enable management command will be returned as EAGAIN or
EFAULT.
Cc: <[email protected]> # v6.1+
Co-developed-by: Sathya Prakash <[email protected]>
Signed-off-by: Sathya Prakash <[email protected]>
Signed-off-by: Chandrakanth patil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
After a controller reset, if the firmware changes the state of devices to
"hide", then remove those devices from the OS.
Cc: <[email protected]> # v6.6+
Co-developed-by: Sathya Prakash <[email protected]>
Signed-off-by: Sathya Prakash <[email protected]>
Signed-off-by: Chandrakanth patil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
After a controller reset, the firmware may modify the device queue depth.
Therefore, update the device queue depth accordingly.
Cc: <[email protected]> # v5.15+
Co-developed-by: Sathya Prakash <[email protected]>
Signed-off-by: Sathya Prakash <[email protected]>
Signed-off-by: Chandrakanth patil <[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,
when testing command timeout with the help of XDP I found that
scsi_try_to_abort_cmd() would always return 'SUCCESS' for FCoE, even
if no commands could be sent over the wire. Which is not only
surprising, but also can lead to data corruption as commands were
never aborted. Root cause was that aborts had been sent twice, once
from FC error recovery and once from SCSI EH, with the former inducing
the latter to assume that the command was already aborted.
As usual, comments and reviews are welcome.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When an exchange is completed with FC_TIMED_OUT we should map it to
DID_TIME_OUT to inform the SCSI midlayer that this was a command timeout;
DID_BUS_BUSY implies that the command was never sent which is not the case
here.
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]>
|
|
We should set the status to FC_TIMED_OUT when a timeout error is passed to
fc_fcp_rec_error().
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 FC error recovery is sending up to three REC (recovery) frames
in 10 second intervals, and as a final step sending an ABTS after 30
seconds for the command itself. Unfortunately sending an ABTS is also the
action for the SCSI abort handler, and the default timeout for SCSI
commands is also 30 seconds. This causes two ABTS to be scheduled, with the
libfc one slightly earlier. The ABTS scheduled by SCSI EH then sees the
command to be already aborted, and will always return with a 'GOOD' status
irrespective on the actual result from the first ABTS. This causes the
SCSI EH abort handler to always succeed, and SCSI EH never to be engaged.
Fix this by not issuing an ABTS when a SCSI command is present for the
exchange, but rather wait for the abort scheduled from SCSI EH. And warn
if an abort is already scheduled to avoid similar errors in the future.
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]>
|
|
aic7770_config() returns both negative and positive error codes. It's
better to make aic7770_probe() only return negative error codes.
A previous commit made ahc_linux_register_host() return negative error
codes, which makes sure aic7770_probe() returns negative error codes.
Signed-off-by: Su Hui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Dan Carpenter <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
ahc_linux_register_host() can return an error code in case of failure. So
ahc_linux_pci_dev_probe() should return the value of
ahc_linux_register_host() rather than zero.
An earlier commit made ahc_linux_register_host() return negative error
codes, which makes sure ahc_linux_pci_dev_probe() returns negative error
codes.
Signed-off-by: Su Hui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Dan Carpenter <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
ahc_linux_register_host() returns both positive and negative error codes.
It's better to make this function only return negative error codes.
Signed-off-by: Su Hui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Dan Carpenter <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
sci_task_request_construct_ssp() has invariant return. Change this function
to void and get rid of unnecessary checks.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Artem Chernyshev <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The IPR driver has a routine to check whether it's running on certain CPU
versions and if so whether the adapter is supported on that CPU.
But none of the CPUs it checks for are supported by Linux anymore.
The most recent CPU it checks for is Power4+ which was removed in commit
471d7ff8b51b ("powerpc/64s: Remove POWER4 support").
So drop the check. That makes the "testmode" module parameter unused, so
remove it as well.
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
strncpy() is deprecated for use on NUL-terminated destination strings [1]
and as such we should prefer more robust and less ambiguous string
interfaces.
We expect partition_name to be NUL-terminated based on its usage with
format strings:
| dev_info(hostdata->dev, "host srp version: %s, "
| "host partition %s (%d), OS %d, max io %u\n",
| hostdata->madapter_info.srp_version,
| hostdata->madapter_info.partition_name,
| be32_to_cpu(hostdata->madapter_info.partition_number),
| be32_to_cpu(hostdata->madapter_info.os_type),
| be32_to_cpu(hostdata->madapter_info.port_max_txu[0]));
...
| len = snprintf(buf, PAGE_SIZE, "%s\n",
| hostdata->madapter_info.partition_name);
Moreover, NUL-padding is not required as madapter_info is explicitly
memset to 0:
| memset(&hostdata->madapter_info, 0x00,
| sizeof(hostdata->madapter_info));
Considering the above, a suitable replacement is strscpy() [2] due to the
fact that it guarantees NUL-termination on the destination buffer without
unnecessarily NUL-padding.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: <[email protected]>
Signed-off-by: Justin Stitt <[email protected]>
Link: https://lore.kernel.org/r/20231030-strncpy-drivers-scsi-ibmvscsi-ibmvscsi-c-v1-1-f8b06ae9e3d5@google.com
Reviewed-by: Kees Cook <[email protected]>
Tested-by: Michael Ellerman <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
strncpy() is deprecated for use on NUL-terminated destination strings [1]
and as such we should prefer more robust and less ambiguous string
interfaces.
We expect these fields to be NUL-terminated as the property names from
which they are derived are also NUL-terminated.
Moreover, NUL-padding is not required as our destination buffers are
already NUL-allocated and any future NUL-byte assignments are redundant
(like the ones that strncpy() does).
ibmvfc_probe() ->
| struct ibmvfc_host *vhost;
| struct Scsi_Host *shost;
...
| shost = scsi_host_alloc(&driver_template, sizeof(*vhost));
... **side note: is this a bug? Looks like a type to me ^^^^^**
...
| vhost = shost_priv(shost);
... where shost_priv() is:
| static inline void *shost_priv(struct Scsi_Host *shost)
| {
| return (void *)shost->hostdata;
| }
.. and:
scsi_host_alloc() ->
| shost = kzalloc(sizeof(struct Scsi_Host) + privsize, GFP_KERNEL);
And for login_info->..., NUL-padding is also not required as it is
explicitly memset to 0:
| memset(login_info, 0, sizeof(*login_info));
Considering the above, a suitable replacement is strscpy() [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: <[email protected]>
Signed-off-by: Justin Stitt <[email protected]>
Link: https://lore.kernel.org/r/20231030-strncpy-drivers-scsi-ibmvscsi-ibmvfc-c-v1-1-5a4909688435@google.com
Reviewed-by: Kees Cook <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In fnic_init_module() exists redundant check for return value from
fnic_debugfs_init(), because at moment it only can return zero. It make
sense to process theoretical vmalloc() failure.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 9730ddfb123d ("scsi: fnic: remove redundant assignment of variable rc")
Signed-off-by: Artem Chernyshev <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Karan Tilak Kumar <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When an error occurs in the for loop of beiscsi_init_wrb_handle(), we
should free phwi_ctxt->be_wrbq before returning an error code to prevent
potential memleak.
Fixes: a7909b396ba7 ("[SCSI] be2iscsi: Fix dynamic CID allocation Mechanism in driver")
Signed-off-by: Dinghao Liu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Mike Christie <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Replace literal 0x80 with PCI_HEADER_TYPE_MFD.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
|
|
Driver update from ching Huang <[email protected]>.
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Signed-off-by: ching Huang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add support for Areca RAID controllers with PCI device IDs 1883 and 1886.
Signed-off-by: ching Huang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add support for new Areca RAID controller ARC-1688
Signed-off-by: ching Huang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Sparse static analysis tool generates a warning with this message "Using
plain integer as NULL pointer". Fix it.
Signed-off-by: Abhinav Singh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
controllers"
Sumit Saxena <[email protected]> says:
These patches add support for Broadcom's SAS5116 IO/RAID controllers
in mpi3mr driver.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Update driver version to 8.5.0.0.50.
Signed-off-by: Sumit Saxena <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Inform controller firmware that driver supports status reply descriptor.
Signed-off-by: Sumit Saxena <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
SAS5116 controllers supports maximum 48 physical PHYs. Modify driver to
accommodate up to 64 PHYs (though current need is to support 48 PHYs).
Signed-off-by: Sumit Saxena <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add PCI IDs checks for the cases where SAS5116 diverges from SAS4116 in
behavior.
Signed-off-by: Sumit Saxena <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add support for Broadcom's SAS5116 IO/RAID controllers PCI IDs.
Signed-off-by: Sumit Saxena <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
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: <[email protected]>
Signed-off-by: Damien Le Moal <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Calling scsi_eh_scmd_add() may cause the error handler never to be woken up
because this may result in shost->host_failed to become larger than
scsi_host_busy(shost). Hence complain if scsi_eh_scmd_add() is called after
SCMD_STATE_INFLIGHT has been cleared.
Cc: Hannes Reinecke <[email protected]>
Cc: Damien Le Moal <[email protected]>
Cc: Mike Christie <[email protected]>
Cc: John Garry <[email protected]>
Cc: Ming Lei <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the following sparse warning:
drivers/scsi/bfa/bfad_bsg.c:2553:50: sparse: sparse: incorrect type in initializer (different base types)
Fixes: 2e5a6c3baccd ("scsi: bfa: Convert bfad_reset_sdev_bflags() from a macro into a function")
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Bart Van Assche <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The mpt3sas_ctl_exit() should be called after communication with the
controller stops but currently it may cause false warnings about not
released memory. Fix this by letting mpt3sas_ctl_exit() handle misc driver
release per driver and release DMA in mpt3sas_ctl_release() per ioc.
Signed-off-by: Tomas Henzl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Justin Tee <[email protected]> says:
Update lpfc to revision 14.2.0.16
This patch set contains a user input range check correction, static
code analyzer fixes, refactoring of clean up code, and logging
enhancements.
The patches were cut against Martin's 6.7/scsi-queue tree.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
A series of patches from Justin Stitt.
Signed-off-by: Martin K. Petersen <[email protected]>
|