- 15 Jan, 2021 17 commits
-
-
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:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
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:
Avri Altman <avri.altman@wdc.com> Signed-off-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 23 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:
Bean Huo <beanhuo@micron.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:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-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:
-
Bikash Hazarika authored
FW needs to wait for an ABTS response before completing the I/O. Link: https://lore.kernel.org/r/20210111093134.1206-5-njavali@marvell.comReviewed-by:
Bikash Hazarika <bhazarika@marvell.com> Signed-off-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
-
Saurav Kashyap authored
This change will aid in debugging issues arising because of dropped frame, DIF errors, queue full etc where debug level is not set. Link: https://lore.kernel.org/r/20210111093134.1206-4-njavali@marvell.comSigned-off-by:
-
Saurav Kashyap authored
Display error counters via debugfs node. Link: https://lore.kernel.org/r/20210111093134.1206-3-njavali@marvell.comReviewed-by:
-
Saurav Kashyap authored
This statistics will help in debugging process and checking specific error counts. It also provides a capability to isolate the port or bring it out of isolation. Link: https://lore.kernel.org/r/20210111093134.1206-2-njavali@marvell.comReported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
YANG LI authored
Fix the following coccicheck warning: ./drivers/scsi/qedf/qedf_main.c:3716:5-31: WARNING: Comparison to bool Link: https://lore.kernel.org/r/1610357368-62866-1-git-send-email-abaci-bugfix@linux.alibaba.comReported-by:
-
Sergey Shtylyov authored
Some comments in this driver don't comply with the preferred multi-line comment style, as reported by 'scripts/checkpatch.pl': WARNING: Block comments use * on subsequent lines WARNING: Block comments use a trailing */ on a separate line Fix those comments, along with the (unreported for some reason?) starts of the multi-line comments not being /* on their own line... Link: https://lore.kernel.org/r/08c231e5-d86f-9d0b-19ac-ad46fa0c0b58@omprussia.ruReviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by:
-
Sergey Shtylyov authored
Some source lines (mostly the comments) in this driver end with spaces, as reported by 'scripts/checkpatch.pl'. Trim these lines. Link: https://lore.kernel.org/r/59829052-4932-4ea3-b504-857bbb19e6a0@omprussia.ruReviewed-by:
-
Sergey Shtylyov authored
This driver's original authors did pretty bad job of documenting the Command Control Block (CCB) structure -- especially its 2nd byte, where the bit numbers were completely left out. Sync up the 'struct ccb' comments to the Adaptec AHA-154xA manual. Link: https://lore.kernel.org/r/17a7be14-a9d2-9822-bb3e-1d7385f486b0@omprussia.ruReviewed-by:
-
Avri Altman authored
Remove a redundant if clause in ufshcd_add_query_upiu_trace. Link: https://lore.kernel.org/r/20210110084618.189371-1-avri.altman@wdc.comReviewed-by:
-
Pavel Begunkov authored
iov_iter_bvec() initialises iterators well, no need to pre-zero it beforehand as done in fd_execute_rw_aio(). Compilers can't optimise it out and generate extra code for that (confirmed with assembly). Link: https://lore.kernel.org/r/34cd22d6cec046e3adf402accb1453cc255b9042.1610207523.git.asml.silence@gmail.comReviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Signed-off-by:
-
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:
-
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:
-
