From: "Manoj N. Kumar" <ma...@linux.vnet.ibm.com>

When switching to the internal LUN defined on the
IBM CXL flash adapter, there is an unnecessary
scan occurring on the second port. This scan leads
to the following extra lines in the log:

Dec 17 10:09:00 tul83p1 kernel: [ 3708.561134] cxlflash 0008:00:00.0: 
cxlflash_queuecommand: (scp=c0000000fc1f0f00) 11/1/0/0 
cdb=(A0000000-00000000-10000000-00000000)
Dec 17 10:09:00 tul83p1 kernel: [ 3708.561147] process_cmd_err: cmd failed 
afu_rc=32 scsi_rc=0 fc_rc=0 afu_extra=0xE, scsi_extra=0x0, fc_extra=0x0

By definition, both of the internal LUNs are on the first port/channel.

When the lun_mode is switched to internal LUN the
same value for host->max_channel is retained. This
causes an unnecessary scan over the second port/channel.

This fix alters the host->max_channel to 0 (1 port), if internal
LUNs are configured and switches it back to 1 (2 ports) while
going back to external LUNs.

Signed-off-by: Manoj N. Kumar <ma...@linux.vnet.ibm.com>
---
 drivers/scsi/cxlflash/main.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index ca702d8..0f062a4 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -2097,6 +2097,16 @@ static ssize_t lun_mode_store(struct device *dev,
        rc = kstrtouint(buf, 10, &lun_mode);
        if (!rc && (lun_mode < 5) && (lun_mode != afu->internal_lun)) {
                afu->internal_lun = lun_mode;
+
+               /*
+                * When configured for internal LUN, there is only one channel,
+                * channel number 0, else there will be 2 (default).
+                */
+               if (afu->internal_lun)
+                       shost->max_channel = 0;
+               else
+                       shost->max_channel = NUM_FC_PORTS - 1;
+
                afu_reset(cfg);
                scsi_scan_host(cfg->host);
        }
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to