EEPROM dumping/changing code for r8169 driver

Hi,

As noted in another mail, I have been working on adding EEPROM reading writing support for the r8169 driver. The below diff adds basic support, but it is not completely finished yet:

- debug code is still present
- Kconfig help text might be reworded
- No check for EEPROM size, currently it assumed 1K bits, but 2K bits also exist. This is low-hanging fruit, but as I did not have hardware with 93c56, I did not bother to add it right now. (according to the Realtek r8168 driver, there are also configurations without these 93cx6 chips, but an EEPROM with "TWSI" which these changes currently do not account for at all)

There is an issue with reading though, the initial read fails until a certain action has happened[1]. In the case of an external RTL8169sb GBe PCI card (RTL869SC according to the text on the chip), a write to the EEPROM has to happen first. Could it be a timing issue? I have several PDFs available, but the most detailed one is a PDF with the title "xRTL8169spec_1.21.DOC" (from 2002) which also has a section "11.3.2 Serial EEPROM Interface Timing".

Regards,
Peter

[1]: http://marc.info/?l=linux-netdev&m=137422584013574
--

index ae5d027..ee70de2 100644
@@ -112,4 +112,13 @@ config R8169
 	  To compile this driver as a module, choose M here: the module
 	  will be called r8169.  This is recommended.
 
+config R8169_93CX6
+	bool "Realtek 8169 external 93CX6 EEPROM support"
+	depends on R8169
+	select EEPROM_93CX6
+	---help---
+	  Select this if your want to access EEPROM of the Realtek 8169 PCI
+	  Gigabit Ethernet adapter. This is necessary for dumping or changing
+	  EEPROM using ethtool. If unsure, say N.
+
 endif # NET_VENDOR_REALTEK

[...]

Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

For this, I got inspiration from drivers/ethernet/8390/Kconfig which had an AX88796_93CX6 option. Reading EEPROM is currently not a critical piece of functionality, so I decided to make this optional. There seem also to be newer hardware that use a two-wired serial interface for accessing EEPROM instead of 93C46/93C56/93C66. Would you suggest always including this code (distro kernels should typically enable this) or making it optional? If optional, what is the correct way to depend on EEPROM_93CX6? I think that this option will be hidden in the R8169 menu until EEPROM_93CX6 is selected which might be confusing if looking for this option.

Newer patch follows, I still need to figure out why it reads FFs on my onboard RTL8111E NIC. (observation: accessing PCI memory resource2 via sysfs gives an EIO error, ethtool -d eth0 fails too and reads FFs).

Thanks,
Peter
---

index ae5d027..68a1317 100644
@@ -112,4 +112,13 @@ config R8169
 	  To compile this driver as a module, choose M here: the module
 	  will be called r8169.  This is recommended.
 
+config R8169_93CX6
+	bool "Realtek 8169 external 93CX6 EEPROM support"
+	depends on R8169
+	select EEPROM_93CX6
+	---help---
+	  Select this if your want to access the 93C46/93C56/93C66 EEPROM of the
+	  Realtek 8169 PCI Gigabit Ethernet adapter. This is necessary for
+	  dumping or changing EEPROM using ethtool. If unsure, say N.
+
 endif # NET_VENDOR_REALTEK

Most ethtool operations are not critical, but it costs very little to implement them unconditionally (and config options increase the maintenance burden).

[...]

Always include it.

Ben.

Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.