On 2004-02-28 22:18, Michael JAKOB <mjakob@web.de> wrote:
> Sorry, I can't provide a patch, since I'm not sure what the best way is
> to distinguish between the 963 and 963L chipsets. One possibility is to
> try the EEPROM approach first, check whether it returns a valid result,
> and call sis635_get_mac_addr() otherwise (but there might be other
> reasons why the EEPROM read fails on a real 963?) Alternatively, one
> might do a PCI scan to check whether the firewire interface is present
> (I can't test that since I only have the version without.)
On second thoughts, that was nonsense. Here's a patch.
However, my suspicion is that an even better solution might be to simply
remove the special case for revision ID 91. This whole EEPROM stuff
looks kinda weird to me: why should SiS change a well established
mechanism just because there are a few unused words in some EEPROM that
just happens to be around for a completely unrelated purpose, even more
so if you can't access the EEPROM right away, but must jump through some
hoops first to request access permission? And further, when there's
another version of the chipset with the same PCI ID that has no EEPROM?
I suspect that the MAC reload command works perfectly well on 962/963
chipsets, too, and the EEPROM stuff is not really necessary (maybe it
can be used to change the MAC address, but this isn't supported with
the sis900 driver anyway.) Maybe someone could try this out?
Michael
--- drivers/net/sis900.c.orig 2003-10-29 21:18:34.000000000 +0100
+++ drivers/net/sis900.c 2004-02-29 12:49:00.000000000 +0100
@@ -18,6 +18,7 @@
preliminary Rev. 1.0 Jan. 18, 1998
http://www.sis.com.tw/support/databook.htm
+ Rev 1.08.07 Feb. 29 2004 Michael Jakob <mjakob@web.de> add support for SiS 962L/963L
Rev 1.08.06 Sep. 24 2002 Mufasa Yang bug fix for Tx timeout & add SiS963 support
Rev 1.08.05 Jun. 6 2002 Mufasa Yang bug fix for read_eeprom & Tx descriptor over-boundary
Rev 1.08.04 Apr. 25 2002 Mufasa Yang <mufasa@sis.com.tw> added SiS962 support
@@ -74,7 +75,7 @@
#include "sis900.h"
#define SIS900_MODULE_NAME "sis900"
-#define SIS900_DRV_VERSION "v1.08.06 9/24/2002"
+#define SIS900_DRV_VERSION "v1.08.07 2/29/2004"
static char version[] __devinitdata =
KERN_INFO "sis900.c: " SIS900_DRV_VERSION "\n";
@@ -329,6 +330,10 @@
* MAC address is read into @net_dev->dev_addr.
*/
+/** Update: recent versions SiS962L/963L (same PCI ID) without firewire
+ * controller have no EEPROM, but use the MAC reload command like the 635.
+ */
+
static int __devinit sis96x_get_mac_addr(struct pci_dev * pci_dev, struct net_device *net_dev)
{
long ioaddr = net_dev->base_addr;
@@ -336,6 +341,8 @@
u32 waittime = 0;
int i;
+ /* First, try to read from the EEPROM. In case of the 962L/963L, this appears
+ to work, but all reads return just 0xFFFF words. */
outl(EEREQ, ee_addr);
while(waittime < 2000) {
if(inl(ee_addr) & EEGNT) {
@@ -343,9 +350,15 @@
/* get MAC address from EEPROM */
for (i = 0; i < 3; i++)
((u16 *)(net_dev->dev_addr))[i] = read_eeprom(ioaddr, i+EEPROMMACAddr);
-
outl(EEDONE, ee_addr);
- return 1;
+
+ /* check the result for validity */
+ for (i = 0; i < 6; i++) {
+ if (net_dev->dev_addr[i] != 0xFF)
+ return 1;
+ }
+ /* if it's all 0xFF, try the other way */
+ return sis635_get_mac_addr(pci_dev, net_dev);
} else {
udelay(1);
waittime ++;
