Justin Tee <justintee8345@gmail.com> says:
Update lpfc to revision 14.4.0.7
This patch set contains fixes related to smatch, clean up of obsolete code
and global spinlocks, changes to ADISC and LS_RJT handling, and support for
large fw object reads used in proprietary applications.
The patches were cut against Martin's 6.14/scsi-queue tree.
Link: https://lore.kernel.org/r/20241212233309.71356-1-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Current lpfc bsg implementation allows a maximum fw read object size of
30KB. Implementation and support for read object mailbox commands for fw
objects larger than 30KB are now required for proprietary applications.
Thus, update the lpfc_sli_config_emb0_subsys structure and its associated
submission and completion paths to accommodate for an alternative form of
read object command that supports large fw objects.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241212233309.71356-9-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When a LS_RJT is received with reason explanation authentication required,
current driver logic is to retry the PLOGI up to 48 times. In the worse
case scenario, 48 retries can take longer than dev_loss_tmo and if there is
an RSCN received indicating an authentication requirement change, the
driver may miss processing it. Fix by adding logic to specifically handle
reason explanation authentication required and set the max retry count to 8
times.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241212233309.71356-6-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In lpfc_check_adisc, remove the requirement that the ndlp object must have
been RPI registered. Whether or not the ndlp is RPI registered is
unrelated to verifying that the received ADISC is intended for that ndlp
rport object.
After ADISC receipt, there's no need to put the ndlp state into NPR. Let
the cmpl routines from the actions taken earlier in ADISC handling set the
proper ndlp state.
Also, refactor when a RESUME_RPI mailbox command should be sent. It should
only be sent if the RPI registered flag is set.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241212233309.71356-5-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Remove the NLP_TARGET_REMOVE flag as its usage is obsolete. The current
framework is to rely on the lpfc_dev_loss_tmo_callbk from upper layer to
notify final ndlp kref release. There's no need to specifically set
NLP_EVT_DEVICE_RM when a LOGO completes. The dev_loss_tmo_callbk is
responsible for the final kref put.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20241212233309.71356-4-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Linux 5.15 logs the error below
mpt3sas_cm0: overriding NVDATA EEDPTagMode setting
on a Dell PowerEdge T440 with the card below.
5e:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097] (rev 02)
It’s not clear to a user what this error is about. As a first step to
improve this, add the values to the error message.
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20241212221817.78940-1-pmenzel@molgen.mpg.de
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
By default the UFS core is responsible for initializing the
blk_crypto_profile, but Qualcomm platforms have their own way of
programming and evicting crypto keys. So currently
ufs_hba_variant_ops::program_key is used to redirect control flow from
ufshcd_program_key(). This has worked until now, but it's a bit of a hack,
given that the key (and algorithm ID etc.) ends up being converted from
blk_crypto_key => ufs_crypto_cfg_entry => SCM call parameters, where the
intermediate ufs_crypto_cfg_entry step is unnecessary. Taking a similar
approach with the upcoming wrapped key support, the implementation of which
is similarly platform-specific, would require adding four new methods to
ufs_hba_variant_ops, changing program_key to take the struct
blk_crypto_key, and adding a new UFSHCD_CAP_* flag to indicate support for
wrapped keys.
This patch takes a different approach. It changes ufs-qcom to use the
existing UFSHCD_QUIRK_CUSTOM_CRYPTO_PROFILE which was recently added for
ufs-exynos. This allows it to override the full blk_crypto_profile,
eliminating the need for the existing ufs_hba_variant_ops::program_key and
the hooks that would have been needed for wrapped key support. It does
require a bit of duplicated code to read the crypto capability registers,
but it's worth the simplification in design with ufs-qcom and ufs-exynos
now using the same method to customize the crypto profile, and it makes it
much easier to add wrapped key support.
Tested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> # sm8650
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20241213041958.202565-4-ebiggers@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The functions:
iscsit_check_unsolicited_dataout()
iscsit_fail_session()
iscsit_create_conn_recovery_datain_values()
iscsit_create_conn_recovery_dataout_values()
iscsit_tpg_dump_params()
iscsit_print_session_params()
were all added in 2011 by commit e48354ce07 ("iscsi-target: Add iSCSI
fabric support for target v4.1") but have remained unused.
Remove them.
Having deleted them, the functions:
iscsi_print_params()
iscsi_dump_conn_ops()
iscsi_dump_sess_ops()
are also unused.
Remove them.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20241222213524.270735-1-linux@treblig.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Current code allocates the stor_chns array with size num_possible_cpus().
This code assumes cpu_possible_mask is dense, which is not true in the
general case per [1]. If cpu_possible_mask is sparse, the array might be
indexed by a value beyond the size of the array.
However, the configurations that Hyper-V provides to guest VMs on x86 and
ARM64 hardware, in combination with how architecture specific code assigns
Linux CPU numbers, *does* always produce a dense cpu_possible_mask. So the
dense assumption is not currently causing failures. But for robustness
against future changes in how cpu_possible_mask is populated, update the
code to no longer assume dense.
The correct approach is to allocate and initialize the array using size
"nr_cpu_ids". While this leaves unused array entries corresponding to holes
in cpu_possible_mask, the holes are assumed to be minimal and hence the
amount of memory wasted by unused entries is minimal.
[1] https://lore.kernel.org/lkml/SN6PR02MB4157210CC36B2593F8572E5ED4692@SN6PR02MB4157.namprd02.prod.outlook.com/
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/20241003035333.49261-5-mhklinux@outlook.com
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bart Van Assche <bvanassche@acm.org> says:
Hi Martin,
The text "slave_" in multiple function names does not make it clear what
the purpose of these functions is. Hence this patch series that renames all
SCSI functions that have the word "slave" in their function name. Please
consider this patch series for the next merge window.
Thanks,
Bart.
Link: https://lore.kernel.org/r/20241022180839.2712439-1-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
