[0/3] via-rhine: experimental patches

[0/3] via-rhine: experimental patches

[Roger Luethi]

The following batch needs testing. I don't expect any notable
regressions, but I could do with some reports on WOL (already in -mm)
and suspend/resume.

Roger

[1/3] via-rhine: suspend/resume support

[Roger Luethi]

From: Arkadiusz Miskiewicz

Signed-off-by: Arkadiusz Miskiewicz <arekm@pld-linux.org>
Signed-off-by: Roger Luethi <rl@hellgate.ch>

--- linux-2.6.8-rc2-mm1/drivers/net/via-rhine.c	2004-07-30 19:19:19.000000000 +0200
+++ linux-2.6.8-rc2/drivers/net/via-rhine.c	2004-08-06 19:19:07.931310552 +0200
@@ -485,6 +485,9 @@
 	dma_addr_t tx_bufs_dma;
 
 	struct pci_dev *pdev;
+#ifdef CONFIG_PM
+	long pioaddr;
+#endif
 	struct net_device_stats stats;
 	spinlock_t lock;
 
@@ -825,6 +828,9 @@
 	dev->base_addr = ioaddr;
 	rp = netdev_priv(dev);
 	rp->quirks = quirks;
+#ifdef CONFIG_PM
+	rp->pioaddr = pioaddr;
+#endif
 
 	/* Get chip registers into a sane state */
 	rhine_power_init(dev);
@@ -1951,11 +1957,70 @@
 
 }
 
+#ifdef CONFIG_PM
+static int rhine_suspend(struct pci_dev *pdev, u32 state)
+{
+	struct net_device *dev = pci_get_drvdata(pdev);
+	struct rhine_private *rp = netdev_priv(dev);
+	unsigned long flags;
+
+	if (!netif_running(dev))
+		return 0;
+
+	netif_device_detach(dev);
+	pci_save_state(pdev, pdev->saved_config_space);
+
+	spin_lock_irqsave(&rp->lock, flags);
+	rhine_shutdown(&pdev->dev);
+	spin_unlock_irqrestore(&rp->lock, flags);
+
+	return 0;
+}
+
+static int rhine_resume(struct pci_dev *pdev)
+{
+	struct net_device *dev = pci_get_drvdata(pdev);
+	struct rhine_private *rp = netdev_priv(dev);
+	unsigned long flags;
+	int ret;
+
+	if (!netif_running(dev))
+		return 0;
+
+	ret = pci_set_power_state(pdev, 0);
+	if (debug > 1)
+		printk(KERN_INFO "%s: Entering power state D0 %s (%d).\n",
+			dev->name, ret ? "failed" : "succeeded", ret);
+
+	pci_restore_state(pdev, pdev->saved_config_space);
+
+	spin_lock_irqsave(&rp->lock, flags);
+#ifdef USE_MMIO
+	enable_mmio(rp->pioaddr, rp->quirks);
+#endif
+	rhine_power_init(dev);
+	free_tbufs(dev);
+	free_rbufs(dev);
+	alloc_tbufs(dev);
+	alloc_rbufs(dev);
+	init_registers(dev);
+	spin_unlock_irqrestore(&rp->lock, flags);
+	
+	netif_device_attach(dev);
+
+	return 0;
+}
+#endif /* CONFIG_PM */
+
 static struct pci_driver rhine_driver = {
 	.name		= DRV_NAME,
 	.id_table	= rhine_pci_tbl,
 	.probe		= rhine_init_one,
 	.remove		= __devexit_p(rhine_remove_one),
+#ifdef CONFIG_PM
+	.suspend	= rhine_suspend,
+	.resume		= rhine_resume,
+#endif /* CONFIG_PM */
 	.driver = {
 		.shutdown = rhine_shutdown,
 	}

[2/3] via-rhine: de-isolate PHY

[Roger Luethi]

PHYs may come up isolated. Make sure we can send data to them. This code
section needs a clean-up, but I prefer to merge this fix in isolation.

Report and suggested fix by Tam, Ming Dat (Tommy).

Signed-off-by: Roger Luethi <rl@hellgate.ch>

--- linux-2.6.8-rc3-mm1/drivers/net/via-rhine.c.01	2004-08-08 12:36:03.440855262 +0200
+++ linux-2.6.8-rc3-mm1/drivers/net/via-rhine.c	2004-08-08 13:15:24.527527919 +0200
@@ -896,7 +896,10 @@ static int __devinit rhine_init_one(stru
 	pci_set_drvdata(pdev, dev);
 
 	{
+		u16 mii_cmd;
 		int mii_status = mdio_read(dev, phy_id, 1);
+		mii_cmd = mdio_read(dev, phy_id, MII_BMCR) & ~BMCR_ISOLATE;
+		mdio_write(dev, phy_id, MII_BMCR, mii_cmd);
 		if (mii_status != 0xffff && mii_status != 0x0000) {
 			rp->mii_if.advertising = mdio_read(dev, phy_id, 4);
 			printk(KERN_INFO "%s: MII PHY found at address "

[3/3] via-rhine: small fixes

[Roger Luethi]

- remove Rhine model names (per Jeff's request)
- remove redundant calls to clear MII cmd
- fill some rhine_private fields earlier

Signed-off-by: Roger Luethi <rl@hellgate.ch>

--- linux-2.6.8-rc3-mm1/drivers/net/via-rhine.c.02	2004-08-08 13:16:11.009654178 +0200
+++ linux-2.6.8-rc3-mm1/drivers/net/via-rhine.c	2004-08-08 13:19:59.350890566 +0200
@@ -346,7 +346,7 @@ enum rhine_revs {
 	VT6105L		= 0x8A,
 	VT6107		= 0x8C,
 	VTunknown2	= 0x8E,
-	VT6105M		= 0x90,
+	VT6105M		= 0x90,	/* Management adapter */
 };
 
 enum rhine_quirks {
@@ -485,9 +485,7 @@ struct rhine_private {
 	dma_addr_t tx_bufs_dma;
 
 	struct pci_dev *pdev;
-#ifdef CONFIG_PM
 	long pioaddr;
-#endif
 	struct net_device_stats stats;
 	spinlock_t lock;
 
@@ -596,7 +594,7 @@ static void rhine_power_init(struct net_
 			default:
 				reason = "Unknown";
 			}
-			printk("%s: Woke system up. Reason: %s.\n",
+			printk(KERN_INFO "%s: Woke system up. Reason: %s.\n",
 			       DRV_NAME, reason);
 		}
 	}
@@ -706,7 +704,7 @@ static int __devinit rhine_init_one(stru
 	long memaddr;
 	long ioaddr;
 	int io_size, phy_id;
-	const char *name, *mname;
+	const char *name;
 
 /* when built into the kernel, we only print version if device is found */
 #ifndef MODULE
@@ -721,41 +719,24 @@ static int __devinit rhine_init_one(stru
 	phy_id = 0;
 	quirks = 0;
 	name = "Rhine";
-	mname = "unknown";
 	if (pci_rev < VTunknown0) {
 		quirks = rqRhineI;
 		io_size = 128;
-		mname = "VT86C100A";
 	}
 	else if (pci_rev >= VT6102) {
 		quirks = rqWOL | rqForceReset;
 		if (pci_rev < VT6105) {
 			name = "Rhine II";
 			quirks |= rqStatusWBRace;	/* Rhine-II exclusive */
-			if (pci_rev < VT8231)
-				mname = "VT6102";
-			else if (pci_rev < VT8233)
-				mname = "VT8231";
-			else if (pci_rev < VT8235)
-				mname = "VT8233";
-			else if (pci_rev < VT8237)
-				mname = "VT8235";
-			else if (pci_rev < VTunknown1)
-				mname = "VT8237";
 		}
 		else {
-			name = "Rhine III";
 			phy_id = 1;	/* Integrated PHY, phy_id fixed to 1 */
 			if (pci_rev >= VT6105_B0)
 				quirks |= rq6patterns;
-			if (pci_rev < VT6105L)
-				mname = "VT6105";
-			else if (pci_rev < VT6107)
-				mname = "VT6105L";
-			else if (pci_rev < VT6105M)
-				mname = "VT6107";
-			else if (pci_rev >= VT6105M)
-				mname = "Management Adapter VT6105M";
+			if (pci_rev < VT6105M)
+				name = "Rhine III";
+			else
+				name = "Rhine III (Management Adapter)";
 		}
 	}
 
@@ -793,6 +774,11 @@ static int __devinit rhine_init_one(stru
 	SET_MODULE_OWNER(dev);
 	SET_NETDEV_DEV(dev, &pdev->dev);
 
+	rp = netdev_priv(dev);
+	rp->quirks = quirks;
+	rp->pioaddr = pioaddr;
+	rp->pdev = pdev;
+
 	rc = pci_request_regions(pdev, DRV_NAME);
 	if (rc)
 		goto err_out_free_netdev;
@@ -826,11 +812,6 @@ static int __devinit rhine_init_one(stru
 #endif /* USE_MMIO */
 
 	dev->base_addr = ioaddr;
-	rp = netdev_priv(dev);
-	rp->quirks = quirks;
-#ifdef CONFIG_PM
-	rp->pioaddr = pioaddr;
-#endif
 
 	/* Get chip registers into a sane state */
 	rhine_power_init(dev);
@@ -852,7 +833,6 @@ static int __devinit rhine_init_one(stru
 	dev->irq = pdev->irq;
 
 	spin_lock_init(&rp->lock);
-	rp->pdev = pdev;
 	rp->mii_if.dev = dev;
 	rp->mii_if.mdio_read = mdio_read;
 	rp->mii_if.mdio_write = mdio_write;
@@ -880,8 +860,8 @@ static int __devinit rhine_init_one(stru
 	if (rc)
 		goto err_out_unmap;
 
-	printk(KERN_INFO "%s: VIA %s (%s) at 0x%lx, ",
-	       dev->name, name, mname,
+	printk(KERN_INFO "%s: VIA %s at 0x%lx, ",
+	       dev->name, name,
 #ifdef USE_MMIO
 		memaddr
 #else
@@ -1181,7 +1161,7 @@ static int mdio_read(struct net_device *
 
 	rhine_disable_linkmon(ioaddr, rp->quirks);
 
-	writeb(0, ioaddr + MIICmd);
+	/* rhine_disable_linkmon already cleared MIICmd */
 	writeb(phy_id, ioaddr + MIIPhyAddr);
 	writeb(regnum, ioaddr + MIIRegAddr);
 	writeb(0x40, ioaddr + MIICmd);		/* Trigger read */
@@ -1199,7 +1179,7 @@ static void mdio_write(struct net_device
 
 	rhine_disable_linkmon(ioaddr, rp->quirks);
 
-	writeb(0, ioaddr + MIICmd);
+	/* rhine_disable_linkmon already cleared MIICmd */
 	writeb(phy_id, ioaddr + MIIPhyAddr);
 	writeb(regnum, ioaddr + MIIRegAddr);
 	writew(value, ioaddr + MIIData);

Re: [0/3] via-rhine: experimental patches

[Lee Revell]

On Sun, 2004-08-08 at 10:02, Roger Luethi wrote:
> The following batch needs testing. I don't expect any notable
> regressions, but I could do with some reports on WOL (already in -mm)
> and suspend/resume.
> 

Maybe this is a known issue by now, but the via-rhine bug is still not
fixed in 2.6.8-rc3.  I had to replace it with the via-rhine.c from -mm2
to get online.

Lee

Re: [0/3] via-rhine: experimental patches

[Roger Luethi]

On Mon, 09 Aug 2004 22:08:14 -0400, Lee Revell wrote:
> On Sun, 2004-08-08 at 10:02, Roger Luethi wrote:
> > The following batch needs testing. I don't expect any notable
> > regressions, but I could do with some reports on WOL (already in -mm)
> > and suspend/resume.
> 
> Maybe this is a known issue by now, but the via-rhine bug is still not
> fixed in 2.6.8-rc3.  I had to replace it with the via-rhine.c from -mm2
> to get online.

It is known. The fix for that bug is simmering in the pipeline
somewhere. The experimental patches OTOH were for -mm and unrelated.

Roger

Re: [0/3] via-rhine: experimental patches

[Lee Revell]

On Tue, 2004-08-10 at 03:10, Roger Luethi wrote:
> On Mon, 09 Aug 2004 22:08:14 -0400, Lee Revell wrote:
> > On Sun, 2004-08-08 at 10:02, Roger Luethi wrote:
> > > The following batch needs testing. I don't expect any notable
> > > regressions, but I could do with some reports on WOL (already in -mm)
> > > and suspend/resume.
> > 
> > Maybe this is a known issue by now, but the via-rhine bug is still not
> > fixed in 2.6.8-rc3.  I had to replace it with the via-rhine.c from -mm2
> > to get online.
> 
> It is known. The fix for that bug is simmering in the pipeline
> somewhere. The experimental patches OTOH were for -mm and unrelated.
> 

OK, just wanted to make sure the fix gets into 2.6.8, because it can be
a showstopper.

Lee

Re: [2/3] via-rhine: de-isolate PHY

[Manfred Spraul]

Roger wrote:

> PHYs may come up isolated. Make sure we can send data to them. This code
> section needs a clean-up, but I prefer to merge this fix in isolation.
>
What was the phyid value for the isolated PHYs?

I know that PHYs go into isolate mode if the startup id is wired to 0, 
but I haven't figured out what's necessary to initialize them: Just 
clear the isolate bit or is it necessary to set the id to a nonzero value.

--
    Manfred

Re: [2/3] via-rhine: de-isolate PHY

[Roger Luethi]

[ BCCed reporter in case he wants to weigh in on the issue ]

On Sun, 08 Aug 2004 21:53:57 +0200, Manfred Spraul wrote:
> Roger wrote:
> 
> >PHYs may come up isolated. Make sure we can send data to them. This code
> >section needs a clean-up, but I prefer to merge this fix in isolation.
> >
> What was the phyid value for the isolated PHYs?

I suspect it was 0, because another suggestion in the same message was to
start scanning at 0 rather than 1 (obsolete with current via-rhine code).

> I know that PHYs go into isolate mode if the startup id is wired to 0, 

Wouldn't that be s/go/can go/ ?

> but I haven't figured out what's necessary to initialize them: Just 
> clear the isolate bit or is it necessary to set the id to a nonzero value.

The proposed fix apparently worked for the PHY in question (LSI Logic
80225).

Roger

Re: [2/3] via-rhine: de-isolate PHY

[Manfred Spraul]

Roger Luethi wrote:

>  
>
>>I know that PHYs go into isolate mode if the startup id is wired to 0, 
>>    
>>
>
>Wouldn't that be s/go/can go/ ?
>
>  
>
I don't have the MII standard, my knowledge is from the DP83840A specs:
The pin description contains a section about the phy ids:
During power up five pins are latched to determine the initial phy address.
Then the following sentence in bold: "An address selection of all zeros 
(00000) will result in a PHY isolation condition".

I've reread the DP specs and I now think that your current patch is 
sufficient:
The isolate state is independant from the phy address - a non-zero phy 
can be in isolate mode and the phy zero can be non-isolated. The phy id 
just sets the power-up value of the isolate bit: 0 means start isolated, 
non-zero means start non-isolated.

If this is really true then handling phy 0 is trivial:
First scan 1-31. If nothing found: try 0. If a phy is found: clear the 
isolate bit and then use phy 0.

--
    Manfred

Re: [2/3] via-rhine: de-isolate PHY

[Roger Luethi]

On Sun, 08 Aug 2004 23:04:06 +0200, Manfred Spraul wrote:
> Roger Luethi wrote:
> >>I know that PHYs go into isolate mode if the startup id is wired to 0, 
> >
> >Wouldn't that be s/go/can go/ ?
> >
> I don't have the MII standard, my knowledge is from the DP83840A specs:
> The pin description contains a section about the phy ids:
> During power up five pins are latched to determine the initial phy address.
> Then the following sentence in bold: "An address selection of all zeros 
> (00000) will result in a PHY isolation condition".

I suppose all PHYs do that. Even if they don't, though, I should be
safe as long as I de-isolate unconditionally (instead of testing for
phy_id==0).

> I've reread the DP specs and I now think that your current patch is 
> sufficient:
> The isolate state is independant from the phy address - a non-zero phy 
> can be in isolate mode and the phy zero can be non-isolated. The phy id 

Stands to reason. A PHY that can't get out of isolation wouldn't be
very useful.

> If this is really true then handling phy 0 is trivial:
> First scan 1-31. If nothing found: try 0. If a phy is found: clear the 
> isolate bit and then use phy 0.

Makes sense. The Rhine is actually pretty neat in that regard, I've
been able to drop the PHY scanning entirely.

Roger