Skip to contentSkip to conversation

de2104x: fix power management

PATCH Ondrej Zary 3 participants 3 messages Sep 25, 2010 – Sep 26, 2010

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Ondrej Zary

author
#0 lore raw

At least my 21041 cards come out of suspend with bus mastering disabled so they did not work after resume(no data transferred).
After adding pci_set_master(), the driver oopsed immediately on resume - because de_clean_rings() is called on suspend but de_init_rings() call was missing in resume.

Also disable link (reset SIA) before sleep (de4x5 does this too).

Signed-off-by Ondrej Zary <[email protected]>
drivers/net/tulip/de2104x.c +3 -0
@@ -1231,6 +1231,7 @@ static void de_adapter_sleep (struct de_
 	if (de->de21040)
 		return;
 
+	dw32(CSR13, 0); /* Reset phy */
 	pci_read_config_dword(de->pdev, PCIPM, &pmctl);
 	pmctl |= PM_Sleep;
 	pci_write_config_dword(de->pdev, PCIPM, pmctl);

@@ -2166,6 +2167,8 @@ static int de_resume (struct pci_dev *pd
 		dev_err(&dev->dev, "pci_enable_device failed in resume\n");
 		goto out;
 	}
+	pci_set_master(pdev);
+	de_init_rings(de);
 	de_init_hw(de);
 out_attach:
 	netif_device_attach(dev);
Signature · 1 line
Ondrej Zary
Acked-by
#1 lore raw
Quoted 21 lines · Ondrej Zary

At least my 21041 cards come out of suspend with bus mastering disabled so they did not work after resume(no data transferred).
After adding pci_set_master(), the driver oopsed immediately on resume - because de_clean_rings() is called on suspend but de_init_rings() call was missing in resume.

Also disable link (reset SIA) before sleep (de4x5 does this too).

Signed-off-by Ondrej Zary<[email protected]>
drivers/net/tulip/de2104x.c +1 -0
@@ -1231,6 +1231,7 @@ static void de_adapter_sleep (struct de_
  	if (de->de21040)
  		return;
 
+	dw32(CSR13, 0); /* Reset phy */
  	pci_read_config_dword(de->pdev, PCIPM,&pmctl);
  	pmctl |= PM_Sleep;
  	pci_write_config_dword(de->pdev, PCIPM, pmctl);

drivers/net/tulip/de2104x.c static int de_resume (struct pci_dev *pd · line 2174

Quoted 8 lines
drivers/net/tulip/de2104x.c +2 -0
@@ -2166,6 +2167,8 @@ static int de_resume (struct pci_dev *pd
  		dev_err(&dev->dev, "pci_enable_device failed in resume\n");
  		goto out;
  	}
+	pci_set_master(pdev);
+	de_init_rings(de);
  	de_init_hw(de);
  out_attach:
  	netif_device_attach(dev);
Acked-by Jeff Garzik <[email protected]>

IMO suspend/resume could use another look; if netif_running is false (interface is down), de2104x does not put the PCI device to sleep, which seems strange.

I also wonder if rtnl_lock() couldn't be eliminated, as other net drivers don't need it in suspend/resume.

maintainer
#2 lore raw

From: Jeff Garzik <[email protected]>
Date: Sat, 25 Sep 2010 13:16:56 -0400

Quoted 12 lines · Ondrej Zary
Quoted 11 lines

At least my 21041 cards come out of suspend with bus mastering disabled so
they did not work after resume(no data transferred).
After adding pci_set_master(), the driver oopsed immediately on resume -
because de_clean_rings() is called on suspend but de_init_rings() call was missing in resume.

Also disable link (reset SIA) before sleep (de4x5 does this too).

Signed-off-by Ondrej Zary<[email protected]>

...

Quoted 1 line
Acked-by Jeff Garzik <[email protected]>

I'll apply this, thanks guys.

Quoted 3 lines

IMO suspend/resume could use another look; if netif_running is false (interface is down), de2104x does not put the PCI device to sleep, which seems strange.

TG3 does the same.

The reason is that until we bringing the device up (and thus netif_running becomes true) the device is left in the most appropriate powered down state.

At least that is my understanding.

What is appropriate for any driver in this situation depends upon how it programs the device before ->open() occurs.

Quoted 2 lines

I also wonder if rtnl_lock() couldn't be eliminated, as other net drivers don't need it in suspend/resume.

I suspect the RTNL stuff here can be safely removed.

I think it's using it to guard the netif_running() check but that isn't necessary.