Skip to contentSkip to conversation

iphase: doesn't call phy->start due to a bogus #ifndef

PATCH In review Jorge Boncompte [DTI2] 3 participants 5 messages Jun 5, 2008 – Jun 14, 2008

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 iphase: doesn't call phy->start due to a bogus #ifndef

This causes the suni driver to oops if you try to use sonetdiag to
get the statistics. Also add the corresponding phy->stop call to fix another oops if you try to remove the module.

---
 drivers/atm/iphase.c |   25 +++++++++++++------------
 1 files changed, 13 insertions(+), 12 deletions(-)
drivers/atm/iphase.c +13 -12
index 1b7090a..521d8af 100644
@@ -2556,17 +2556,13 @@ static int __devinit ia_start(struct atm_dev *dev)
 		error = suni_init(dev);
 		if (error)
 			goto err_free_rx;
-		/*
-		 * Enable interrupt on loss of signal
-		 * SUNI_RSOP_CIE - 0x10
-		 * SUNI_RSOP_CIE_LOSE - 0x04
-		 */
-		ia_phy_put(dev, ia_phy_get(dev, 0x10) | 0x04, 0x10);
-#ifndef MODULE
-		error = dev->phy->start(dev);
-		if (error)
-			goto err_free_rx;
-#endif
+
+		if (dev->phy->start) {
+			error = dev->phy->start(dev);
+			if (error)
+				goto err_free_rx;
+		}
+
 		/* Get iadev->carrier_detect status */
 		IaFrontEndIntr(iadev);
 	}
@@ -3226,9 +3222,14 @@ static void __devexit ia_remove_one(struct pci_dev *pdev)
 	struct atm_dev *dev = pci_get_drvdata(pdev);
 	IADEV *iadev = INPH_IA_DEV(dev);
 
-	ia_phy_put(dev, ia_phy_get(dev,0x10) & ~(0x4), 0x10);
+	/* Disable phy interrupts */
+	ia_phy_put(dev, ia_phy_get(dev,
+			SUNI_RSOP_CIE) & ~(SUNI_RSOP_CIE_LOSE), SUNI_RSOP_CIE);
 	udelay(1);
 
+	if (dev->phy && dev->phy->stop)
+		dev->phy->stop(dev);
+
 	/* De-register device */
       	free_irq(iadev->irq, dev);
 	iadev_count--;
maintainer
#2 lore raw

From: "Chas Williams (CONTRACTOR)" <[email protected]>
Date: Sat, 14 Jun 2008 17:24:05 -0400

Quoted 1 line

i will submit to davem with the next batch of atm patches.

Please do so soon, I've been waiting (too) patiently.

All of those ATM patches have been sitting in my mailbox rotting, and I easily could have applied them even while I was travelling constantly for 3 weeks.

The only reason I didn't was to give you an opportunity to look at them and give feedback. But that feedback and submission needs to be measured in days, not weeks.

Thanks.

#3 lore raw
Quoted 3 lines · In message <[email protected]>,David Miller writes:
Quoted 1 line

i will submit to davem with the next batch of atm patches.

Please do so soon, I've been waiting (too) patiently.

ok. they would need to go on 2.6.27 though. are you taking those at the moment?

Quoted 3 lines

All of those ATM patches have been sitting in my mailbox rotting, and I easily could have applied them even while I was travelling constantly for 3 weeks.

doubt it. his mailer mangled them pretty good.

Quoted 3 lines

The only reason I didn't was to give you an opportunity to look at them and give feedback. But that feedback and submission needs to be measured in days, not weeks.

ok. only 10 days actually. not quite weeks.

maintainer
#4 lore raw

From: "Chas Williams (CONTRACTOR)" <[email protected]>
Date: Sat, 14 Jun 2008 19:45:12 -0400

Quoted 7 lines
Quoted 3 lines · In message <[email protected]>,David Miller writes:
Quoted 1 line

i will submit to davem with the next batch of atm patches.

Please do so soon, I've been waiting (too) patiently.

ok. they would need to go on 2.6.27 though. are you taking those at the moment?

Yes I am, but some of those changes are bug fixes and thus should be submitted for 2.6.26

As I often indicate here, my two trees are:

master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git

for "bug fix current release" stuff and:

master.kernel.org:/pub/scm/linux/kernel/git/davem/net-next-2.6.git

for "features/cleanups bound for next release".

So please post those patches relative to that, as appropriate.