The queuecommand routine has a local dev pointer used for the
dev_* prints. The two prints that currently exist are tucked
under a debug define and thus can be left out. Use the actual
location instead of a local to avoid this warning.

This patch is intended to be applied after the "CXL Flash Error
Recovery and Superpipe" series.

Signed-off-by: Matthew R. Ochs <mro...@linux.vnet.ibm.com>
Signed-off-by: Manoj N. Kumar <ma...@linux.vnet.ibm.com>
Reported-by: kbuild test robot <fengguang...@intel.com>
---
 drivers/scsi/cxlflash/main.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index 458ed83..3ccb546 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -354,7 +354,6 @@ static int cxlflash_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *scp)
        struct cxlflash_cfg *cfg = (struct cxlflash_cfg *)host->hostdata;
        struct afu *afu = cfg->afu;
        struct pci_dev *pdev = cfg->dev;
-       struct device *dev = &cfg->dev->dev;
        struct afu_cmd *cmd;
        u32 port_sel = scp->device->channel + 1;
        int nseg, i, ncount;
@@ -384,11 +383,13 @@ static int cxlflash_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *scp)
 
        switch (cfg->state) {
        case STATE_LIMBO:
-               dev_dbg_ratelimited(dev, "%s: device in limbo!\n", __func__);
+               dev_dbg_ratelimited(&cfg->dev->dev, "%s: device in limbo!\n",
+                                   __func__);
                rc = SCSI_MLQUEUE_HOST_BUSY;
                goto out;
        case STATE_FAILTERM:
-               dev_dbg_ratelimited(dev, "%s: device has failed!\n", __func__);
+               dev_dbg_ratelimited(&cfg->dev->dev, "%s: device has failed!\n",
+                                   __func__);
                scp->result = (DID_NO_CONNECT << 16);
                scp->scsi_done(scp);
                rc = 0;
-- 
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