Patch to handle parisc-device quirks/bugs.

Hello parisc-linux hackers,

I have written a small patch to handle a case on the E35 where the device is mis-reported. Specifically, the upper port of the HP-PB bus converter is reported as:

U2-IOA BC GSC+ Port

This is obviously wrong since U2 connects runway to GSC and this bus converer is attempting to connect GSC to HP-PB. The correct bus converter is:

Gecko BOA BC GSC+ Port

The following patch fixes this problem by adding a HP hardare quirks table, and fixing up the device early on in the discovery process so everything else just works.

My question about the patch is is the interface generic enough. The one thing I do not like is depending upon the HPA of the device to determine the quirk, but I could not think of a different/better way to handle this.

Thoughts?

- Ryan

Index: arch/parisc/kernel/drivers.c
===================================================================
RCS file: /var/cvs/linux-2.5/arch/parisc/kernel/drivers.c,v retrieving revision 1.5

diff -u -p -r1.5 drivers.c
@@ -416,6 +416,8 @@ alloc_pa_dev(unsigned long hpa, struct h
 	dev->id.sversion = ((iodc_data[4] & 0x0f) << 16) |
 			(iodc_data[5] << 8) | iodc_data[6];
 	dev->hpa = hpa;
+
+	parisc_hardware_quirks(dev);
 	name = parisc_hardware_description(&dev->id);
 	if (name) {
 		strncpy(dev->name, name, sizeof(dev->name)-1);

Index: arch/parisc/kernel/hardware.c
===================================================================
RCS file: /var/cvs/linux-2.5/arch/parisc/kernel/hardware.c,v retrieving revision 1.4

diff -u -p -r1.4 hardware.c
@@ -1289,6 +1289,21 @@ char *cpu_name_version[][2] = {
 	[pcxw2]	{ "PA8700 (PCX-W2)",	"2.0" }
 };
 
+static struct hp_hardware_quirk {
+	unsigned long hpa;
+	struct parisc_device_id quirk;
+	struct parisc_device_id real;
+} hp_hardware_quirk_list[] __initdata = {
+	/* E35 - Gecko BOA GSC Bus Converter is reported */
+	/* 	 as a U2 GSC Bus converter. */
+	{ 0xfffb8000,	{HPHW_BCPORT, 0, 0x501, 0x0000c },
+			{HPHW_BCPORT, 0, 0x500, 0x0000c }},
+
+	/* NULL terminated list */
+	{ 0x0,		{ HPHW_FAULTY, 0, 0x00, 0x0 },
+			{ HPHW_FAULTY, 0, 0x00, 0x0 }},
+};
+
 const char * __init
 parisc_hardware_description(struct parisc_device_id *id)
 {

@@ -1343,3 +1358,21 @@ parisc_get_cpu_type(unsigned long hversi
 	return pcx;	/* not reached: */
 }
 
+
+void __init parisc_hardware_quirks(struct parisc_device *dev)
+{
+	struct hp_hardware_quirk *list;
+
+	for(list = hp_hardware_quirk_list; list->hpa; list++) {
+		if((dev->hpa == list->hpa) && 
+			(dev->id.hw_type == list->quirk.hw_type) &&
+			(dev->id.hversion == list->quirk.hversion) &&
+			(dev->id.sversion == list->quirk.sversion)) 
+		{
+			dev->id.hw_type = list->real.hw_type;
+			dev->id.hversion = list->real.hversion;
+			dev->id.sversion = list->real.sversion;
+			return;
+		}
+	}
+}

Index: include/asm-parisc/hardware.h
===================================================================
RCS file: /var/cvs/linux-2.5/include/asm-parisc/hardware.h,v retrieving revision 1.3

diff -u -p -r1.3 hardware.h
@@ -131,6 +131,7 @@ struct bc_module {
 /* hardware.c: */
 extern const char *parisc_hardware_description(struct parisc_device_id *id);
 extern enum cpu_type parisc_get_cpu_type(unsigned long hversion);
+extern void parisc_hardware_quirks(struct parisc_device *dev);
 
 struct pci_dev;
 

Could you also check the IODC device type?
Or is that also wrong?
If HPA and type match, then I'd be comfortable with it.

grant

Grant,

I test the hpa, hw_type, hversion, and sversion for the quirk. If all these match, then I update the parisc_device_id with the device it should be.

+ if((dev->hpa == list->hpa) &&

+                       (dev->id.hw_type == list->quirk.hw_type) &&
+                       (dev->id.hversion == list->quirk.hversion) &&
+                       (dev->id.sversion == list->quirk.sversion))

Thanks,

- Ryan

We have some other occurrences of this kind of problem:

Graphics cards are frequently wrong.
HSC-PCI cards show up with the wrong sversion in 715/Mirage machines. One of the Dinos in the J2240 has the wrong sversion.

We ignore the problem for gfx cards since we don't use the IDs anyway. The Dino problems are solved by additional IDs in the Dino driver.

It is legitimate for a driver to refuse to claim a device that it's advertised for. So my personl preference is to advertise for all BC ports, and then refuse to claim the ones which are actually lower ports. That confines the knowledge to one driver.

This scheme doesn't fix the device name printout, but that seems less important.

Revolutions do not require corporate support.

These could easily be added to the quirks list also :)

ditto.

So for this case, you would rather see the U2 GSC+ port added to the hppb.c driver, and simply not-claim any driver that does not reside on the central bus? This would work because ccio only claims devices for the U2 runway side, not the GSC side.

The quirks fixes the print-outs, plus all these problems are fixed in one place, drivers do not even to know there was a problem.

Either way works for me really, just pointing out the reason I built it as a quirk table to begin with.

Thanks,

-Ryan

For users, the name printout *is* important.
It helps determine which devices are really in the box and are supported.

grant