[PATCH 1/2] 8139cp/8139too: do not read into reserved registers

3 views
Skip to first unread message

Jason Wang

unread,
Dec 31, 2011, 4:44:33 AM12/31/11
to net...@vger.kernel.org, da...@davemloft.net, linux-...@vger.kernel.org, ak...@redhat.com
delay_eeprom() use long read for Cfg9346 register(offset 0x50) which may read
into the area of reserved register(offset 0x53). Use byte read instead.

Signed-off-by: Jason Wang <jaso...@redhat.com>
---
drivers/net/ethernet/realtek/8139cp.c | 2 +-
drivers/net/ethernet/realtek/8139too.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 87cff10..886e6be 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -1589,7 +1589,7 @@ static int cp_set_mac_address(struct net_device *dev, void *p)
No extra delay is needed with 33Mhz PCI, but 66Mhz may change this.
*/

-#define eeprom_delay() readl(ee_addr)
+#define eeprom_delay() readb(ee_addr)

/* The EEPROM commands include the alway-set leading bit. */
#define EE_EXTEND_CMD (4)
diff --git a/drivers/net/ethernet/realtek/8139too.c b/drivers/net/ethernet/realtek/8139too.c
index d9c7227..a8779be 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -1122,7 +1122,7 @@ static void __devexit rtl8139_remove_one (struct pci_dev *pdev)
No extra delay is needed with 33Mhz PCI, but 66Mhz may change this.
*/

-#define eeprom_delay() (void)RTL_R32(Cfg9346)
+#define eeprom_delay() (void)RTL_R8(Cfg9346)

/* The EEPROM commands include the alway-set leading bit. */
#define EE_WRITE_CMD (5)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jason Wang

unread,
Dec 31, 2011, 4:44:42 AM12/31/11
to net...@vger.kernel.org, da...@davemloft.net, linux-...@vger.kernel.org, ak...@redhat.com
Rx mode should be reset after resming, so unconditionally updating rx
mode rather than conditionally updating based on the value we
remembered, otherwise unexpected value may be used by the nic after
resuming.

btw. I find and test this when debugging guest hibernation in qemu, as
I did not have a 8139cp card in hand, this patch is untested in a
physical 8139cp card, plase review it carefully.

Signed-off-by: Jason Wang <jaso...@redhat.com>
---

drivers/net/ethernet/realtek/8139cp.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 886e6be..cc6b391 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -859,7 +859,6 @@ static void __cp_set_rx_mode (struct net_device *dev)
struct cp_private *cp = netdev_priv(dev);
u32 mc_filter[2]; /* Multicast hash filter */
int rx_mode;
- u32 tmp;

/* Note: do not reorder, GCC is clever about common statements. */
if (dev->flags & IFF_PROMISC) {
@@ -886,11 +885,9 @@ static void __cp_set_rx_mode (struct net_device *dev)
}

/* We can safely update without stopping the chip. */
- tmp = cp_rx_config | rx_mode;
- if (cp->rx_config != tmp) {
- cpw32_f (RxConfig, tmp);
- cp->rx_config = tmp;
- }
+ cp->rx_config = cp_rx_config | rx_mode;
+ cpw32_f(RxConfig, cp->rx_config);
+
cpw32_f (MAR0 + 0, mc_filter[0]);
cpw32_f (MAR0 + 4, mc_filter[1]);

Ben Hutchings

unread,
Dec 31, 2011, 5:20:28 PM12/31/11
to Jason Wang, net...@vger.kernel.org, da...@davemloft.net, linux-...@vger.kernel.org, ak...@redhat.com
On Sat, 2011-12-31 at 17:44 +0800, Jason Wang wrote:
> delay_eeprom() use long read for Cfg9346 register(offset 0x50) which may read
> into the area of reserved register(offset 0x53). Use byte read instead.
[...]

If they've been working like this for so long (from the start of git
history), maybe they're best left alone.

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.

Reply all
Reply to author
Forward
0 new messages