ESP: cosmetic printk error during detection

ESP: cosmetic printk error during detection

[Meelis Roos]

I testbooted 2.6.23-rc2 on my Ultra 1 that has 3 SCSI controllers - 
builtin, ESP, addon esp+hme and a qlogicpti. The detection lines of both 
these esp controllers tell about esp0 although they clearly seem to be 
about different controllers:

esp: esp0, regs[1ffe8800000:1ffe8400000] irq[10]
esp: esp0 is a FAS100A, 40 MHz (ccf=0), SCSI ID 7
scsi0 : esp
esp: esp0, regs[1ff08810000:1ff08800000] irq[14]
esp: esp0 is a FASHME, 40 MHz (ccf=0), SCSI ID 7
scsi 0:0:0:0: Direct-Access     MAXTOR   ATLAS10K4_36SCA  DFV0 PQ: 0 ANSI: 3
 target0:0:0: Beginning Domain Validation
 target0:0:0: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
 target0:0:0: Domain Validation skipping write tests
 target0:0:0: Ending Domain Validation
scsi 0:0:6:0: CD-ROM            TOSHIBA  XM-5401TASUN4XCD 2565 PQ: 0 ANSI: 2
 target0:0:6: Beginning Domain Validation
 target0:0:6: FAST-5 SCSI 4.2 MB/s ST (236 ns, offset 15)
 target0:0:6: Domain Validation skipping write tests
 target0:0:6: Ending Domain Validation
scsi1 : esp

The second esp0 should be esp1. In the code, esp->host->unique_id is 
printed there and after printing the unique_id is assigned like that: 

esp->host->unique_id = instance++;

Should it be ++instance instead?

-- 
Meelis Roos (mroos@linux.ee)

Re: ESP: cosmetic printk error during detection

[David Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Sun, 12 Aug 2007 14:42:03 +0300 (EEST)

> The second esp0 should be esp1. In the code, esp->host->unique_id is 
> printed there and after printing the unique_id is assigned like that: 
> 
> esp->host->unique_id = instance++;
> 
> Should it be ++instance instead?

The first call of scsi_esp_register() (for the controller "0") should
get unique_id set to 0 and instance incremented to 1, the second call
(for the controller "1") should get unique_id set to 1 and instance
incremented to 2, which is what we want.

The problem is rather that we are not assigning the unique_id early
enough, and thus we do prints with the value uninitialized to zero.

Thankfully the bug is purely cosmetic as it only disrupts the probe
printk statements.

This patch should fix it up, thanks for the report.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 77b06a9..95cf7b6 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2314,6 +2314,7 @@ int __devinit scsi_esp_register(struct esp *esp, struct device *dev)
 	esp->host->transportt = esp_transport_template;
 	esp->host->max_lun = ESP_MAX_LUN;
 	esp->host->cmd_per_lun = 2;
+	esp->host->unique_id = instance;
 
 	esp_set_clock_params(esp);
 
@@ -2337,7 +2338,7 @@ int __devinit scsi_esp_register(struct esp *esp, struct device *dev)
 	if (err)
 		return err;
 
-	esp->host->unique_id = instance++;
+	instance++;
 
 	scsi_scan_host(esp->host);
 

Re: ESP: cosmetic printk error during detection

[Meelis Roos]

> The first call of scsi_esp_register() (for the controller "0") should
> get unique_id set to 0 and instance incremented to 1, the second call
> (for the controller "1") should get unique_id set to 1 and instance
> incremented to 2, which is what we want.
> 
> The problem is rather that we are not assigning the unique_id early
> enough, and thus we do prints with the value uninitialized to zero.
> 
> Thankfully the bug is purely cosmetic as it only disrupts the probe
> printk statements.
> 
> This patch should fix it up, thanks for the report.

Thank you, it works fine here. I have been slow to test things recently 
but I have not forgotten :)

-- 
Meelis Roos (mroos@linux.ee)

Re: ESP: cosmetic printk error during detection

[David Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Wed, 29 Aug 2007 18:08:05 +0300 (EEST)

> Thank you, it works fine here. I have been slow to test things recently 
> but I have not forgotten :)

Thanks for testing :)