linux-dev/drivers/scsi/elx/efct, branch master

scsi: elx: efct: Remove NULL check after calling container_of()

2022-05-20T00:16:27Z

container_of() will never return NULL. Link: https://lore.kernel.org/r/1652750737-22673-1-git-send-email-baihaowen@meizu.com Signed-off-by: Haowen Bai Signed-off-by: Martin K. Petersen

scsi: elx: efct: Remove redundant memset() statement

2022-05-20T00:16:26Z

As memset() of bmbx is immediately followed by a memcpy() where bmbx is the destination, the memset() is redundant. Link: https://lore.kernel.org/r/20220505143703.45441-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Harshit Mogalapalli Signed-off-by: Martin K. Petersen

scsi: elx: efct: Remove unnecessary memset() in efct_io()

2022-04-26T03:28:25Z

io->sgl is allocated by kzalloc(). The memory is set to zero. It is unnecessary to call memset again. Link: https://lore.kernel.org/r/20220318145230.1031-1-wanjiabing@vivo.com Signed-off-by: Wan Jiabing Signed-off-by: Martin K. Petersen

scsi: efct: Remove useless DMA-32 fallback configuration

2022-01-10T15:37:02Z

As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. While at it, return the error code returned by dma_set_mask_and_coherent() instead of -1. [1]: https://lkml.org/lkml/2021/6/7/398 Link: https://lore.kernel.org/r/958bcb2a6e86344c14f38369e8e7079615a2b0e3.1641754613.git.christophe.jaillet@wanadoo.fr Reviewed-by: Christoph Hellwig Signed-off-by: Christophe JAILLET Signed-off-by: Martin K. Petersen

scsi: efct: Don't pass GFP_DMA to dma_alloc_coherent()

2021-12-17T03:52:29Z

dma_alloc_coherent() ignores the zone specifiers so this is pointless and confusing. Link: https://lore.kernel.org/r/20211214163605.416288-1-hch@lst.de Reviewed-by: James Smart Signed-off-by: Christoph Hellwig Signed-off-by: Martin K. Petersen

Merge branch '5.15/scsi-fixes' into 5.16/scsi-staging

2021-10-12T15:58:12Z

Merge the 5.15/scsi-fixes branch into the staging tree to resolve UFS conflict reported by sfr. Signed-off-by: Martin K. Petersen

scsi: elx: efct: Delete stray unlock statement

2021-10-05T03:33:31Z

It's not holding the lock at this stage and the IRQ "flags" are not correct so it would restore something bogus. Delete the unlock statement. Link: https://lore.kernel.org/r/20211004103851.GE25015@kili Fixes: 3e6414003bf9 ("scsi: elx: efct: SCSI I/O handling routines") Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen

scsi: elx: efct: Switch from 'pci_' to 'dma_' API

2021-09-29T03:39:23Z

The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below. It has been hand modified to use 'dma_set_mask_and_coherent()' instead of 'pci_set_dma_mask()/pci_set_consistent_dma_mask()' when applicable. This is less verbose. It has been compile tested. @@ @@ - 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/3899b1ed4abac581c30845d82f33ec6df8b38976.1629633207.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET Signed-off-by: Martin K. Petersen

scsi: efct: Decrease area under spinlock

2021-09-22T04:04:56Z

Under the session level spinlock node->active_ios_lock in efct_scsi_io_alloc() we are taking another spinlock for the port. This leads to contention between sessions and even between I/Os in the same session. Reduce the locked region to active_ios list for which active_ios_lock is intended. Spinlock CPU usage decreases from 18% down to 13%. IOPS are increased from 220 kIOPS to 264 kIOPS for one LUN. Link: https://lore.kernel.org/r/20210914105539.6942-4-d.bogdanov@yadro.com Reviewed-by: Roman Bolshakov Reviewed-by: Ram Vegesna Signed-off-by: Dmitry Bogdanov Signed-off-by: Martin K. Petersen

scsi: elx: efct: Do not hold lock while calling fc_vport_terminate()

2021-09-14T02:15:46Z

Smatch checker reported the following error: drivers/base/power/sysfs.c:833 dpm_sysfs_remove() warn: sleeping in atomic context With a calling sequence of: efct_lio_npiv_drop_nport() <- disables preempt -> fc_vport_terminate() -> device_del() -> dpm_sysfs_remove() Issue is efct_lio_npiv_drop_nport() is making the fc_vport_terminate() call while holding a lock w/ ipl raised. It is unnecessary to hold the lock over this call, shift where the lock is taken. Link: https://lore.kernel.org/r/20210907165225.10821-1-jsmart2021@gmail.com Reported-by: Dan Carpenter Co-developed-by: Ram Vegesna Signed-off-by: Ram Vegesna Signed-off-by: James Smart Signed-off-by: Martin K. Petersen