- 13 Dec, 2018 9 commits
-
-
John Garry authored
This patchset fixes some warnings detected by the sparse tool, like these: drivers/scsi/hisi_sas/hisi_sas_main.c:1469:52: warning: incorrect type in assignment (different base types) drivers/scsi/hisi_sas/hisi_sas_main.c:1469:52: expected unsigned short [unsigned] [assigned] [usertype] tag_of_task_to_be_managed drivers/scsi/hisi_sas/hisi_sas_main.c:1469:52: got restricted __le16 [usertype] <noident> drivers/scsi/hisi_sas/hisi_sas_main.c:1723:52: warning: incorrect type in assignment (different base types) drivers/scsi/hisi_sas/hisi_sas_main.c:1723:52: expected unsigned short [unsigned] [assigned] [usertype] tag_of_task_to_be_managed drivers/scsi/hisi_sas/hisi_sas_main.c:1723:52: got restricted __le16 [usertype] <noident> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Himanshu Madhani authored
Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
Giridhar Malavali authored
This patch fixes NVMe discovery by setting SKIP_PRLI flag, so that PRLI is driven by driver and is retried when the NPIV port is detected to have NVMe capability. Signed-off-by:
Giridhar Malavali <gmalavali@marvell.com> Signed-off-by:
-
Himanshu Madhani authored
This patch fixes issues with NPIV port with FC-NVMe. Clean up code for remoteport delete and also call nvme_delete when deleting VPs. Signed-off-by:
-
Anil Gurumurthy authored
Signed-off-by:
Anil Gurumurthy <agurumurthy@marvell.com> Signed-off-by:
-
Arnd Bergmann authored
The event_wait semaphore has completion semantics, so we can change it over to the completion interface for clarity without changing the behavior. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Dave Carroll <david.carroll@microsemi.com> Signed-off-by:
-
Arnd Bergmann authored
The wait_sem member is used like a completion, so we should use the respective API. The behavior is unchanged. Signed-off-by:
-
James Smart authored
Addition of support for if_type=6 missed several checks for interface type, resulting in the failure of several key management features such as firmware dump and loopback testing. Correct the checks on the if_type so that both SLI4 IF_TYPE's 2 and 6 are supported. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
Martin K. Petersen authored
This reverts commit 287aba25. We killed the bad firmware and this mod is no longer necessary. Signed-off-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
- 08 Dec, 2018 31 commits
-
-
James Smart authored
Update the driver version to 12.0.0.9 Signed-off-by:
-
James Smart authored
When dif and first burst is used in a write command wqe, the driver was not properly setting fields in the io command request. This resulted in no dif bytes being sent and invalid xfer_rdy's, resulting in the io being aborted by the hardware. Correct the wqe initializaton when both dif and first burst are used. Signed-off-by:
-
James Smart authored
On driver termination, after the driver stops fw logging by writing a register on the chip, the driver immediately unmaps and frees the logging buffer, without confirming in any way that the chip has received the write and terminated the logging. As termination on the chip is not immediate, the chip may issue a dma request to the now unmapped dma buffer, resulting in a iommu fault. Change the driver to receive a confirmation that logging ahs been terminated. As the driver always issues an SLI reset with the device as part of shutdown, and as part of that is receiving confirmation that the reset is complete - the driver was modified to perform the write to disable fw logging prior to the SLI reset and only free the fw log buffer after the SLI reset is complete. That guarantees use of the fw log buffer is fully terminated when it is unmapped. Signed-off-by:
-
James Smart authored
Driver missed classifying the chip type for G7 when reporting supported topologies. This resulted in loop being shown as supported on FC links that are not supported per the standard. Add the chip classifications to the topology checks in the driver. Signed-off-by:
-
James Smart authored
Driver is setting bits in word 10 of the SLI4 ABORT WQE (the wqid). The field was a carry over from a prior SLI revision. The field does not exist in SLI4, and the action may result in an overlap with future definition of the WQE. Remove the setting of WQID in the ABORT WQE. Also cleaned up WQE field settings - initialize to zero, don't bother to set fields to zero. Signed-off-by:
-
James Smart authored
The current discovery state machine the driver treated FLOGI oddly. When point to point, an FLOGI is to be exchanged by the two ports, with the port with the most significant WWN then proceeding with PLOGI. The implementation in the driver was keyed to closely with "what have I sent", not with what has happened between the two endpoints. Thus, it blatantly would ACC an FLOGI, but reject PLOGI's until it had its FLOGI ACC'd. The problem is - the sending of FLOGI may be delayed for some reason, or the response to FLOGI held off by the other side. In the failing situation the other side sent an FLOGI, which was ACC'd, then sent PLOGIs which were then rjt'd until the retry count for the PLOGIs were exceeded and the port gave up. The FLOGI may have been very late in transmit, or the response held off until the PLOGIs failed. Given the other port had the higher WWN, no PLOGIs would occur and communication stopped. Correct the situation by changing the FLOGI handling. Defer any response to an FLOGI until the driver has sent its FLOGI as well. Then, upon either completion of the sent FLOGI, or upon sending an ACC to a received FLOGI (which may be received before or just after FLOGI was sent). the driver will act on who has the higher WWN. if the other port does, the driver will noop any handling of an FLOGI response (if outstanding) and wait for PLOGI. If the local port does, the driver will transition to sending PLOGI and will noop any action on responding to an FLOGI (if not yet received). Fortunately, to implement this, it only took another state flag and deferring any FLOGI response if the FLOGI has yet to be transmit. All subsequent actions were already in place. Signed-off-by:
-
James Smart authored
In some link initialization sequences, the fw generates an erroneous FLOGI payload to the driver without an intervening link bounce. The driver, when it sees a 2nd FLOGI without an intervening link bounce, automatically performs a link bounce. In this, the link bounce causes the situate to repeat and in a nasty loop of link bounces. Resolve the issue by validating the FLOGI payload. The erroneous FLOGI will contain VVL signatures that are not normal. When the driver sees these, it will simply reject the flogi rather than bouncing the link. The reject is consumed within the firmware. Signed-off-by:
-
James Smart authored
Two initiator ports were cable swapped and after swap both went down. The driver internally swaps the nlp nodes based on matching node wwn's but not the same nport id as before. After detecting a change in the nodes RPI, the driver sends an UNREG_RPI command and clears the NLP_RPI_REGISTERED flag, then swaps the node information with the other node. But the other node's NLP_RPI_REGISTERED flag is also cleared, but it is done so without an UNREG_RPI being sent, which causes the later REG_RPI for that other node to fail as the hardware believes its still registered. Additionally, if the node swap occurred while the two nodes had PLOGI's in flight, the fc4_types weren't properly getting swapped such that when the PLOGIs commpleted and PRLI's were then sent, the PRLI's acted on bad protocol types so the PRLI was for the wrong protocol. NVME devices saw SCSI FCP PRLIs and vice versa. Clean up the node swap so that the NLP_RPI_REGISTERED flag is handled properly. Fix the handling of the fc4_types when the nodes are swapped as well Signed-off-by:
-
James Smart authored
Depending on the chipset, the number of NPIV vports may vary and be in excess of what most switches support (256). To avoid confusion with the users, limit the reported NPIV vports to 256. Additionally correct the 16G adapter which is reporting a bogus NPIV vport number if the link is down. Signed-off-by:
-
James Smart authored
Driver is hitting null pring pointers in lpfc_do_work(). Pointer assignment occurs based on SLI-revision. If recovering after an error, its possible the sli revision for the port was cleared, making the lpfc_phba_elsring() not return a ring pointer, thus the null pointer. Add SLI revision checking to lpfc_phba_elsring() and status checking to all callers. Signed-off-by:
-
James Smart authored
Renumber one of the 0711 log messages so there isn't a duplication. Signed-off-by:
-
James Smart authored
The driver is getting hit with 100s of RSCNs during remote port address changes. Each of those RSCN's ends up generating UNREG_RPI and REG_PRI mailbox commands. The discovery engine within the driver doesn't wait for the mailbox command completions. Instead it sets state flags and moves forward. At some point, there's a massive backlog of mailbox commands which take time for the adapter to process. Additionally, it appears there were duplicate events from the switch so the driver generated duplicate mailbox commands for the same remote port. During this window, failures on PLOGI and PRLI ELS's are see as the adapter is rejecting them as they are for remote ports that still have pending mailbox commands. Streamline the discovery engine so that PLOGI log checks for outstanding UNREG_RPIs and defer the processing until the commands complete. This better synchronizes the ELS transmission vs the RPI registrations. Filter out multiple UNREG_RPIs being queued up for the same remote port. Beef up log messages in this area. Signed-off-by:
-
James Smart authored
The driver data structure for managing a mailbox command contained two context fields. Unfortunately, the context were considered "generic" to be used at the whim of the command code. Of course, one section of code used fields this way, while another did it that way, and eventually there were mixups. Refactored the structure so that the generic contexts become a node context and a buffer context and all code standardizes on their use. Signed-off-by:
-
James Smart authored
Update manufacturer attribute to reflect Broadcom Inc, not Emulex Signed-off-by:
-
James Smart authored
While trying to get adapter fw-log for a function whose buffsize was set to 0, kernel panic occurred. When buffsize is 0, the kernel buffer for the log won't be allocated. When fw log usage was enabled, it failed to check the buffer size, and log usage was started. Eventually the driver referenced the unallocated log buffer. Added checks of the buffer size before allowing fw logging to be enabled and added check for valid buffer if enabling fw log. Performed a couple other minor cleanups while fixing this: - clarified log messages - re-evaluated log message severity - treat any error as an error, not only a couple codes Signed-off-by:
-
James Bottomley authored
dma_addr_t can be u64 on pae systems but isa_virt_to_bus only ever returns unsigned long (because an ISA physical address can only be 24 bits). Cast to unsigned long to avoid division. Fixes: 1794ef2b ("scsi: aha1542: convert to DMA mapping API") Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Steffen Maier authored
Complements v2.6.35 commit 64deb6ef ("[SCSI] zfcp: Use status_read_buf_num provided by FCP channel") which replaced the hardcoded 16 with a variable value Also complements already existing fixups for above commit v2.6.35 commit 8d88cf3f ("[SCSI] zfcp: Update status read mempool") v3.10 commit 9edf7d75 ("[SCSI] zfcp: status read buffers on first adapter open with link down") Signed-off-by:
Steffen Maier <maier@linux.ibm.com> Reviewed-by:
Jens Remus <jremus@linux.ibm.com> Signed-off-by:
-
Steffen Maier authored
Suppose adapter (open) recovery is between opened QDIO queues and before (the end of) initial posting of status read buffers (SRBs). This time window can be seconds long due to FSF_PROT_HOST_CONNECTION_INITIALIZING causing by design looping with exponential increase sleeps in the function performing exchange config data during recovery [zfcp_erp_adapter_strat_fsf_xconf()]. Recovery triggered by local link up. Suppose an event occurs for which the FCP channel would send an unsolicited notification to zfcp by means of a previously posted SRB. We saw it with local cable pull (link down) in multi-initiator zoning with multiple NPIV-enabled subchannels of the same shared FCP channel. As soon as zfcp_erp_adapter_strategy_open_fsf() starts posting the initial status read buffers from within the adapter's ERP thread, the channel does send an unsolicited notification. Since v2.6.27 commit d26ab06e ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall"), zfcp_fsf_status_read_handler() schedules adapter->stat_work to re-fill the just consumed SRB from a work item. Now the ERP thread and the work item post SRBs in parallel. Both contexts call the helper function zfcp_status_read_refill(). The tracking of missing (to be posted / re-filled) SRBs is not thread-safe due to separate atomic_read() and atomic_dec(), in order to depend on posting success. Hence, both contexts can see atomic_read(&adapter->stat_miss) == 1. One of the two contexts posts one too many SRB. Zfcp gets QDIO_ERROR_SLSB_STATE on the output queue (trace tag "qdireq1") leading to zfcp_erp_adapter_shutdown() in zfcp_qdio_handler_error(). An obvious and seemingly clean fix would be to schedule stat_work from the ERP thread and wait for it to finish. This would serialize all SRB re-fills. However, we already have another work item wait on the ERP thread: adapter->scan_work runs zfcp_fc_scan_ports() which calls zfcp_fc_eval_gpn_ft(). The latter calls zfcp_erp_wait() to wait for all the open port recoveries during zfcp auto port scan, but in fact it waits for any pending recovery including an adapter recovery. This approach leads to a deadlock. [see also v3.19 commit 18f87a67 ("zfcp: auto port scan resiliency"); v2.6.37 commit d3e1088d ("[SCSI] zfcp: No ERP escalation on gpn_ft eval"); v2.6.28 commit fca55b6f ("[SCSI] zfcp: fix deadlock between wq triggered port scan and ERP") fixing v2.6.27 commit c57a39a4 ("[SCSI] zfcp: wait until adapter is finished with ERP during auto-port"); v2.6.27 commit cc8c2829 ("[SCSI] zfcp: Automatically attach remote ports")] Instead make the accounting of missing SRBs atomic for parallel execution in both the ERP thread and adapter->stat_work. Signed-off-by:
-
Rob Herring authored
Convert string compares of DT node names to use of_node_name_eq helper instead. This removes direct access to the node name pointer. Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
David Disseldorp authored
Initialise the t10_wwn vendor, model and revision defaults when a device is allocated instead of when it's enabled. This ensures that custom vendor or model strings set prior to enablement are not later overwritten with default values. The TRANSPORT_FLAG_PASSTHROUGH conditional can be dropped for the following reasons: - target_core_pscsi overwrites the defaults in the pscsi_configure_device() callback. + the contents is then only used for ConfigFS via $pscsi_dev/statistics/scsi_lu/vend, etc. - target_core_user doesn't touch the defaults, nor are they used for anything outside of ConfigFS. Signed-off-by:David Disseldorp <ddiss@suse.de> Reviewed-by:
Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by:
-
David Disseldorp authored
Use the value stored in t10_wwn.vendor, which defaults to "LIO-ORG", but can be reconfigured via the vendor_id ConfigFS attribute. Signed-off-by:
Bryant G. Ly <bly@catalogicsoftware.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
-
David Disseldorp authored
The vendor_id attribute will allow for the modification of the T10 Vendor Identification string returned in inquiry responses. Its value can be viewed and modified via the ConfigFS path at: target/core/$backstore/$name/wwn/vendor_id "LIO-ORG" remains the default value, which is set when the backstore device is enabled. [mkp: corrected VPD page number] Signed-off-by:
-
David Disseldorp authored
In preparation for supporting user provided vendor strings, add an extra byte to the vendor, model and revision arrays in struct t10_wwn. This ensures that the full INQUIRY data can be carried in the arrays along with a null-terminator. Change a number of array readers and writers so that they account for explicit null-termination: - The pscsi_set_inquiry_info() and emulate_model_alias_store() codepaths don't currently explicitly null-terminate; fix this. - Existing t10_wwn field dumps use for-loops which step over null-terminators for right-padding. + Use printf with width specifiers instead. Signed-off-by:
-
David Disseldorp authored
spc5r17.pdf specifies: 4.3.1 ASCII data field requirements ASCII data fields shall contain only ASCII printable characters (i.e., code values 20h to 7Eh) and may be terminated with one or more ASCII null (00h) characters. ASCII data fields described as being left-aligned shall have any unused bytes at the end of the field (i.e., highest offset) and the unused bytes shall be filled with ASCII space characters (20h). LIO currently space-pads the T10 VENDOR IDENTIFICATION and PRODUCT IDENTIFICATION fields in the standard INQUIRY data. However, the PRODUCT REVISION LEVEL field in the standard INQUIRY data as well as the T10 VENDOR IDENTIFICATION field in the INQUIRY Device Identification VPD Page are zero-terminated/zero-padded. Fix this inconsistency by using space-padding for all of the above fields. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
-
Thomas Meyer authored
NULL check before some freeing functions is not needed. Signed-off-by:
Thomas Meyer <thomas@m3y3r.de> Acked-by:
-
Thomas Meyer authored
NULL check before some freeing functions is not needed. Signed-off-by:
Manish Rangankar <Manish.Rangankar@cavium.com> Signed-off-by:
-
Thomas Meyer authored
NULL check before some freeing functions is not needed. Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Bart Van Assche authored
Nesting in __qla2x00_abort_all_cmds() is way too deep. Reduce the nesting level by introducing a helper function. This patch does not change any functionality. Reviewed-by:
Laurence Oberman <loberman@redhat.com> Acked-by:
Himanshu Madhani <himanshu.madhani@cavium.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Varun Prakash authored
flush_scheduled_work() is not required as csio_hw_exit_workers() calls cancel_work_sync() for hw->evtq_work. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
Fedor Loshakov authored
Introduce separate zfcp module parameters to individually select support for: DIF which should work (zfcp.dif, which used to be DIF+DIX, disabled) or DIX+DIF which can cause trouble (zfcp.dix, new, disabled). If DIX is enabled, we warn on zfcp driver initialization. As before, this also reduces the maximum I/O request size to half, to support the worst case of merged single sector requests with one protection data scatter gather element per sector. This can impact the maximum throughput. In DIF-only mode (zfcp.dif=1 zfcp.dix=0), we can use the full maximum I/O request size as there is no protection data for zfcp. Signed-off-by:
Fedor Loshakov <loshakov@linux.ibm.com> Reviewed-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1056537 ("Missing break in switch") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by:
Khalid Aziz <khalid@gonehiking.org> Signed-off-by:
-
