[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20141118.154917.171051693633411092.davem@davemloft.net>
Date: Tue, 18 Nov 2014 15:49:17 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: devzero@....de
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] fix #51791 - bug? mac 00:00:00:00:00:00 with natsemi
DP83815 after driver load
From: "Roland Kletzing" <devzero@....de>
Date: Mon, 17 Nov 2014 01:17:47 +0100
> This one should fix Bugzilla #51791 (details below).
>
> Natsemi driver does not read MAC correctly from eeprom, while natsemi-diag from nictools-pci does. Apparently, tt`s a timing issue in the kernel driver.
>
> According to ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c , eeprom_delay(ee_addr) is defined as follows:
>
> /* Delay between EEPROM clock transitions.
> This flushes the write buffer to prevent quick double-writes.
> */
> #define eeprom_delay(ee_addr) inl(ee_addr); inl(ee_addr)
>
> while in the natsemi linux kernel driver, the delay is done this way :
>
> #define eeprom_delay(ee_addr) readl(ee_addr)
>
> , which results in the MAC being all zero`s.
>
> So i simply added a second readl() to increase delay (instead of turning into inl() as proposed before). This may look a little bit ugly, but it`s fixing the problem for me.
>
> I´m not sure how many natsemi users being left on this planet (probably few), but i guess this change does not do any harm on platforms where the driver does not behave buggy, so please consider adding it to mainline/stable/longterm.
>
> Signed-off-by: Roland Kletzing <devzero@....de>
Please post your patch as a clean new email, without quoting things
after your signoff etc.
Also, please break your lines up to 80 columns max.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists