[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[patch] dmfe installer problems



Hi,
in #454618 and #360699 we have reports about failed installs on the Sun
Netra X1. This is caused by the dmfe driver claiming an incompatible
device (due to the same PCI ID for compatible and incompatible device).

The tulip driver has some logic to refuse to touch the problematic dmfe
devices:

drivers/net/tulip_core.c
1279         /*
1280          *      Early DM9100's need software CRC and the DMFE driver
1281          */
1282 
1283         if (pdev->vendor == 0x1282 && pdev->device == 0x9100)
1284         {
1285                 /* Read Chip revision */
1286                 if (pdev->revision < 0x30)
1287                 {
1288                         printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n");
1289                         return -ENODEV;
1290                 }
1291         }

but dmfe doesnt. So dmfe claims the tulip devices but fails to work with
them. One of the symptoms is that it fails to read the mac address and
sets an all 0 MAC address.

I would propose a patch like this (only compile tested): 

diff --git a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c
index b4891ca..b8511f6 100644
--- a/drivers/net/tulip/dmfe.c
+++ b/drivers/net/tulip/dmfe.c
@@ -362,6 +362,7 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
 	struct net_device *dev;
 	u32 pci_pmr;
 	int i, err;
+	u8 macor=0;
 	DECLARE_MAC_BUF(mac);
 
 	DMFE_DBUG(0, "dmfe_init_one()", 0);
@@ -464,8 +465,19 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
 			cpu_to_le16(read_srom_word(db->ioaddr, i));
 
 	/* Set Node address */
-	for (i = 0; i < 6; i++)
+	for (i = 0; i < 6; i++) {
 		dev->dev_addr[i] = db->srom[20 + i];
+		macor |= db->srom[20 + i];
+	}
+
+	/*
+	 * tulip claims to be able to handle revision >= 0x30. In case we
+	 * failed to read the MAC address it might be wise to let tulip try ...
+	 */
+	if (!macor && pdev->revision >= 0x30) {
+		err = -ENODEV;
+		goto err_out_res;
+	}
 
 	err = register_netdev (dev);
 	if (err)

The problematic chip which should be taken care of by the tulip driver
but instead beeing claimed by dmfe is of revision 0x31 and the dmfe
fails to read the mac address.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

Attachment: signature.asc
Description: Digital signature


Reply to: