sym2 on sparc

sym2 on sparc

[Matthew Wilcox]

Could someone with a symbios 53c8xx chip test this patch?  It works
on non-sparc.  If I don't hear of any problems, it'll be in the next
driver update.

Index: drivers/scsi/sym53c8xx_2/sym_glue.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/scsi/sym53c8xx_2/sym_glue.c,v
retrieving revision 1.63
diff -u -p -r1.63 sym_glue.c
--- drivers/scsi/sym53c8xx_2/sym_glue.c	28 Sep 2004 12:34:20 -0000	1.63
+++ drivers/scsi/sym53c8xx_2/sym_glue.c	1 Oct 2004 18:15:30 -0000
@@ -56,6 +56,15 @@
 #define NAME53C		"sym53c"
 #define NAME53C8XX	"sym53c8xx"
 
+/* Bloody SPARC can't do anything normal ... */
+#ifdef __sparc__
+#define IRQ_FMT "%s"
+#define IRQ_PRM(x) __irq_itoa(x)
+#else
+#define IRQ_FMT "%d"
+#define IRQ_PRM(x) (x)
+#endif
+
 static int __devinit
 pci_get_base_address(struct pci_dev *pdev, int index, u_long *base)
 {
@@ -1400,18 +1409,8 @@ static int sym_host_info(struct sym_hcb 
 	copy_info(&info, "Chip " NAME53C "%s, device id 0x%x, "
 			 "revision id 0x%x\n",
 			 np->s.chip_name, np->device_id, np->revision_id);
-	copy_info(&info, "At PCI address %s, "
-#ifdef __sparc__
-		"IRQ %s\n",
-#else
-		"IRQ %d\n",
-#endif
-		pci_name(np->s.device),
-#ifdef __sparc__
-		__irq_itoa(np->s.irq));
-#else
-		(int) np->s.irq);
-#endif
+	copy_info(&info, "At PCI address %s, IRQ " IRQ_FMT "\n",
+		pci_name(np->s.device), IRQ_PRM(np->s.irq));
 	copy_info(&info, "Min. period factor %d, %s SCSI BUS%s\n",
 			 (int) (np->minsync_dt ? np->minsync_dt : np->minsync),
 			 np->maxwide ? "Wide" : "Narrow",
@@ -1539,19 +1538,9 @@ static struct Scsi_Host * __devinit sym_
 	struct sym_fw *fw;
 
 	printk(KERN_INFO
-		"sym%d: <%s> rev 0x%x at pci %s "
-#ifdef __sparc__
-		"irq %s\n",
-#else
-		"irq %d\n",
-#endif
+		"sym%d: <%s> rev 0x%x at pci %s irq " IRQ_FMT "\n",
 		unit, dev->chip.name, dev->chip.revision_id,
-		pci_name(dev->pdev),
-#ifdef __sparc__
-		__irq_itoa(dev->s.irq));
-#else
-		dev->s.irq);
-#endif
+		pci_name(dev->pdev), IRQ_PRM(dev->s.irq));
 
 	/*
 	 *  Get the firmware for this chip.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: sym2 on sparc

[James Bottomley]

On Fri, 2004-10-01 at 14:20, Matthew Wilcox wrote:
> Could someone with a symbios 53c8xx chip test this patch?  It works
> on non-sparc.  If I don't hear of any problems, it'll be in the next
> driver update.

Do we have to do this?

Putting architecture specific knowledge into a device driver is almost
never a good thing to do.  If all you want to do is print out the IRQ
designation, I suspect this is a generic problem, not a sym2 specific
problem, so what we need is something like an irq_to_string()
abstraction.

James

Re: sym2 on sparc

[Matthew Wilcox]

On Sat, Oct 02, 2004 at 09:33:13AM -0400, James Bottomley wrote:
> On Fri, 2004-10-01 at 14:20, Matthew Wilcox wrote:
> > Could someone with a symbios 53c8xx chip test this patch?  It works
> > on non-sparc.  If I don't hear of any problems, it'll be in the next
> > driver update.
> 
> Do we have to do this?

DaveM sent me a reply saying:

> Just print the IRQ out as an unsigned integer, it's not the
> end of the world if you don't use the special sparc macros.

Again, sorry about the list address confusion.

> Putting architecture specific knowledge into a device driver is almost
> never a good thing to do.  If all you want to do is print out the IRQ
> designation, I suspect this is a generic problem, not a sym2 specific
> problem, so what we need is something like an irq_to_string()
> abstraction.

I agree.  We could probably use something similar on PA-RISC.  There's
about 25 drivers in-tree that're currently using __irq_itoa().  Most
of them would be better-written if everybody were using a string.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: sym2 on sparc

[David S. Miller]

On Sat, 2 Oct 2004 15:44:08 +0100
Matthew Wilcox <matthew@wil.cx> wrote:

> > Putting architecture specific knowledge into a device driver is almost
> > never a good thing to do.  If all you want to do is print out the IRQ
> > designation, I suspect this is a generic problem, not a sym2 specific
> > problem, so what we need is something like an irq_to_string()
> > abstraction.
> 
> I agree.  We could probably use something similar on PA-RISC.  There's
> about 25 drivers in-tree that're currently using __irq_itoa().  Most
> of them would be better-written if everybody were using a string.

The strings used to be useful in debugging IRQ routing issues
on sparc64, but that's no longer the case now that I print
out all of the PCI irq routing info at boot time on sparc64 like
so:

PCI-IRQ: Routing bus[ 0] slot[ 2] map[0] to INO[10]
PCI-IRQ: Routing bus[ 0] slot[ 3] map[0] to INO[14]
PCI-IRQ: Routing bus[ 0] slot[ 5] map[0] to INO[1d]
PCI-IRQ: Routing bus[ 0] slot[ 5] map[0] to INO[1e]
PCI-IRQ: Routing bus[ 0] slot[ 5] map[0] to INO[1f]
PCI-IRQ: Routing bus[ 0] slot[ 6] map[0] to INO[18]
PCI-IRQ: Routing bus[ 0] slot[ 6] map[0] to INO[19]
PCI-IRQ: Routing bus[ 1] slot[ 0] map[1] to INO[0d]
PCI-IRQ: Routing bus[ 1] slot[ 1] map[1] to INO[0e]
PCI-IRQ: Routing bus[ 1] slot[ 2] map[1] to INO[0f]
PCI-IRQ: Routing bus[ 1] slot[ 3] map[1] to INO[0c]
PCI0(PBMB): Bus running at 33MHz
PCI-IRQ: Routing bus[ 0] slot[ 1] map[0] to INO[00]
PCI-IRQ: Routing bus[ 0] slot[ 4] map[0] to INO[04]
PCI0(PBMA): Bus running at 66MHz

Re: sym2 on sparc

[William Lee Irwin III]

On Fri, Oct 01, 2004 at 07:20:56PM +0100, Matthew Wilcox wrote:
> Could someone with a symbios 53c8xx chip test this patch?  It works
> on non-sparc.  If I don't hear of any problems, it'll be in the next
> driver update.

This looks like it can't go wrong in modern kernels. I suspect the
odd macros are long dead.


-- wli