- 13 Jan, 2021 11 commits
-
-
Vishakha Channapattan authored
Added a log message in SATA completion path to capture the status of failed command. If the status does not match any expected status, another message will be logged. On IO failure with known status, the log message will be: [ 1712.951735] pm80xx0:: mpi_sata_completion 2269: IO failed device_id 16385 status 0x1 tag XX If the firmware returns unexpected status, a message of the following format will be logged: [ 1712.951735] pm80xx0:: mpi_sata_completion XXXX: Unknown status device_id XXXXX status 0xX tag XX Link: https://lore.kernel.org/r/20210109123849.17098-8-Viswas.G@microchip.comAcked-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
Vishakha Channapattan <vishakhavc@google.com> Signed-off-by:
Viswas G <Viswas.G@microchip.com> Signed-off-by:
Ruksar Devadi <Ruksar.devadi@microchip.com> Signed-off-by:
Ashokkumar N <Ashokkumar.N@microchip.com> Signed-off-by:
Radha Ramachandran <radha@google.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Bhavesh Jashnani authored
In check_fw_ready() we first wait for ILA to come up and then we wait for RAAE to come up and IOPs and so on. This is a sequential check. Because of this, ILA image seems to be not ready in the allocated time and so the driver marks it as "not ready" and then moves on to other FW images. ILA does become ready eventually, but is not checked again. The driver concludes that FW is not ready when it actually is. Instead of sequentially polling each image, we keep polling for all images to be ready. The timeout for the polling has been set to the sum of what was used for each individual image. Link: https://lore.kernel.org/r/20210109123849.17098-7-Viswas.G@microchip.comAcked-by:
Bhavesh Jashnani <bjashnani@google.com> Signed-off-by:
-
Viswas G authored
The function pm80xx_get_fatal_dump() has two issues that result in the fatal dump not being able to complete successfully. 1. Trying to collect fatal_logs from the application fails because we are not shifting the MEMBASE-II register properly. Once we read 64K region of data we have to shift the MEMBASE-II register and read the next chunk. Only then would we be able to get complete data. 2. If a timeout occurs, our application will get stuck. Link: https://lore.kernel.org/r/20210109123849.17098-6-Viswas.G@microchip.comAcked-by: -
akshatzen authored
Tag was not freed in NVMD get/set data request failure scenario. This caused a tag leak each time a request failed. Link: https://lore.kernel.org/r/20210109123849.17098-5-Viswas.G@microchip.comAcked-by:
akshatzen <akshatzen@google.com> Signed-off-by:
-
akshatzen authored
The driver initializes main configuration, general status, inbound queue and outbound queue table addresses based on a value read from MSGU_SCRATCH_PAD_0 register. We should validate these addresses before dereferencing them. Adds two validations: 1. Check if main configuration table offset lies within the pcibar mapped 2. Check if first dword of main configuration table reads "PMCS" There are two calls to init_pci_device_addresses() done during pm8001_pci_probe() in this sequence: 1. First inside chip_soft_rst, where if init_pci_device_addresses fails we will go ahead assuming MPI state is not ready and reset the device as long as bootloader is okay. This gives chance to second call of init_pci_device_addresses to set up the addresses after reset. 2. The second call is via pm80xx_chip_init, after soft reset is done and firmware is checked to be ready. Once that is done we are safe to go ahead and initialize default table values and use them. Tests: 1. Enabled debugging logs and observed no issues during initialization, with a controller with no issues: pm80xx0:: pm8001_setup_msix 1034: pci_alloc_irq_vectors request ret:64 no of intr 64 pm80xx0:: init_pci_device_addresses 917: Scratchpad 0 Offset: 0x2000 value 0x40002000 pm80xx0:: init_pci_device_addresses 925: Scratchpad 0 PCI BAR: 0 pm80xx0:: init_pci_device_addresses 952: VALID main config signature 0x53434d50 pm80xx0:: init_pci_device_addresses 975: GST OFFSET 0xc4 pm80xx0:: init_pci_device_addresses 978: INBND OFFSET 0x20000128 pm80xx0:: init_pci_device_addresses 981: OBND OFFSET 0x24000928 pm80xx0:: init_pci_device_addresses 984: IVT OFFSET 0x8001408 pm80xx0:: init_pci_device_addresses 987: PSPA OFFSET 0x8001608 pm80xx0:: init_pci_device_addresses 991: addr - main cfg (ptrval) general status (ptrval) pm80xx0:: init_pci_device_addresses 995: addr - inbnd (ptrval) obnd (ptrval) pm80xx0:: init_pci_device_addresses 999: addr - pspa (ptrval) ivt (ptrval) pm80xx0:: pm80xx_chip_soft_rst 1446: reset register before write : 0x0 pm80xx0:: pm80xx_chip_soft_rst 1478: reset register after write 0x40 pm80xx0:: pm80xx_chip_soft_rst 1544: SPCv soft reset Complete pm80xx0:: init_pci_device_addresses 917: Scratchpad 0 Offset: 0x2000 value 0x40002000 pm80xx0:: init_pci_device_addresses 925: Scratchpad 0 PCI BAR: 0 pm80xx0:: init_pci_device_addresses 952: VALID main config signature 0x53434d50 pm80xx0:: init_pci_device_addresses 975: GST OFFSET 0xc4 pm80xx0:: init_pci_device_addresses 978: INBND OFFSET 0x20000128 pm80xx0:: init_pci_device_addresses 981: OBND OFFSET 0x24000928 pm80xx0:: init_pci_device_addresses 984: IVT OFFSET 0x8001408 pm80xx0:: init_pci_device_addresses 987: PSPA OFFSET 0x8001608 pm80xx0:: init_pci_device_addresses 991: addr - main cfg (ptrval) general status (ptrval) pm80xx0:: init_pci_device_addresses 995: addr - inbnd (ptrval) obnd (ptrval) pm80xx0:: init_pci_device_addresses 999: addr - pspa (ptrval) ivt (ptrval) pm80xx0:: pm80xx_chip_init 1329: MPI initialize successful! 2. Tested controller with firmware known to have initialization issue and observed no crashes with this fix: pm80xx 0000:01:00.0: pm80xx: driver version 0.1.38 pm80xx 0000:01:00.0: Removing from 1:1 domain pm80xx 0000:01:00.0: Requesting non-1:1 mappings pm80xx0:: init_pci_device_addresses 948: BAD main config signature 0x0 pm80xx0:: mpi_uninit_check 1365: Failed to init pci addresses pm80xx0:: pm80xx_chip_soft_rst 1435: MPI state is not ready scratch:0:8:62a01000:0 pm80xx0:: pm80xx_chip_soft_rst 1518: Firmware is not ready! pm80xx0:: pm80xx_chip_soft_rst 1532: iButton Feature is not Available!!! pm80xx0:: pm80xx_chip_init 1301: Firmware is not ready! pm80xx0:: pm8001_pci_probe 1215: chip_init failed [ret: -16] pm80xx: probe of 0000:01:00.0 failed with error -16 pm80xx 0000:07:00.0: pm80xx: driver version 0.1.38 pm80xx 0000:07:00.0: Removing from 1:1 domain pm80xx 0000:07:00.0: Requesting non-1:1 mappings scsi host6: pm80xx pm80xx1:: pm8001_setup_sgpio 5568: failed sgpio_req timeout pm80xx1:: mpi_phy_start_resp 3447: phy start resp status:0x0, phyid:0x0 pm80xx 0000:08:00.0: pm80xx: driver version 0.1.38 pm80xx 0000:08:00.0: Removing from 1:1 domain pm80xx 0000:08:00.0: Requesting non-1:1 mappings 3. Without this fix we observe crash on the same controller: pm80xx 0000:01:00.0: pm80xx: driver version 0.1.38 pm80xx 0000:01:00.0: Removing from 1:1 domain pm80xx 0000:01:00.0: Requesting non-1:1 mappings [<ffffffffc0451b3b>] pm80xx_chip_soft_rst+0x6b/0x4c0 [pm80xx] [<ffffffffc043a933>] pm8001_pci_probe+0xa43/0x1630 [pm80xx] RIP: 0010:pm80xx_chip_soft_rst+0x71/0x4c0 [pm80xx] [<ffffffffc0451b3b>] ? pm80xx_chip_soft_rst+0x6b/0x4c0 [pm80xx] [<ffffffffc043a933>] pm8001_pci_probe+0xa43/0x1630 [pm80xx] pm80xx0:: mpi_uninit_check 1339: TIMEOUT:IBDB value/=2 pm80xx0:: pm80xx_chip_soft_rst 1387: MPI state is not ready scratch:0:8:62a01000:0 pm80xx0:: pm80xx_chip_soft_rst 1470: Firmware is not ready! pm80xx0:: pm80xx_chip_soft_rst 1484: iButton Feature is not Available!!! pm80xx0:: pm80xx_chip_init 1266: Firmware is not ready! pm80xx0:: pm8001_pci_probe 1207: chip_init failed [ret: -16] pm80xx: probe of 0000:01:00.0 failed with error -16 Link: https://lore.kernel.org/r/20210109123849.17098-4-Viswas.G@microchip.comAcked-by: -
akshatzen authored
When the controller runs into a fatal error, commands get stuck due to no response. If the controller is in fatal error state, abort requests issued to the controller get stuck too. Check the controller state for fatal error conditions. Link: https://lore.kernel.org/r/20210109123849.17098-3-Viswas.G@microchip.comAcked-by:
-
akshatzen authored
We do not need to busy wait during mpi_init_check() since it is not being invoked in atomic context. mpi_init_check() is being called from pm8001_pci_resume(), pm8001_pci_probe(). Hence we are replacing udelay with msleep. Link: https://lore.kernel.org/r/20210109123849.17098-2-Viswas.G@microchip.comAcked-by:
-
Ziqi Chen authored
According to the spec (JESD220E chapter 7.2), while powering off/on the ufs device, RST_n signal should be between VSS(Ground) and VCCQ/VCCQ2. Link: https://lore.kernel.org/r/1610103385-45755-3-git-send-email-ziqichen@codeaurora.orgAcked-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Ziqi Chen <ziqichen@codeaurora.org> Signed-off-by:
-
Ziqi Chen authored
According to the spec (JESD220E chapter 7.2), while powering off/on the ufs device, REF_CLK signal should be between VSS(Ground) and VCCQ/VCCQ2. Link: https://lore.kernel.org/r/1610103385-45755-2-git-send-email-ziqichen@codeaurora.orgReviewed-by:
Can Guo <cang@codeaurora.org> Acked-by:
-
YANG LI authored
The variable 'status' is being initialized with SCI_SUCCESS and never updated later with a new value. The initialization is redundant and can be removed. Link: https://lore.kernel.org/r/1609311860-102820-1-git-send-email-abaci-bugfix@linux.alibaba.comReported-by:
Abaci <abaci@linux.alibaba.com> Signed-off-by:
YANG LI <abaci-bugfix@linux.alibaba.com> Signed-off-by:
-
Adrian Hunter authored
People testing have a need to know how many errors might be occurring over time. Add error counters and expose them via debugfs. A module initcall is used to create a debugfs root directory for ufshcd-related items. In the case that modules are built-in, then initialization is done in link order, so move ufshcd-core to the top of the Makefile. Link: https://lore.kernel.org/r/20210107072538.21782-1-adrian.hunter@intel.comReviewed-by:
Bean Huo <beanhuo@micron.com> Reviewed-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
- 08 Jan, 2021 29 commits
-
-
Andrea Parri (Microsoft) authored
Check that the packet is of the expected size at least, don't copy data past the packet. Link: https://lore.kernel.org/r/20201217203321.4539-4-parri.andrea@gmail.com Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Reported-by:
Saruhan Karademir <skarade@microsoft.com> Reviewed-by:
Dexuan Cui <decui@microsoft.com> Reviewed-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
Andrea Parri (Microsoft) <parri.andrea@gmail.com> Signed-off-by:
-
Andrea Parri (Microsoft) authored
vmscsi_size_delta can be written concurrently by multiple instances of storvsc_probe(), corresponding to multiple synthetic IDE/SCSI devices; cf. storvsc_drv's probe_type == PROBE_PREFER_ASYNCHRONOUS. Change the global variable vmscsi_size_delta to per-synthetic-IDE/SCSI-device. Link: https://lore.kernel.org/r/20201217203321.4539-3-parri.andrea@gmail.com Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Suggested-by:
-
Andrea Parri (Microsoft) authored
Current code overestimates the value of max_outstanding_req_per_channel for Win8 and newer hosts, since vmscsi_size_delta is set to the initial value of sizeof(vmscsi_win8_extension) rather than zero. This may lead to wrong decisions when using ring_avail_percent_lowater equals to zero. The estimate of max_outstanding_req_per_channel is 'exact' for Win7 and older hosts. A better choice, keeping the algorithm for the estimation simple, is to err the other way around, i.e., to underestimate for Win7 and older but to use the exact value for Win8 and newer. Link: https://lore.kernel.org/r/20201217203321.4539-2-parri.andrea@gmail.com Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Suggested-by:
-
James Smart authored
Update lpfc version to 12.8.0.7 Link: https://lore.kernel.org/r/20210104180240.46824-16-jsmart2021@gmail.comCo-developed-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
James Smart authored
While testing recent discovery node rework, several items were seen that could be done better with respect to the new trace event logic. 1) in the following msg: kernel: lpfc 0000:44:00.0: start 35 end 35 cnt 0 If cnt is zero in the 1st message, there is no reason to display the 1st message, which is just giving start/end positioning. Fix by not displaying message if cnt is 0. 2) If the driver is loaded with module log verbosity off, and later a single NPIV host instance verbosity is enabled via sysfs, it enables messages on all instances. This is due to the trace log verbosity checks (lpfc_dmp_dbg) looking at the phba only. It should look at the phba and the vport. Fix by enabling a check on both phba and vport. 3) in the following messages: 2904 Firmware Dump Image Present on Adapter 2887 Reset Needed: Attempting Port Recovery... These messages are not necessary for the trace event log, which is primarily for discovery. Fix by changing log level on these 2 messages to LOG_SLI. Link: https://lore.kernel.org/r/20210104180240.46824-15-jsmart2021@gmail.comCo-developed-by: -
James Smart authored
Several errors have occurred where the adapter stops or fails but does not raise the register values for the driver to detect failure. Thus driver is unaware of the failure. The failure typically results in I/O timeouts, the I/O timeout handler failing (after several seconds), and the error handler escalating recovery policy and resulting in more errors. Eventually, the driver is in a position where things have spiraled and it can't do recovery because other recovery ops are still outstanding and it becomes unusable. Resolve the situation by having the I/O timeout handler (actually a els, SCSI I/O, NVMe ls, or NVMe I/O timeout), in addition to aborting the I/O, perform a mailbox command and look for a response from the hardware. If the mailbox command fails, it will mark the adapter offline and then invoke the adapter reset handler to clean up. The new I/O timeout test will be limited to a test every 5s. If there are multiple I/O timeouts concurrently, only the 1st I/O timeout will generate the mailbox command. Further testing will only occur once a timeout occurs after a 5s delay from the last mailbox command has expired. Link: https://lore.kernel.org/r/20210104180240.46824-14-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
When lpfc is running in NVMET mode and supports the NVME-1 addendum changes, a LIP on a bound NVME Initiator or lipping the lpfc NVMET's link resulted in an Oops in lpfc_nvmet_host_release. The fix requires lpfc NVMET to maintain an additional reference on any node structure that acts as the hosthandle for the NVMET transport. This reference get is a one-time addition, is taken prior to the upcall of an unsolicited LS_REQ, and is released when the NVMET transport releases the hosthandle during the host_release downcall. Link: https://lore.kernel.org/r/20210104180240.46824-13-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
When with testing with large numbers of npiv vports and link bounces, the driver is flooding the messages file, even with log_verbose = 0. The new LOG_TRACE_EVENT messages are still generating events to the messages files. Fix by converting the vport create msg from LOG_TRACE_EVENT to LOG_VPORT. Link: https://lore.kernel.org/r/20210104180240.46824-12-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
If a mailbox command times out, the SLI port is deemed in error and the port is reset. The HBA cleanup is not returning I/Os to the NVMe layer before the port is unregistered. This is due to the HBA being marked offline (!SLI_ACTIVE) and cleanup being done by the mailbox timeout handler rather than an general adapter reset routine. The mailbox timeout handler mailbox handler only cleaned up SCSI I/Os. Fix by reworking the mailbox handler to: - After handling the mailbox error, detect the board is already in failure (may be due to another error), and leave cleanup to the other handler. - If the mailbox command timeout is initial detector of the port error, continue with the board cleanup and marking the adapter offline (!SLI_ACTIVE). Remove the SCSI-only I/O cleanup routine. The generic reset adapter routine that is subsequently invoked, will clean up the I/Os. - Have the reset adapter routine flush all NVMe and SCSI I/Os if the adapter has been marked failed (!SLI_ACTIVE). - Rework the NVMe I/O terminate routine to take a status code to fail the I/O with and update so that cleaned up I/O calls the wqe completion routine. Currently it is bypassing the wqe cleanup and calling the NVMe I/O completion directly. The wqe completion routine will take care of data structure and node cleanup then call the NVMe I/O completion handler. Link: https://lore.kernel.org/r/20210104180240.46824-11-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
Target reset is failed by the target as an invalid command. The Target Reset TMF has been obsoleted in T10 for a while, but continues to be used. On (newer) devices, the TMF is rejected causing the reset handler to escalate to adapter resets. Fix by having Target Reset TMF rejections be translated into a LOGO and re-PLOGI with the target device. This provides the same semantic action (although, if the device also supports nvme traffic, it will terminate nvme traffic as well - but it's still recoverable). Link: https://lore.kernel.org/r/20210104180240.46824-10-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
A successful task mgmt command is logging errors, making it look like problems were encountered. This is due to log messages for the device/target and bus reset handlers having the LOG_TRACE_EVENT flag set. Fix by adjusting the event flag such that the call to the logging routine only receives a LOG_TRACE_EVENT if a prior call actually failed. Link: https://lore.kernel.org/r/20210104180240.46824-9-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
In the lpfc offline routine, called for various reasons such as sysfs attribute, driver unload, or port error, the driver is calling __lpfc_cpuhp_remove() to destroy the hot plug data. If the offline routine is called while the driver is in the process of being unloaded, a request using lpfc_cpuhp_remove() is also made from lpfc_sli4_hba_unset(). The cpuhp elements are no longer valid when the second removal request is made. Fix by only calling the cpuhp removal once when the adapter is in the process of unloading. Link: https://lore.kernel.org/r/20210104180240.46824-8-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
If the port is configured for NVME and has any outstanding IOs when a FW reset is requesteed, outstanding I/Os are not properly cleaned up. This causes the fw download request to fail. Fix by clearing the LPFC_SLI_ACTIVE flag to signify the I/O must be manually flushed by the driver on port reset. Link: https://lore.kernel.org/r/20210104180240.46824-7-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
When lpfc generates a GEN_REQUEST wqe for the nvme LS (such as Create Association), the timeout is set to R_A_TOV without regard to the timeout value supplied by the nvme-fc transport. The driver should be setting the timeout to the value passed into the routine. Additionally the caller should be setting the timeout value to the value in the ls request set by the nvme transport. Instead, it unconditionally is setting it to a driver defined value. So the driver actually overrode the value twice. Fix by using the timeout provided to the routine, and for the caller, set the timeout to the ls request timeout value. Link: https://lore.kernel.org/r/20210104180240.46824-6-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
The driver's management of the fabric controller (aka pseudo-scsi initiator) node in SLI3 mode is causing this crash. The crash occurs because of a node reference imbalance that frees the fabric controller node while devloss is outstanding from the SCSI transport. This is triggered by an odd behavior where the switch reacts to a rejected RDP request with a PLOGI and nothing else, not even a LOGO. The driver ACKS the PLOGI and after successfully registering the RPI, incorrectly registers the fabric controller node because it has the NLP_FC4_FCP flag still set from the fabric controller PRLI. If a LIP is issued, the driver attempts to cleanup on Link Up and ends up executing too many puts. Fix by detecting the fabric node type and clearing out the nodes internal flags that triggered a SCSI transport registration and subsequence dev_loss event. The driver cannot count on any persistence from fabric controller nodes. Link: https://lore.kernel.org/r/20210104180240.46824-5-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
Testing with target ports coming and going, the driver eventually reached a state where it no longer discovered the target. When the driver has issued a PRLI and receives a PRLI from the target, it is not properly updating the node's initiator/target role flags. Thus, when a subsequent RSCN is received for a target loss, the driver mis-identifies the target as an initiator and does not initiate LUN scanning. Fix by always refreshing the ndlp with the latest PRLI state information whenever a PRLI is processed. Also clear the ndlp flags when processing a PLOGI so that there is no carry over through a re-login. Link: https://lore.kernel.org/r/20210104180240.46824-4-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
A very long time ago, there was a feature: auto sli mode. It gave the user the ability to auto select the SLI mode (SLI2 or SLI3) to run the port in, or even force SLI2 mode if configured. Because of the convoluted logic, the CONFIG_PORT mbox command ends up being called 2 or 3 times. It should have been called only once. Additionally, the driver no longer supports SLI-2, so only SLI-3 mode should be allowed. The following changes were made: - Force module parameter to SLI3 only. - Rip out redundant CONFIG_PORT mbox commands. - Force CONFIG_PORT mbox command to be in beginning of enable ISR routine. - Added changes for offline to online behavior Link: https://lore.kernel.org/r/20210104180240.46824-3-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
Under some pt2pt situations, the other end of the link may issue a LOGO after successfully completing PLOGI and assigning addresses to the port. Thus the driver may attempt a new PLOGI to re-create the login, but the LOGO handling cleared the address back to 0. Once this happens, the other end, which may be address 0, gets all confused and this cannot be resolved without an administrative action to bounce the link. Fix by assuming that address assignment only occurs on the 1st PLOGI after link up, and regardless of login state, the address assignment sticks. The FC standards aren't particularly clear in this situation (it only describes initial PLOGI), but there is nothing that contradicts this and behaviors on the devices tested appears to conform to the understanding. Thus, don't reset the port address to 0 as part of LOGO handling. Port addresses will only reset on link down. Link: https://lore.kernel.org/r/20210104180240.46824-2-jsmart2021@gmail.comCo-developed-by:
-
John Garry authored
Now that the driver always uses managed interrupts, delete auto_affine_msi_experimental module param. Link: https://lore.kernel.org/r/1609763622-34119-2-git-send-email-john.garry@huawei.comSigned-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Bean Huo authored
sprintf and snprintf may cause output defect in sysfs content, it is better to use new added sysfs_emit function which knows the size of the temporary buffer. Link: https://lore.kernel.org/r/20210106211541.23039-1-huobean@gmail.comSuggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
-
Randy Dunlap authored
Use consistent and expected indentation for all Kconfig text. Link: https://lore.kernel.org/r/20210106205554.18082-1-rdunlap@infradead.org Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: Avri Altman <avri.altman@wdc.com> Cc: linux-scsi@vger.kernel.org Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Reviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Tyrel Datwyler authored
The driver's queuecommand routine is still wrapped to hold the host lock for the duration of the call. This will become problematic when moving to multiple queues due to the lock contention preventing asynchronous submissions to mulitple queues. There is no real legitimate reason to hold the host lock, and previous patches have insured proper protection of moving ibmvfc_event objects between free and sent lists. Link: https://lore.kernel.org/r/20210106201835.1053593-6-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
Drain the command queue and place all commands on a completion list. Perform command completion on that list outside the host/queue locks. Further, move purged command compeletions outside the host_lock as well. Link: https://lore.kernel.org/r/20210106201835.1053593-5-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
Define per-queue locks for protecting queue state and event pool sent/free lists. The evt list lock is initially redundant but it allows the driver to be modified in the follow-up patches to relax the queue locking around submissions and completions. Link: https://lore.kernel.org/r/20210106201835.1053593-4-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
There is currently a single command event pool per host. In anticipation of providing multiple queues add a per-queue event pool definition and reimplement the existing CRQ to use its queue defined event pool for command submission and completion. Link: https://lore.kernel.org/r/20210106201835.1053593-3-tyreld@linux.ibm.comReviewed-by:
-
Tyrel Datwyler authored
The primary and async CRQs are nearly identical outside of the format and length of each message entry in the dma mapped page that represents the queue data. These queues can be represented with a generic queue structure that uses a union to differentiate between message format of the mapped page. This structure will further be leveraged in a followup patcheset that introduces Sub-CRQs. Link: https://lore.kernel.org/r/20210106201835.1053593-2-tyreld@linux.ibm.comReviewed-by:
-
Bean Huo authored
Transaction Specific Fields (TSF) in the UPIU package could be CDB (SCSI/UFS Command Descriptor Block), OSF (Opcode Specific Field), and TM I/O parameter (Task Management Input/Output Parameter). But, currently, we take all of these as CDB in the UPIU trace. Thus makes user confuse among CDB, OSF, and TM message. So fix it with this patch. Link: https://lore.kernel.org/r/20210105113446.16027-7-huobean@gmail.comAcked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Bean Huo authored
Distinguish between TM request UPIU and response UPIU in TM UPIU trace, for the TM response, let TM UPIU trace print its TM response UPIU. Link: https://lore.kernel.org/r/20210105113446.16027-6-huobean@gmail.comAcked-by:
-
Bean Huo authored
Currently, in the query completion trace print, since we use hba->lrb[tag].ucd_req_ptr and didn't differentiate UPIU between request and response, thus header and transaction-specific field in UPIU printed by query trace are identical. This is not very practical. As below: query_send: HDR:16 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00 00 00 00 00 00 00 00 00 00 query_complete: HDR:16 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00 00 00 00 00 00 00 00 00 00 For the failure analysis, we want to understand the real response reported by the UFS device, however, the current query trace tells us nothing. After this patch, the query trace on the query_send, and the above a pair of query_send and query_complete will be: query_send: HDR:16 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00 00 00 00 00 00 00 00 00 00 ufshcd_upiu: HDR:36 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00 00 00 00 00 01 00 00 00 00 Link: https://lore.kernel.org/r/20210105113446.16027-5-huobean@gmail.comAcked-by:
-
