FCP-4 (referred FCP-4 rev-2b) identifies the earlier known "retry delay
timer" field as "status qualifier", which is described in SAM-5 and later
specs. This fix makes appropriate driver side modifications to honor the
new definition. The SAM document referred was SAM-6 rev-5.
Link: https://lore.kernel.org/r/20200904045128.23631-5-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Arun Easi <aeasi@marvell.com>
Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Create a base for adding remote port related entries in debugfs.
Link: https://lore.kernel.org/r/20200904045128.23631-3-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Arun Easi <aeasi@marvell.com>
Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Driver was using a lower value for dev_loss_tmo making it more prone to I/O
failures during remote port toggle testing. Set dev_loss_tmo to zero during
remote port registration to allow nvme-fc default dev_loss_tmo to be used,
which is higher than what driver was using.
Link: https://lore.kernel.org/r/20200904045128.23631-2-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Arun Easi <aeasi@marvell.com>
Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In the discovery thread, ibmvfc does a vhost->task_set++ without any lock
held. This could result in two targets getting the same cancel key, which
could have strange effects in error recovery. The actual probability of
this occurring should be extremely small, since this should all be done in
a single threaded loop from the discovery thread, but let's fix it up
anyway to be safe.
Link: https://lore.kernel.org/r/1600286999-22059-1-git-send-email-brking@linux.vnet.ibm.com
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
scatter_data_area() has two purposes:
1) Create the iovs for the data area buffer of a SCSI cmd.
2) If there is data in DMA_TO_DEVICE direction, copy
the data from sg_list to data area buffer.
Both are done in a common loop.
In case of DMA_FROM_DEVICE data transfer, scatter_data_area() is called
with parameter copy_data = false. But this flag is just used to skip
memcpy() for data, while radix_tree_lookup still is called for every dbi of
the area area buffer, and kmap and kunmap are called for every page from
sg_list and data_area as well as flush_dcache_page() for the data area
pages. Since the only thing to do with copy_data = false would be to set
up the iovs, this is a noticeable overhead. Rework the iov creation in the
main loop of scatter_data_area() providing the new function
new_block_to_iov(). Based on this, create the short new function
tcmu_setup_iovs() that only writes the iovs with no overhead. This new
function is now called instead of scatter_data_area() for bidi buffers and
for data buffers in those cases where memcpy() would have been skipped.
Link: https://lore.kernel.org/r/20200910155041.17654-4-bstroesser@ts.fujitsu.com
Acked-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
queue_cmd_ring() needs to check whether there is enough space in cmd ring
and data area for the cmd to queue.
Currently the sequence is:
1) Calculate size the cmd will occupy on the ring based on estimation of
needed iovs.
2) Check whether there is enough space on the ring based on size from 1)
3) Allocate buffers in data area.
4) Calculate number of iovs the command really needs while copying
incoming data (if any) to data area.
5) Re-calculate real size of cmd on ring based on real number of iovs.
6) Set up possible padding and cmd on the ring.
Step 1) must not underestimate the cmd size so use max possible number of
iovs for the given I/O data size. The resulting overestimation can be
really high so this sequence is not ideal. The earliest the real number of
iovs can be calculated is after data buffer allocation. Therefore rework
the code to implement the following sequence:
A) Allocate buffers on data area and calculate number of necessary iovs
during this.
B) Calculate real size of cmd on ring based on number of iovs.
C) Check whether there is enough space on the ring.
D) Set up possible padding and cmd on the ring.
The new sequence enforces the split of new function tcmu_alloc_data_space()
from is_ring_space_avail(). Using this function, change queue_cmd_ring()
according to the new sequence.
Change routines called by tcmu_alloc_data_space() to allow calculating and
returning the iov count. Remove counting of iovs in scatter_data_area().
Link: https://lore.kernel.org/r/20200910155041.17654-3-bstroesser@ts.fujitsu.com
Acked-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Simplify code by joining tcmu_cmd_get_data_length() and
tcmu_cmd_get_block_cnt() into tcmu_cmd_set_block_cnts(). The new function
sets tcmu_cmd->dbi_cnt and also the new field tcmu_cmd->dbi_bidi_cnt which
is needed for further enhancements in following patches. Simplify some
code by using tcmu_cmd->dbi(_bidi)_cnt instead of calculation from length.
Please note: The calculation of the number of dbis needed for bidi was
wrong. It was based on the length of the first bidi sg only. I changed it
to correctly sum up entire length of all bidi sgs.
Link: https://lore.kernel.org/r/20200910155041.17654-2-bstroesser@ts.fujitsu.com
Acked-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The request queue is currently run unconditionally in scsi_end_request() if
both target queue and host queue are ready.
Recently Long Li reported that cost of a queue run can be very heavy in
case of high queue depth. Improve this situation by only running the
request queue when this LUN is busy.
Link: https://lore.kernel.org/r/20200910075056.36509-1-ming.lei@redhat.com
Reported-by: Long Li <longli@microsoft.com>
Tested-by: Long Li <longli@microsoft.com>
Tested-by: Kashyap Desai <kashyap.desai@broadcom.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: John Garry <john.garry@huawei.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
kmemdup() can be used instead of kmalloc()+memcpy(). Replace two
occurrences of this pattern.
Issue identified with Coccinelle.
Link: https://lore.kernel.org/r/20200909185855.151964-1-alex.dewar90@gmail.com
Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
VirtIO 1.0 spec says:
The removed and rescan events ... when sent for LUN 0, they MAY
apply to the entire target so the driver can ask the initiator
to rescan the target to detect this.
This change introduces the behaviour described above by scanning the entire
SCSI target when LUN is set to 0. This is both a functional and a
performance fix. It aligns the driver with the spec and allows control
planes to hotplug targets with large numbers of LUNs without having to
request a RESCAN for each one of them.
Link: https://lore.kernel.org/r/CY4PR02MB33354370E0A81E75DD9DFE74FB520@CY4PR02MB3335.namprd02.prod.outlook.com
Suggested-by: Felipe Franciosi <felipe@nutanix.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Matej Genci <matej.genci@nutanix.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following sparse warning:
drivers/scsi/myrb.c:2229:27: warning: symbol 'myrb_template' was not
declared. Should it be static?
drivers/scsi/myrb.c:2318:31: warning: symbol 'myrb_raid_functions' was
not declared. Should it be static?
drivers/scsi/myrb.c:2492:6: warning: symbol 'myrb_err_status' was not
declared. Should it be static?
Link: https://lore.kernel.org/r/20200915084018.2826922-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following sparse warning:
drivers/scsi/myrs.c:1532:5: warning: symbol 'myrs_host_reset' was not
declared. Should it be static?
drivers/scsi/myrs.c:1922:27: warning: symbol 'myrs_template' was not
declared. Should it be static?
drivers/scsi/myrs.c:2036:31: warning: symbol 'myrs_raid_functions' was
not declared. Should it be static?
drivers/scsi/myrs.c:2046:6: warning: symbol 'myrs_flush_cache' was not
declared. Should it be static?
Link: https://lore.kernel.org/r/20200915084008.2826835-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following sparse warning:
drivers/scsi/isci/phy.c:672:6: warning: symbol
'scu_link_layer_set_txcomsas_timeout' was not declared. Should it be
static?
Link: https://lore.kernel.org/r/20200915084000.2826741-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This eliminates the following sparse warning:
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:53:1: warning: symbol
'bnx2fc_global_lock' was not declared. Should it be static?
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:111:6: warning: symbol
'bnx2fc_devloss_tmo' was not declared. Should it be static?
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:116:6: warning: symbol
'bnx2fc_max_luns' was not declared. Should it be static?
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:121:6: warning: symbol
'bnx2fc_queue_depth' was not declared. Should it be static?
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:126:6: warning: symbol
'bnx2fc_log_fka' was not declared. Should it be static?
Link: https://lore.kernel.org/r/20200912033758.142601-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This eliminates the following sparse warning:
drivers/scsi/isci/init.c:145:25: warning: symbol 'isci_host_attrs' was
not declared. Should it be static?
Link: https://lore.kernel.org/r/20200912033741.142415-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This eliminates the following sparse warning:
drivers/scsi/aacraid/aachba.c:245:5: warning: symbol 'aac_convert_sgl'
was not declared. Should it be static?
drivers/scsi/aacraid/aachba.c:293:5: warning: symbol 'acbsize' was not
declared. Should it be static?
drivers/scsi/aacraid/aachba.c:324:5: warning: symbol 'aac_wwn' was not
declared. Should it be static?
Link: https://lore.kernel.org/r/20200912033749.142488-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If (x_status & XE_PARITY_ERR) is true we set cam_status = DID_PARITY,
othervise cam_status always ends up being DID_ERROR. Delete superfluous
else-if statements.
Link: https://lore.kernel.org/r/20200902061646.576966-1-yebin10@huawei.com
Signed-off-by: Ye Bin <yebin10@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When a canister on a FS9100, or similar storage, running in NPIV mode, is
rebooted, its WWPNs will fail over to another canister. When this occurs,
we see a WWPN going away from the fabric at one N-Port ID, and, a short
time later, the same WWPN appears at a different N-Port ID. When the
canister is fully operational again, the WWPNs fail back to the original
canister. If there is any I/O outstanding to the target when this occurs,
it will result in the implicit logout the ibmvfc driver issues before
removing the rport to fail. When the WWPN then shows up at a different
N-Port ID, and we issue a PLOGI to it, the VIOS will see that it still has
a login for this WWPN at the old N-Port ID, which results in the VIOS
simulating a link down / link up sequence to the client, in order to get
the VIOS and client LPAR in sync.
The patch below improves the way we handle this scenario so as to avoid the
link bounce, which affects all targets under the virtual host adapter. The
change is to utilize the Move Login MAD, which will work even when I/O is
outstanding to the target. The change only alters the target state machine
for the case where the implicit logout fails prior to deleting the rport.
If this implicit logout fails, we defer deleting the ibmvfc_target object
after calling fc_remote_port_delete. This enables us to later retry the
implicit logout after terminate_rport_io occurs, or to issue the Move Login
request if a WWPN shows up at a new N-Port ID prior to this occurring.
This has been tested by IBM's storage interoperability team on a FS9100,
forcing the failover to occur. With debug tracing enabled in the ibmvfc
driver, we confirmed the move login was sent in this scenario and confirmed
the link bounce no longer occurred.
[mkp: fix checkpatch warnings]
Link: https://lore.kernel.org/r/1599859706-8505-1-git-send-email-brking@linux.vnet.ibm.com
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
No need for else after return.
Link: https://lore.kernel.org/r/20200910074843.217661-2-damien.lemoal@wdc.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Boot occasionally fails with some Samsung low-power UFS devices. The reason
is that these devices have a little bit higher latency for NOP OUT
responses. This causes boot to fail because the NOP OUT command is issued
during initialization to check whether the device transport protocol is
ready or not. Increase NOP_OUT_TIMEOUT value from 30 to 50ms.
Link: https://lore.kernel.org/r/231786897.01599016081767.JavaMail.epsvc@epcpadp2
Acked-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Daejun Park <daejun7.park@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
There is no need to compute modulo. A simple comparison is good enough.
Link: https://lore.kernel.org/r/20200911180057.14633-1-thenzl@redhat.com
Acked-by: sreekanth reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
_base_process_reply_queue() called from _base_interrupt() may schedule a
new irq poll. Fix this by calling synchronize_irq() first.
Also ensure that enable_irq() is called only when necessary to avoid
"Unbalanced enable for IRQ..." errors.
Link: https://lore.kernel.org/r/20200910142126.8147-1-thenzl@redhat.com
Fixes: 320e77acb3 ("scsi: mpt3sas: Irq poll to avoid CPU hard lockups")
Acked-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The driver will throw an error message when a tampered type controller
is detected. The intent is to avoid interacting with any firmware
which is not secured/signed by Broadcom. Any tampering on firmware
component will be detected by hardware and it will be communicated to
the driver to avoid any further interaction with that component.
[mkp: switched back to dev_err]
Link: https://lore.kernel.org/r/20200814130426.2741171-1-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following sparse warning:
drivers/scsi/megaraid/megaraid_sas_base.c:80:5: warning: symbol
'smp_affinity_enable' was not declared. Should it be static?
Link: https://lore.kernel.org/r/20200915083948.2826598-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The variable ret has been initialized with a value '0'. The assignment in
switch-case is redundant. Remove it.
Link: https://lore.kernel.org/r/20200914023207.113792-1-jingxiangfeng@huawei.com
Reviewed-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
While reviewing commit 936e6b85da ("scsi: zfcp: Fix panic on ERP timeout
for previously dismissed ERP action"), I stumbled over
zfcp_fsf_req_complete() and wondered whether it has similar issues wrt
concurrent modification of req->erp_action by
zfcp_erp_strategy_check_fsfreq().
But a closer look shows that both its two callers [zfcp_fsf_reqid_check(),
zfcp_fsf_req_dismiss_all()] remove the request from the adapter's req_list
under the req_list's lock. Hence we can trust that if
zfcp_erp_strategy_check_fsfreq() concurrently looks up the corresponding
req_id, it won't find this request and is thus unable to modify it while
it's being processed by zfcp_fsf_req_complete().
Add a code comment that hopefully makes this easier for future readers, and
condense the two accesses to ->erp_action that made me trip over this code
path in the first place.
Link: https://lore.kernel.org/r/c500eac301fcbba5af942bbd200f2d6b14e46994.1599765652.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Use the right helper to avoid poking around in the list's internals.
Link: https://lore.kernel.org/r/ed669555c73aab95b29444c10066f492c0c43391.1599765652.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/libfc/fc_disc.c:304
fc_disc_error() warn: passing zero to 'PTR_ERR'
fp may be NULL in fc_disc_error(), use PTR_ERR_OR_ZERO to handle this.
Link: https://lore.kernel.org/r/20200909135432.36772-1-yuehaibing@huawei.com
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following coccinelle warning:
drivers/scsi/fnic/fnic_main.c:446:2-3: Unneeded semicolon
Link: https://lore.kernel.org/r/20200911091057.2938685-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following coccinelle warning:
drivers/scsi/nsp32.c:1250:4-5: Unneeded semicolon
drivers/scsi/nsp32.c:1842:2-3: Unneeded semicolon
Link: https://lore.kernel.org/r/20200911091049.2938158-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following coccinelle warning:
drivers/scsi/sym53c8xx_2/sym_fw.c:372:3-4: Unneeded semicolon
drivers/scsi/sym53c8xx_2/sym_fw.c:480:3-4: Unneeded semicolon
drivers/scsi/sym53c8xx_2/sym_fw.c:536:2-3: Unneeded semicolon
Link: https://lore.kernel.org/r/20200911091031.2937834-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following coccinelle warning:
drivers/scsi/qla2xxx/qla_init.c:7112:5-9: Unneeded variable: "rval".
Return "QLA_SUCCESS" on line 7115
Link: https://lore.kernel.org/r/20200911091021.2937708-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Intel host controllers support the setting of latency tolerance.
Accordingly, implement the PM QoS ->set_latency_tolerance() callback. The
raw register values are also exposed via debugfs.
Link: https://lore.kernel.org/r/20200827072030.24655-1-adrian.hunter@intel.com
Fixes: 8c09d75276 ("scsi: ufshdc-pci: Add Intel PCI IDs for EHL")
Fixes: 1ab27c9cf8 ("ufs: Add support for clock gating")
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Acked-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following gcc warning with "make W=1":
not used [-Wunused-but-set-variable]
struct lpfc_sli4_hdw_queue *qp;
^
Link: https://lore.kernel.org/r/20200909082716.37787-1-yebin10@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Ye Bin <yebin10@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/lpfc/lpfc_debugfs.c: In function ‘lpfc_debugfs_hdwqstat_data’:
drivers/scsi/lpfc/lpfc_debugfs.c:1699:30: warning: variable ‘qp’ set but
This addresses the following gcc warning with "make W=1":
drivers/scsi/gdth.c: In function ‘gdth_async_event’:
drivers/scsi/gdth.c:3010:9: warning: variable ‘cmd_index’ set but not
used [-Wunused-but-set-variable]
int cmd_index;
Link: https://lore.kernel.org/r/20200909082627.101984-1-yebin10@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Ye Bin <yebin10@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following gcc warning with "make W=1":
drivers/scsi/pmcraid.c: In function ‘pmcraid_abort_cmd’:
drivers/scsi/pmcraid.c:2863:33: warning: variable ‘res’ set but not
used [-Wunused-but-set-variable]
struct pmcraid_resource_entry *res;
^
Link: https://lore.kernel.org/r/20200909082627.101984-2-yebin10@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Ye Bin <yebin10@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following gcc warning with "make W=1":
drivers/scsi/qla1280.c: In function ‘qla1280_status_entry’:
drivers/scsi/qla1280.c:3607:28: warning: variable ‘lun’ set but not used
[-Wunused-but-set-variable]
3607 | unsigned int bus, target, lun;
| ^~~
drivers/scsi/qla1280.c:3607:20: warning: variable ‘target’ set but not
used [-Wunused-but-set-variable]
3607 | unsigned int bus, target, lun;
| ^~~~~~
drivers/scsi/qla1280.c:3607:15: warning: variable ‘bus’ set but not used
[-Wunused-but-set-variable]
3607 | unsigned int bus, target, lun;
| ^~~
Link: https://lore.kernel.org/r/20200907074518.2326360-5-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following gcc warning with "make W=1":
drivers/scsi/qla1280.c: In function ‘qla1280_mailbox_command’:
drivers/scsi/qla1280.c:2430:11: warning: variable ‘data’ set but not
used [-Wunused-but-set-variable]
2430 | uint16_t data;
| ^~~~
Link: https://lore.kernel.org/r/20200907074518.2326360-4-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following gcc warning with "make W=1":
drivers/scsi/qla1280.c: In function ‘qla1280_nvram_config’:
drivers/scsi/qla1280.c:2188:36: warning: variable ‘ddma_conf’ set but
not used [-Wunused-but-set-variable]
2188 | uint16_t hwrev, cfg1, cdma_conf, ddma_conf;
| ^~~~~~~~~
Link: https://lore.kernel.org/r/20200907074518.2326360-3-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This addresses the following gcc warning with "make W=1":
drivers/scsi/qla1280.c: In function ‘qla1280_done’:
drivers/scsi/qla1280.c:1244:19: warning: variable ‘lun’ set but not used
[-Wunused-but-set-variable]
1244 | int bus, target, lun;
| ^~~
Link: https://lore.kernel.org/r/20200907074518.2326360-2-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
With !CONFIG_OF and SCSI_UFS_EXYNOS selected, the below warning is given:
WARNING: unmet direct dependencies detected for PHY_SAMSUNG_UFS
Depends on [n]: OF [=n] && (ARCH_EXYNOS || COMPILE_TEST [=y])
Selected by [y]:
- SCSI_UFS_EXYNOS [=y] && SCSI_LOWLEVEL [=y] && SCSI [=y] && SCSI_UFSHCD_PLATFORM [=y] && (ARCH_EXYNOS || COMPILE_TEST [=y])
Fix it by removing PHY_SAMSUNG_UFS dependency.
Link: https://lore.kernel.org/r/20200721172021.28922-1-alim.akhtar@samsung.com
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Fix to return error code PTR_ERR() from the error handling case instead of
0.
Link: https://lore.kernel.org/r/20200907083949.154251-1-jingxiangfeng@huawei.com
Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Fix build warnings with make W=1 as below,
1.
>> drivers/scsi/ufs/ufs-mediatek.c:116:22: warning: format '%d' expects
>> argument of type 'int', but argument 4 has type 'long int'
2.
CC [M] drivers/scsi/ufs/ufs-mediatek.o
../drivers/scsi/ufs/ufs-mediatek.c:749: error: Cannot parse struct or union!
/** is used specifically with kernel-doc tool.
As a quick fix by removing dubious /** in the comment block of
struct ufs_hba_variant_ops ufs_hba_mtk_vops.
Link: https://lore.kernel.org/r/20200910013756.11385-1-stanley.chu@mediatek.com
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
It was observed on an ISP8324 16Gb HBA with fw=8.08.203 (d0d5) in a
PowerPC64 machine that pkt->entry_type was MBX_IOCB_TYPE/0x39 with an
sp->type SRB_SCSI_CMD which is invalid and should not be possible.
Reading the entry_type from the crash dump shows the expected value of
STATUS_TYPE/0x03 but the call trace shows that qla24xx_mbx_iocb_entry() is
used.
Add a check to verify for consistency and reset the HBA if an invalid state
is reached. Obviously, this is only a workaround until the real problem is
solved.
Link: https://lore.kernel.org/r/20200908081516.8561-5-dwagner@suse.de
Reviewed-by: Arun Easi <aeasi@marvell.com>
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Quinn Tran