bfa has a set of structure parsers, of which quite a few are unused.
Remove the unused set.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20241117135215.38771-3-linux@treblig.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
bfa has a large set of structure builders, of which only about 60% are
used; remove the rest.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20241117135215.38771-2-linux@treblig.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Fix the hardware revision numbering for Qlogic ISP1020/1040 boards. HWMASK
suggests that the revision number only needs four bits, this is consistent
with how NetBSD does things in their ISP driver. Verified on a IPS1040B
which is seen as rev 5 not as BIT_4.
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
Link: https://lore.kernel.org/r/20241113225636.2276-1-linmag7@gmail.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Kai Mäkisara <Kai.Makisara@kolumbus.fi> says:
These three patches were developed in response to Bugzilla report
https://bugzilla.kernel.org/show_bug.cgi?id=219419
After device reset, the tape driver allows only operations that don't
write or read anything from tape. The reason for this is that many
(most ?) drives rewind the tape after reset and the subsequent reads
or writes would not be at the tape location the user expects. Reading
and writing is allowed again when the user does something to position the
tape (e.g., rewind).
The Bugzilla report considers the case when a user, after reset, tries
to read the drive status with MTIOCGET ioctl, but it fails. MTIOCGET
does not return much useful data after reset, but it can be allowed.
MTLOAD positions the tape and it should be allowed. The second patch
adds these to the set of allowed operations after device reset.
The first patch fixes a bug seen when developing the second patch.
V2: The third patch is added to fix a bug that resulted in not
blocking writes if reset occurs while the device file is not open.
Link: https://lore.kernel.org/r/20241106095723.63254-1-Kai.Makisara@kolumbus.fi
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently the code starts new tape session when any Unit Attention
(UA) is seen when opening the device. This leads to incorrectly
clearing pos_unknown when the UA is for reset. Set new session only
when the UA is for a new tape.
Signed-off-by: Kai Mäkisara <Kai.Makisara@kolumbus.fi>
Link: https://lore.kernel.org/r/20241106095723.63254-4-Kai.Makisara@kolumbus.fi
Reviewed-by: John Meneghini <jmeneghi@redhat.com>
Tested-by: John Meneghini <jmeneghi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Most drives rewind the tape when the device is reset. Reading and writing
are not allowed until something is done to make the tape position match the
user's expectation (e.g., rewind the tape). Add MTIOCGET and MTLOAD to
operations allowed after reset. MTIOCGET is modified to not touch the tape
if pos_unknown is non-zero. The tape location is known after MTLOAD.
Signed-off-by: Kai Mäkisara <Kai.Makisara@kolumbus.fi>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219419#c14
Link: https://lore.kernel.org/r/20241106095723.63254-3-Kai.Makisara@kolumbus.fi
Reviewed-by: John Meneghini <jmeneghi@redhat.com>
Tested-by: John Meneghini <jmeneghi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
As described in the added code comment, a reference to .exit.text is ok
for drivers registered via module_platform_driver_probe(). Make this
explicit to prevent the following section mismatch warnings
WARNING: modpost: drivers/scsi/sun3_scsi: section mismatch in reference: sun3_scsi_driver+0x4 (section: .data) -> sun3_scsi_remove (section: .exit.text)
WARNING: modpost: drivers/scsi/sun3_scsi_vme: section mismatch in reference: sun3_scsi_driver+0x4 (section: .data) -> sun3_scsi_remove (section: .exit.text)
that trigger on a Sun 3 allmodconfig build.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/b2c56fa3556505befe9b4cb9a830d9e2a962e72c.1730831769.git.geert@linux-m68k.org
Acked-by: Finn Thain <fthain@linux-m68k.org>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In 2010, runtime power management support was implemented in the SCSI
core. The description of patch "[SCSI] implement runtime Power
Management" mentions that the sg driver is skipped but not why. This
patch enables runtime power management even if an instance of the sg
driver is held open. Enabling runtime PM for the sg driver is safe
because all interactions of the sg driver with the SCSI device pass
through the block layer (blk_execute_rq_nowait()) and the block layer
already supports runtime PM.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Douglas Gilbert <dgilbert@interlog.com>
Fixes: bc4f24014d ("[SCSI] implement runtime Power Management")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20241030220310.1373569-1-bvanassche@acm.org
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMA
memory sb_virt when it fails. Add dma_free_coherent() to free it. This
is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Fixes: ace7f46ba5 ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.")
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20241026125711.484-3-thunder.leizhen@huawei.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMA
memory sb_virt when it fails. Add dma_free_coherent() to free it. This
is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Fixes: 61d8658b4a ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.")
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20241026125711.484-2-thunder.leizhen@huawei.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
esas2r_build_cli_req() has been unused since it was added in 2013 by
commit 26780d9e12 ("[SCSI] esas2r: ATTO Technology ExpressSAS 6G
SAS/SATA RAID Adapter Driver")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20241102220336.80541-1-linux@treblig.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/scsi to use .remove(), with
the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.
On the way do a few whitespace changes to make indention consistent.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20241028080754.429191-2-u.kleine-koenig@baylibre.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Increasing the per-request size maximum to 4MiB (8192 sectors x 512
bytes) runs into the per-device DMA scatter gather list limit
(max_segments) for users of the io vector system calls (e.g. readv and
writev).
Increase the max scatter gather list length to 1024 to enable kernel to
send 4MiB (1024 * 4KiB page size) requests.
Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
Link: https://lore.kernel.org/r/20241025185009.3278297-1-ipylypiv@google.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Devices can be allocated and freed at runtime. For example during a soft
reset all devices are freed and reallocated upon discovery.
Currently the driver fully initializes devices once in pm8001_alloc().
Allows initialization steps to happen during runtime, avoiding any
leftover states from the device being freed.
Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
Signed-off-by: Terrence Adams <tadamsjr@google.com>
Link: https://lore.kernel.org/r/20241021201828.1378858-1-tadamsjr@google.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The pm8001 driver sets pcs event log threshold very high which causes
most of the FW log messages to not be captured. Add a module parameter
to configure pcs event log severity with 3 (medium severity) as the
default.
Co-developed-by: Bhavesh Jashnani <bjashnani@google.com>
Signed-off-by: Bhavesh Jashnani <bjashnani@google.com>
Signed-off-by: Salomon Dushimirimana <salomondush@google.com>
Link: https://lore.kernel.org/r/20241016220944.370539-1-salomondush@google.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Justin Tee <justintee8345@gmail.com> says:
Update lpfc to revision 14.4.0.6
This patch set contains bug fixes related to congestion handling,
accounting for internal remoteport objects, resource release during
HBA unload and reset, and clean up regarding the abuse of a global
spinlock.
The patches were cut against Martin's 6.13/scsi-queue tree.
Link: https://lore.kernel.org/r/20241031223219.152342-1-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In attempt to reduce the amount of unnecessary ndlp->lock acquisitions
in the lpfc driver, change nlpa_flag into an unsigned long bitmask and
use clear_bit/test_bit bitwise atomic APIs instead of reliance on
ndlp->lock for synchronization.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241031223219.152342-10-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
An RPI is tightly bound to an NDLP structure and is freed only upon
release of an NDLP object. As such, there should be no logic that frees
an RPI outside of the lpfc_nlp_release() routine. In order to reinforce
the original design usage of RPIs, remove the NLP_RELEASE_RPI flag and
related logic.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241031223219.152342-9-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Current dev_loss_tmo handling checks whether there has been a previous
call to unregister with SCSI transport. If so, the NDLP kref count is
decremented a second time in dev_loss_tmo as the final kref release.
However, this can sometimes result in a reference count underflow if
there is also a race to unregister with NVMe transport as well. Add a
check for NVMe transport registration before decrementing the final
kref. If NVMe transport is still registered, then the NVMe transport
unregistration is designated as the final kref decrement.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241031223219.152342-8-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
An HBA reset request that is executed when there are outstanding NVME-LS
commands can cause delays for the reset process to complete. Fix by
introducing a new routine called lpfc_nvmels_flush_cmd() that walks the
phba->nvmels_wq list and cancels outstanding submitted NVME-LS requests
speeding up the HBA reset process.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241031223219.152342-7-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The lpfc_cmpl_ct_disc_fdmi() routine has incorrect logic that treats an
FDMI completion with error LOCAL_REJECT/SLI_ABORTED as a success status.
Under the erroneous assumption of successful completion, the routine
proceeds to issue follow up FDMI commands, which may never complete if
the HBA is in an errata state as indicated by the errored completion
status. Fix by freeing FDMI cmd resources and early return when the
LPFC_SLI_ACTIVE flag is not set and a LOCAL_REJECT/SLI_ABORTED or
SLI_DOWN status is received.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241031223219.152342-6-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
During firmware errata events, the lpfc_els_flush_cmd() routine is
responsible for the clean up of outstanding ELS and CT command
submissions. Thus, move the LPFC_SLI_ACTIVE flag check into the txcmplq
list walk and mark a piocb object for canceling if determined the HBA is
not active. Clean up should be regardless of application or driver
layer origin.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241031223219.152342-5-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
During initialization, the driver allocates wq->pring in lpfc_wq_create
and lpfc_sli4_queue_unset() is the only place where kfree(wq->pring) is
called.
There is a possible memory leak in lpfc_sli_brdrestart_s4() (restart)
and lpfc_pci_remove_one_s4() (rmmod) paths because there are no calls to
lpfc_sli4_queue_unset() to kfree() the wq->pring.
Fix by inserting a call to lpfc_sli4_queue_unset() in
lpfc_sli_brdrestart_s4() and lpfc_sli4_hba_unset() routines. Also, add
a check for the SLI_ACTIVE flag before issuing the Q_DESTROY mailbox
command. If not set, then the mailbox command will obviously fail. In
such cases, skip issuing the mailbox command and only execute the driver
resource clean up portions of the lpfc_*q_destroy routines.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241031223219.152342-4-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Should an rport remain in the NOTPRESENT state it is possible that
stgt_delete_work is scheduled after dev_loss_tmo_callbk. In such cases,
dev_loss_tmo_callbk would have cleaned up the NDLP object resulting in
stale ndlp pointers in lpfc_terminate_rport_io().
Check for the DEVLOSS_CALLBK_DONE flag to know if dev_loss_tmo_callbk
has been called. This is a more reliable way to avoid dereferencing
stale NDLP pointers.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241031223219.152342-3-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
CGN warning signals are currently statically fixed to a passed in driver
parameter called lpfc_fabric_cgn_frequency. However, CGN frequency
should be more correctly based on EDC responses from the fabric when
available. Otherwise, still allow the driver to fall back on user
configured lpfc_fabric_cgn_frequency driver parameter.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241031223219.152342-2-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
We have two reports of failed memory allocation in btrfs' code which is
calling into report zones.
Both of these reports have the following signature coming from
__vmalloc_area_node():
kworker/u17:5: vmalloc error: size 0, failed to allocate pages, mode:0x10dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NORETRY|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0
Further debugging showed these where allocations of one sector (512
bytes) and at least one of the reporter's systems where low on memory,
so going through the overhead of allocating a vm area failed.
Switching the allocation from __vmalloc() to kvzalloc() avoids the
overhead of vmalloc() on small allocations and succeeds.
Note: the buffer is already freed using kvfree() so there's no need to
adjust the free path.
Cc: Qu Wenru <wqu@suse.com>
Cc: Naohiro Aota <naohiro.aota@wdc.com>
Link: https://github.com/kdave/btrfs-progs/issues/779
Link: https://github.com/kdave/btrfs-progs/issues/915
Fixes: 23a50861ad ("scsi: sd_zbc: Cleanup sd_zbc_alloc_report_buffer()")
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Link: https://lore.kernel.org/r/20241030110253.11718-1-jth@kernel.org
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If the sg_copy_buffer() call returns less than sdebug_sector_size, then
we drop out of the copy loop. However, we still report that we copied
the full expected amount, which is not proper.
Fix by keeping a running total and return that value.
Fixes: 84f3a3c01d ("scsi: scsi_debug: Atomic write support")
Reported-by: Colin Ian King <colin.i.king@gmail.com>
Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://lore.kernel.org/r/20241018101655.4207-1-john.g.garry@oracle.com
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Yihang Li <liyihang9@huawei.com> says:
This series contains some fixes including:
- Adjust priority of registering and exiting debugfs for security;
- Create trigger_dump at the end of the debugfs initialization;
- Add firmware information check;
- Enable all PHYs that are not disabled by user during controller reset;
- Reset PHY again if phyup timeout;
- Check usage count only when the runtime PM status is RPM_SUSPENDING;
- Add cond_resched() for no forced preemption model;
- Default enable interrupt coalescing;
- Update disk locked timeout to 7 seconds;
- Add time interval between two H2D FIS following soft reset spec;
- Update v3 hw STP_LINK_TIMER setting;
- Create all dump files during debugfs initialization;
- Add latest_dump for the debugfs dump;
Link: https://lore.kernel.org/r/20241008021822.2617339-1-liyihang9@huawei.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Before that, after the user triggers the dump, the latest dump
information can be viewed in the directory with the maximum number in
the dump directory.
After this series patch, the driver creates all debugfs directories and
files during initialization. Therefore, users cannot know the directory
where the latest dump information is stored. So, add latest_dump file to
notify users where the latest dump information is stored.
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-14-liyihang9@huawei.com
Reviewed-by: Xingui Yang <yangxingui@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
At present, it is found that some SATA HDD disks may continue to return
the HOLD primitive for more than 500ms when they are busy writing data,
which is more likely to trigger an STP link timeout exception. Now
Modify STP link timer from 500ms to the maximum value of 1.048575s.
Signed-off-by: Xingui Yang <yangxingui@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-12-liyihang9@huawei.com
Reviewed-by: Yihang Li <liyihang9@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Spec says at least 5us between two H2D FIS when do soft reset, but be
generous and sleep for about 1ms.
Signed-off-by: Xingui Yang <yangxingui@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-11-liyihang9@huawei.com
Reviewed-by: Yihang Li <liyihang9@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The SATA disk will be locked after the disk sends the DMA Setup frame
until all data frame transmission is completed. The
CFG_ICT_TIMER_STEP_TRSH register is used for sata disk to configure the
step size of the timer which records the time when the disk is
locked. The unit is 1us and the default step size is 150ms. If the disk
is locked for more than 7 timer steps, the io to be sent to the disk
will end abnormally.
The current timeout is only about 1 second, it is easy to trigger IO
abnormal end when the SATA hard disk returns data slowly. Adjust the
timeout to 7 seconds based on ERC time of most disks.
Signed-off-by: Xingui Yang <yangxingui@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-10-liyihang9@huawei.com
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Reviewed-by: Yihang Li <liyihang9@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In the current interrupt reporting mode, each CQ entry reports an
interrupt. However, when there are a large number of I/O hardware
completion interrupts, the following issue may occur:
[ 4682.678657][ C129] irq 134: nobody cared (try booting with the "irqpoll" option)
[ 4682.708455][ C129] Call trace:
[ 4682.711589][ C129] dump_backtrace+0x0/0x1e4
[ 4682.715934][ C129] show_stack+0x20/0x2c
[ 4682.719933][ C129] dump_stack+0xd8/0x140
[ 4682.724017][ C129] __report_bad_irq+0x54/0x180
[ 4682.728625][ C129] note_interrupt+0x1ec/0x2f0
[ 4682.733143][ C129] handle_irq_event+0x118/0x1ac
[ 4682.737834][ C129] handle_fasteoi_irq+0xc8/0x200
[ 4682.742613][ C129] __handle_domain_irq+0x84/0xf0
[ 4682.747391][ C129] gic_handle_irq+0x88/0x2c0
[ 4682.751822][ C129] el1_irq+0xbc/0x140
[ 4682.755648][ C129] _find_next_bit.constprop.0+0x20/0x94
[ 4682.761036][ C129] cpumask_next+0x24/0x30
[ 4682.765208][ C129] gic_ipi_send_mask+0x48/0x170
[ 4682.769900][ C129] __ipi_send_mask+0x34/0x110
[ 4682.775720][ C129] smp_cross_call+0x3c/0xcc
[ 4682.780064][ C129] arch_send_call_function_single_ipi+0x38/0x44
[ 4682.786146][ C129] send_call_function_single_ipi+0xd0/0xe0
[ 4682.791794][ C129] generic_exec_single+0xb4/0x170
[ 4682.796659][ C129] smp_call_function_single_async+0x2c/0x40
[ 4682.802395][ C129] blk_mq_complete_request_remote.part.0+0xec/0x100
[ 4682.808822][ C129] blk_mq_complete_request+0x30/0x70
[ 4682.813950][ C129] scsi_mq_done+0x48/0xac
[ 4682.818128][ C129] sas_scsi_task_done+0xb0/0x150 [libsas]
[ 4682.823692][ C129] slot_complete_v3_hw+0x230/0x710 [hisi_sas_v3_hw]
[ 4682.830120][ C129] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw]
[ 4682.836114][ C129] irq_thread_fn+0x34/0xa4
[ 4682.840371][ C129] irq_thread+0xc4/0x130
[ 4682.844455][ C129] kthread+0x108/0x13c
[ 4682.848365][ C129] ret_from_fork+0x10/0x18
[ 4682.852621][ C129] handlers:
[ 4682.855577][ C129] [<00000000949e52bf>] cq_interrupt_v3_hw [hisi_sas_v3_hw] threaded [<000000005d8e3b68>] cq_thread_v3_hw [hisi_sas_v3_hw]
[ 4682.868084][ C129] Disabling IRQ #134
When the IRQ management layer processes each hardware interrupt, if the
return value of the interrupt handler is IRQ_WAKE_THREAD, it will wake
up the handler thread for this interrupt action and set IRQTF_RUNTHREAD
flag, wait for the interrupt handling thread to clear the
IRQTF_RUNTHREAD flag after execution. Later in note_interrupt(), use
irq_count to count hardware interrupts and irqs_unhandled to count
interrupts for which no thread handler is responsible. When irq_count
reaches 100000 and irqs_unhandled reaches 99000, irq will be disabled.
In the performance test scenario, I/O completion hardware interrupts are
continuously and quickly generated. As a result, the interrupt
processing thread is cyclically called in irq_thread() and does not
exit, this affects the response of the interrupt thread to the hardware
interrupt and causes irqs_unhandled to grow to 99000. Finally, the irq
is disabled.
Therefore, default enable interrupt coalescing to reduce the generation
of hardware interrupts, this helps interrupt processing threads to stop
calling in irq_thread().
For interrupt coalescing, according to the actual performance test, set
the count of CQ entries to 10 and the interrupt coalescing timeout
period to 10us based on the actual performance test.
Before and after interrupt coalescing is enabled, the 4K read/write
performance is improved by about 3%, and the 256K read/write performance
is basically the same.
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-9-liyihang9@huawei.com
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Users can suspend the machine with 'echo disk > /sys/power/state', but
the suspend will fail because the SAS controller cannot be suspended:
[root@localhost ~]# echo freeze > /sys/power/state
-bash: echo: write error: Device or resource busy
[15104.142955] PM: suspend entry (s2idle)
...
[15104.283465] hisi_sas_v3_hw 0000:32:04.0: entering suspend state
[15104.283480] hisi_sas_v3_hw 0000:30:04.0: entering suspend state
[15104.283500] hisi_sas_v3_hw 0000:32:04.0: PM suspend: host status cannot be suspended
[15104.283508] hisi_sas_v3_hw 0000:30:04.0: PM suspend: host status cannot be suspended
[15104.283516] hisi_sas_v3_hw 0000:32:04.0: PM: pci_pm_suspend(): suspend_v3_hw+0x0/0x210 [hisi_sas_v3_hw] returns -16
[15104.283527] hisi_sas_v3_hw 0000:32:04.0: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x1c0 returns -16
[15104.283524] hisi_sas_v3_hw 0000:30:04.0: PM: pci_pm_suspend(): suspend_v3_hw+0x0/0x210 [hisi_sas_v3_hw] returns -16
[15104.283533] hisi_sas_v3_hw 0000:32:04.0: PM: failed to suspend async: error -16
[15104.283536] hisi_sas_v3_hw 0000:30:04.0: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x1c0 returns -16
[15104.283542] hisi_sas_v3_hw 0000:30:04.0: PM: failed to suspend async: error -16
The problem is that when the ->runtime_suspend() callback
suspend_v3_hw() is executing, the current runtime PM status is
RPM_ACTIVE and the usage count of the controller is not 0, so return
immediately.
To fix it, Check the device usage count only when the runtime PM status
is RPM_SUSPENDING.
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-7-liyihang9@huawei.com
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In commit 89954f024c ("scsi: hisi_sas: Ensure all enabled PHYs up
during controller reset"), we enable PHYs in parallel through async
operations and wait for PHYs come up. However, for some directly
attached SATA disks, the PHY not come up after a timeout period and the
hardware is not ready. At this time, we should get the latest PHY
hardware state, if the new PHY state is not ready but the old PHY state
is ready, call work HISI_PHYE_LINK_RESET to give it another chance to
phyup.
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-6-liyihang9@huawei.com
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
For the controller reset operation(such as FLR or clear nexus ha in SCSI
EH), we will disable all PHYs and then enable PHY based on the
hisi_hba->phy_state obtained in hisi_sas_controller_reset_prepare(). If
the device is removed before controller reset or the PHY is not attached
to any device in directly attached scenario, the corresponding bit of
phy_state is not set. After controller reset done, the PHY is disabled.
The device cannot be identified even if user reconnect the disk.
Therefore, for PHYs that are not disabled by user, hisi_sas_phy_enable()
needs to be executed even if the corresponding bit of phy_state is not
set.
Fixes: 89954f024c ("scsi: hisi_sas: Ensure all enabled PHYs up during controller reset")
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-5-liyihang9@huawei.com
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
For security purposes, after information is obtained through the FW,
check information to ensure data correctness.
- In v1 and v2 hw, the maximum number of PHYs is 9, while in v3 it is 8.
- In v2 and v3 hw, the maximum number of hardware queues is 16, while
in v1 it is 32.
Also add some debug logs for failure.
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-4-liyihang9@huawei.com
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In the current debugfs initialization process, the interface
trigger_dump is created first, and then the dump directory is created to
store the register dump information.
The issue is that after the trigger_dump interface is created, users can
access the interface to trigger dump and call
debugfs_create_files_v3_hw(). In debugfs_create_files_v3_hw(), if
.debugfs_dump_dentry is NULL, the file for storing dump information is
created under /sys/kernel/debug, and the memory and information cannot
be released after the driver is uninstalled.
Therefore, the creation of the trigger_dump interface is placed at the
end of debugfs initialization.
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-3-liyihang9@huawei.com
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
To be safe, we should register debugfs at the last stage of driver
initialization and then unregister debugfs at the first stage of driver
uninstallation.
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Link: https://lore.kernel.org/r/20241008021822.2617339-2-liyihang9@huawei.com
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
A sanity check on phy_mask was added in commit 3668651def ("scsi:
mpi3mr: Sanitise num_phys"). This causes warning messages when more than
64 phys are detected and devices connected to phys greater than 64 are
dropped.
The phy_mask bitmap is only needed for controller phys and not required
for expander phys. Controller phys can go up to a maximum of 64 and
therefore u64 is good enough to contain phy_mask bitmap.
To suppress those warnings and allow devices to be discovered as before
the offending commit, restrict the phy_mask setting and lowest phy
setting only to the controller phys.
Fixes: 3668651def ("scsi: mpi3mr: Sanitise num_phys")
Cc: stable@vger.kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202410051943.Mp9o5DlF-lkp@intel.com/
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
Link: https://lore.kernel.org/r/20241008074353.200379-1-ranjan.kumar@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
linux@treblig.org says:
Hi,
This removes a pile of dead functions in the SCSI bfa driver.
These were spotted by hunting for unused symbols in a unmodular
kernel build, and then double checking by grepping for the function
name.
It's been build tested only, I don't have the hardware, but
it's strictly full function (and the occasional struct) deletion,
so there should be no change in functionality.
Thanks to David Hildenbrand for the suggestion of hunting
for unused symbols.
Dave
Link: https://lore.kernel.org/r/20240915125633.25036-1-linux@treblig.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
