- 21 Jan, 2021 4 commits
-
-
Bean Huo authored
Once going into while-do loop, intr_status is already true, this if-statement is redundant, remove it. Link: https://lore.kernel.org/r/20210118201233.3043-1-huobean@gmail.comReviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Colin Ian King authored
There is a spelling mistake in a ibmvfc_dbg debug message. Fix it. Link: https://lore.kernel.org/r/20210118111346.70798-1-colin.king@canonical.comSigned-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'pm8001_init_ccb_tag()' GFP_KERNEL can be used because this function already uses this flag a few lines above. While at it, remove "pm80xx: " in a debug message. 'pm8001_dbg()' already adds the driver name in the message. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Link: https://lore.kernel.org/r/20210117132445.562552-1-christophe.jaillet@wanadoo.frAcked-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Colin Ian King authored
A block of code is indented one level too deeply, clean this up. Link: https://lore.kernel.org/r/20210115095824.9170-1-colin.king@canonical.comAcked-by:
-
- 20 Jan, 2021 1 commit
-
-
Martin K. Petersen authored
Pull in the 5.11 SCSI fixes branch to provide an updated baseline for megaraid and hisi_sas. Both drivers received core changes in v5.11-rc3. Signed-off-by:
-
- 15 Jan, 2021 28 commits
-
-
Muneendra Kumar authored
Add support for eh_should_retry_cmd callback in lpfc_template. Link: https://lore.kernel.org/r/1609969748-17684-6-git-send-email-muneendra.kumar@broadcom.comReviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by:
-
Muneendra Kumar authored
Add store capability to the rport port_state using sysfs under fc_remote_ports/rport-*/port_state. With this the user can move the port_state from Marginal->Online and Online->Marginal. - Marginal: This interface will set SCMD_NORETRIES_ABORT bit in scmd->state for all the pending I/Os on the SCSI device associated with target port. - Online: This interface will clear SCMD_NORETRIES_ABORT bit in scmd->state for all the pending I/Os on the SCSI device associated with target port. The following interface is provided to set the port state to Marginal and Online respectively: echo "Marginal" >> /sys/class/fc_remote_ports/rport-X\:Y-Z/port_state echo "Online" >> /sys/class/fc_remote_ports/rport-X\:Y-Z/port_state Link: https://lore.kernel.org/r/1609969748-17684-5-git-send-email-muneendra.kumar@broadcom.comReviewed-by:
-
Muneendra Kumar authored
Add a new interface, fc_eh_should_retry_cmd(), which checks if the cmd should be retried or not by checking the rport state. If the rport state is marginal it returns false to make sure there won't be any retries on the cmd. Make the fc_remote_port_delete(), fc_user_scan_tgt(), and fc_timeout_deleted_rport() functions handle the new rport state. Link: https://lore.kernel.org/r/1609969748-17684-4-git-send-email-muneendra.kumar@broadcom.comReviewed-by:
-
Muneendra Kumar authored
Add a new optional routine, eh_should_retry_cmd(), in scsi_host_template that allows the transport to decide if a cmd is retryable. Return true if the transport is in a state the cmd should be retried on. Update scmd_eh_abort_handler() and scsi_eh_flush_done_q() to both call scsi_eh_should_retry_cmd() to check whether the command needs to be retried. The above changes were based on a patch by Mike Christie. Link: https://lore.kernel.org/r/1609969748-17684-3-git-send-email-muneendra.kumar@broadcom.comReviewed-by:
-
Muneendra Kumar authored
Add code in scsi_result_to_blk_status to translate a new error DID_TRANSPORT_MARGINAL to the corresponding blk_status_t i.e BLK_STS_TRANSPORT. Add DID_TRANSPORT_MARGINAL case to scsi_decide_disposition(). Link: https://lore.kernel.org/r/1609969748-17684-2-git-send-email-muneendra.kumar@broadcom.comReviewed-by:
-
Tyrel Datwyler authored
Add the various module parameter toggles for adjusting the MQ characteristics at boot/load time as well as a device attribute for changing the client scsi channel request amount. Link: https://lore.kernel.org/r/20210114203148.246656-22-tyreld@linux.ibm.comReviewed-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by:
-
Tyrel Datwyler authored
Turn on MQ by default and set sane values for the upper limit on hw queues for the SCSI host, and number of hw SCSI channels to request from the partner VIOS. Link: https://lore.kernel.org/r/20210114203148.246656-21-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Grab the queue and list lock for each Sub-CRQ and add any uncompleted events to the host purge list. Link: https://lore.kernel.org/r/20210114203148.246656-20-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
In general the client needs to send Cancel MADs and task management commands down the same channel as the command(s) intended to cancel or abort. The client assigns cancel keys per LUN and thus must send a Cancel down each channel commands were submitted for that LUN. Further, the client then must wait for those cancel completions prior to submitting a LUN RESET or ABORT TASK SET. Add a cancel rsp iu syncronization field to the ibmvfc_queue struct such that the cancel routine can sync the cancel response to each queue that requires a cancel command. Build a list of each cancel event sent and wait for the completion of each submitted cancel. Link: https://lore.kernel.org/r/20210114203148.246656-19-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Add a helper routine for initializing a Cancel MAD. This will be useful for a channelized client that needs to send Cancel commands down every channel commands were sent for a particular LUN. Link: https://lore.kernel.org/r/20210114203148.246656-18-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
If the ibmvfc client adapter requests channels it must submit a number of Sub-CRQ handles matching the number of channels being requested. The VIOS in its response will overwrite the actual number of channel resources allocated which may be less than what was requested. The client then must store the VIOS Sub-CRQ handle for each queue. This VIOS handle is needed as a parameter with h_send_sub_crq(). Link: https://lore.kernel.org/r/20210114203148.246656-17-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
When the client has negotiated the use of channels all vfcFrames are required to go down a Sub-CRQ channel or it is a protocoal violation. If the adapter state is channelized submit vfcFrames to the appropriate Sub-CRQ via the h_send_sub_crq() helper. Link: https://lore.kernel.org/r/20210114203148.246656-16-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Extract the hwq id from a SCSI command and store it in the ibmvfc_event structure to identify which Sub-CRQ to send the command down when channels are being utilized. Link: https://lore.kernel.org/r/20210114203148.246656-15-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Previous patches have plumbed the necessary Sub-CRQ interface and channel negotiation MADs to fully channelize via hardware backed queues. Advertise client support via NPIV Login capability IBMVFC_CAN_USE_CHANNELS when the client bits have MQ enabled via vhost->mq_enabled, or when channels were already in use during a subsequent NPIV Login. The later is required because channel support is only renegotiated after a CRQ pair is broken. Simple NPIV Logout/Logins require the client to continue to advertise the channel capability until the CRQ pair between the client is broken. Link: https://lore.kernel.org/r/20210114203148.246656-14-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
New NPIV_ENQUIRY_CHANNEL and NPIV_SETUP_CHANNEL management datagrams (MADs) were defined in a previous patchset. If the client advertises a desire to use channels and the partner VIOS is channel capable then the client must proceed with channel enquiry to determine the maximum number of channels the VIOS is capable of providing, and registering SubCRQs via channel setup with the VIOS immediately following NPIV Login. This handshaking should not be performed for subsequent NPIV Logins unless the CRQ connection has been reset. Implement these two new MADs and issue them following a successful NPIV login where the VIOS has set the SUPPORT_CHANNELS capability bit in the NPIV Login response. Link: https://lore.kernel.org/r/20210114203148.246656-13-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Create an irq mapping for the hw_irq number provided from phyp firmware. Request an irq assigned our Sub-CRQ interrupt handler. Unmap these irqs at Sub-CRQ teardown. Link: https://lore.kernel.org/r/20210114203148.246656-12-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Simple handler that calls Sub-CRQ drain routine directly. Link: https://lore.kernel.org/r/20210114203148.246656-11-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
The logic for iterating over the Sub-CRQ responses is similiar to that of the primary CRQ. Add the necessary handlers for processing those responses. Link: https://lore.kernel.org/r/20210114203148.246656-10-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Each Sub-CRQ has its own interrupt. A hypercall is required to toggle the IRQ state. Provide the necessary mechanism via a helper function. Link: https://lore.kernel.org/r/20210114203148.246656-9-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Allocate a set of Sub-CRQs in advance. During channel setup the client and VIOS negotiate the number of queues the VIOS supports and the number that the client desires to request. Its possible that the final channel resources allocated is less than requested, but the client is still responsible for sending handles for every queue it is hoping for. Also, provide deallocation cleanup routines. Link: https://lore.kernel.org/r/20210114203148.246656-8-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Subordinate Command Response Queues (Sub CRQ) are used in conjunction with the primary CRQ when more than one queue is needed by the virtual I/O adapter. Recent phyp firmware versions support Sub CRQ's with ibmvfc adapters. This feature is a prerequisite for supporting multiple hardware backed submission queues in the vfc adapter. The Sub CRQ command element differs from the standard CRQ in that it is 32bytes long as opposed to 16bytes for the latter. Despite this extra 16bytes the ibmvfc protocol will use the original CRQ command element mapped to the first 16bytes of the Sub CRQ element initially. Add definitions for the Sub CRQ command element and queue. Link: https://lore.kernel.org/r/20210114203148.246656-7-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Sub-CRQs are registred with firmware via a hypercall. Abstract that interface into a simpler helper function. Link: https://lore.kernel.org/r/20210114203148.246656-6-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
With the upcoming addition of Sub-CRQs the event pool size may vary per-queue. Add a size parameter to ibmvfc_init_event_pool() such that different size event pools can be requested by ibmvfc_alloc_queue(). Link: https://lore.kernel.org/r/20210114203148.246656-5-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
The event pool and CRQ used to be separate entities of the adapter host structure and as such were allocated and freed independently of each other. Recent work as defined a generic queue structure with an event pool specific to each queue. As such the event pool for each queue shouldn't be allocated/freed independently, but instead performed as part of the queue allocation/free routines. Move the calls to ibmvfc_event_pool_{init|free} into ibmvfc_{alloc|free}_queue respectively. The only functional change here is that the CRQ cannot be released in ibmvfc_remove until after the event pool has been successfully purged since releasing the queue will also free the event pool. Link: https://lore.kernel.org/r/20210114203148.246656-4-tyreld@linux.ibm.comReviewed-by: -
Tyrel Datwyler authored
The next patch in this series reworks the event pool allocation calls to happen within the individual queue allocation routines instead of as independent calls. Move the init/free routines earlier in ibmvfc.c to prevent undefined reference errors when calling these functions from the queue allocation code. No functional change. Link: https://lore.kernel.org/r/20210114203148.246656-3-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Introduce several new vhost fields for managing MQ state of the adapter as well as initial defaults for MQ enablement. Link: https://lore.kernel.org/r/20210114203148.246656-2-tyreld@linux.ibm.comReviewed-by:
-
Can Guo authored
User layer may access sysfs nodes when system PM ops or error handling is running. This can cause various problems. Rename eh_sem to host_sem and use it to protect PM ops and error handling from user layer intervention. Link: https://lore.kernel.org/r/1610594010-7254-3-git-send-email-cang@codeaurora.orgReviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Acked-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
-
Can Guo authored
During system resume/suspend, hba could be NULL. In this case, do not touch eh_sem. Fixes: 88a92d6a ("scsi: ufs: Serialize eh_work with system PM events and async scan") Link: https://lore.kernel.org/r/1610594010-7254-2-git-send-email-cang@codeaurora.orgAcked-by:
-
- 13 Jan, 2021 7 commits
-
-
John Garry authored
The mail address intel-linux-scu@intel.com bounces. Remove it. Link: https://lore.kernel.org/r/1610449890-198089-1-git-send-email-john.garry@huawei.com Cc: Ahmed S. Darwish <a.darwish@linutronix.de> Cc: Artur Paszkiewicz <artur.paszkiewicz@intel.com> Acked-by:
Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Bean Huo authored
The memory allocated with devm_kzalloc() is freed automatically no need to explicitly call devm_kfree(). Delete it and save some instruction cycles. Link: https://lore.kernel.org/r/20210112092128.19295-1-huobean@gmail.comReviewed-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
YANG LI authored
Fix the following coccicheck warning: ./drivers/scsi/lpfc/lpfc_bsg.c:5392:5-29: WARNING: Comparison to bool Link: https://lore.kernel.org/r/1610439893-64872-1-git-send-email-abaci-bugfix@linux.alibaba.comReported-by:
Abaci Robot <abaci@linux.alibaba.com> Reviewed-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
YANG LI <abaci-bugfix@linux.alibaba.com> Signed-off-by:
-
Jaegeuk Kim authored
Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units from rpmb LUN. The reason is that the unit descriptor length is different per LU. The length of Normal LU is 45 while the one of rpmb LU is 35. int ufshcd_read_desc_param(struct ufs_hba *hba, ...) { param_offset=41; param_size=4; buff_len=45; ... buff_len=35 by rpmb LU; if (is_kmalloc) { /* Make sure we don't copy more data than available */ if (param_offset + param_size > buff_len) param_size = buff_len - param_offset; --> param_size = 250; memcpy(param_read_buf, &desc_buf[param_offset], param_size); --> memcpy(param_read_buf, desc_buf+41, 250); [ 141.868974][ T9174] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: wb_buf_alloc_units_show+0x11c/0x11c } } Link: https://lore.kernel.org/r/20210111095927.1830311-1-jaegeuk@kernel.orgReviewed-by:Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Nilesh Javali authored
Link: https://lore.kernel.org/r/20210111093134.1206-8-njavali@marvell.comReviewed-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
-
Saurav Kashyap authored
Enable NVMe confirmation bit in PRLI. Link: https://lore.kernel.org/r/20210111093134.1206-7-njavali@marvell.comReviewed-by:
Saurav Kashyap <skashyap@marvell.com> Signed-off-by:
-
Quinn Tran authored
Mailbox Ch/dump ram extend expects mb register 10 to be set. If not set/clear, firmware can pick up garbage from previous invocation of this mailbox. Example: mctp dump can set mb10. On subsequent flash read which use mailbox cmd Ch, mb10 can retain previous value. Link: https://lore.kernel.org/r/20210111093134.1206-6-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
-
