Re: [PATCH v4 02/13] scsi: fnic: Use fnic_num for non-SCSI identifiers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Unconditionally using `fnic->fnic_num` instead of `host_no` in `fnic_fcpio_ack_handler` fractures trace continuity for FCP initiators.
--

commit b27e55a05c332cb8bdf0c9ddf7ffd360abf37856
Author: Karan Tilak Kumar <kartilak@cisco.com>

scsi: fnic: Use fnic_num for non-SCSI identifiers

This commit updates the fnic driver to use the driver instance number
for non-SCSI identifiers when dealing with NVMe initiators. It updates
NVMe-facing FDMI and debugfs entries with fnic_num, and records trace
events with the driver instance number.

> diff --git a/drivers/scsi/fnic/fnic_scsi.c b/drivers/scsi/fnic/fnic_scsi.c
> index 0759540f66753..b92260583c67b 100644
> --- a/drivers/scsi/fnic/fnic_scsi.c
> +++ b/drivers/scsi/fnic/fnic_scsi.c
> @@ -894,7 +894,7 @@ static inline void fnic_fcpio_ack_handler(struct fnic *fnic,
>  
>  	spin_unlock_irqrestore(&fnic->wq_copy_lock[wq_index], flags);
>  	FNIC_TRACE(fnic_fcpio_ack_handler,
> -		  fnic->host->host_no, 0, 0, ox_id_tag[2], ox_id_tag[3],
> +		  fnic->fnic_num, 0, 0, ox_id_tag[2], ox_id_tag[3],

[Severity: Low]
Is it intentional to unconditionally use fnic->fnic_num here instead of
conditionally switching based on the initiator type?

Other FCP-specific trace events continue to log the host_no. Because host_no
and fnic_num can differ depending on driver load order, logging FCP ACKs under
a different identifier might split the trace stream and break tools that
filter traces by host number.

Would it be better to conditionally use host_no for FCP initiators and
fnic_num for NVMe initiators, similar to how the FDMI and debugfs entries
were updated?

>  		  ox_id_tag[4], ox_id_tag[5]);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612180918.8554-1-kartilak@cisco.com?part=2