summaryrefslogtreecommitdiff
path: root/drivers/net/enc28j60.c
diff options
context:
space:
mode:
authorRadu Cristescu <advantis@gmx.net>2008-06-12 17:04:54 -0500
committerJeff Garzik <jgarzik@redhat.com>2008-06-17 23:09:21 -0400
commit58c7821c4264a7ddd6f0c31c5caaf393b3897f10 (patch)
treefe34d345975b21d29abe52cb112cac28d528bd4c /drivers/net/enc28j60.c
parent7dac6f8df607929e51f4fd598d80bd009c45a9f8 (diff)
downloadlinux-3.10-58c7821c4264a7ddd6f0c31c5caaf393b3897f10.tar.gz
linux-3.10-58c7821c4264a7ddd6f0c31c5caaf393b3897f10.tar.bz2
linux-3.10-58c7821c4264a7ddd6f0c31c5caaf393b3897f10.zip
atl1: relax eeprom mac address error check
The atl1 driver tries to determine the MAC address thusly: - If an EEPROM exists, read the MAC address from EEPROM and validate it. - If an EEPROM doesn't exist, try to read a MAC address from SPI flash. - If that fails, try to read a MAC address directly from the MAC Station Address register. - If that fails, assign a random MAC address provided by the kernel. We now have a report of a system fitted with an EEPROM containing all zeros where we expect the MAC address to be, and we currently handle this as an error condition. Turns out, on this system the BIOS writes a valid MAC address to the NIC's MAC Station Address register, but we never try to read it because we return an error when we find the all- zeros address in EEPROM. This patch relaxes the error check and continues looking for a MAC address even if it finds an illegal one in EEPROM. Signed-off-by: Radu Cristescu <advantis@gmx.net> Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Diffstat (limited to 'drivers/net/enc28j60.c')
0 files changed, 0 insertions, 0 deletions