Skip to contentSkip to conversation

tg3 and Broadcom PHY driver

DISCUSSION Felix Radensky 4 participants 8 messages Sep 26, 2009 – Oct 9, 2009

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

Felix Radensky

author
#0 lore raw

Hi,

I've noticed that in linux-2.6.31 I have to make tg3 driver modular, due to its dependency on Broadcom PHY driver. If both tg3 and PHY driver are compiled into the kernel, tg3 fails to detect a PHY, apparently because PHY driver is loaded later. I'm using BCM57760 on embedded powerpc platform (MPC8536).

How can I make tg3 work when it's compiled into the kernel ?

Thanks.

Felix.

#1 lore raw
Quoted 11 lines · Felix Radensky

Hi,

I've noticed that in linux-2.6.31 I have to make tg3 driver modular, due to its dependency on Broadcom PHY driver. If both tg3 and PHY driver are compiled into the kernel, tg3 fails to detect a PHY, apparently because PHY driver is loaded later. I'm using BCM57760 on embedded powerpc platform (MPC8536).

How can I make tg3 work when it's compiled into the kernel ?

Thanks.

Is the broadcom module also compiled into the kernel?

author
#2 lore raw

Hi, Matt

Quoted 10 lines · Matt Carlson
Quoted 8 lines · Felix Radensky

Hi,

I've noticed that in linux-2.6.31 I have to make tg3 driver modular, due to its dependency on Broadcom PHY driver. If both tg3 and PHY driver are compiled into the kernel, tg3 fails to detect a PHY, apparently because PHY driver is loaded later. I'm using BCM57760 on embedded powerpc platform (MPC8536).

Quoted 8 lines
Quoted 4 lines

How can I make tg3 work when it's compiled into the kernel ?

Thanks.

Is the broadcom module also compiled into the kernel?

Yes.

maintainer
#3 lore raw

From: Felix Radensky <[email protected]>
Date: Mon, 28 Sep 2009 22:53:15 +0200

Quoted 9 lines

Hi, Matt

Quoted 5 lines · Matt Carlson

On Sat, Sep 26, 2009 at 02:32:18PM -0700, Felix Radensky wrote:

Is the broadcom module also compiled into the kernel?

Yes.

I bet this is all because the tg3 driver is linked into the kernel before the PHY layer and drivers subdirectory or something like that.

Link order determines the order in which built-in initializations occur (within the same init type).

author
#4 lore raw

Hi, David

Quoted 14 lines · David Miller

From: Felix Radensky <[email protected]>
Date: Mon, 28 Sep 2009 22:53:15 +0200

Quoted 10 lines

Hi, Matt

Quoted 6 lines · Matt Carlson

On Sat, Sep 26, 2009 at 02:32:18PM -0700, Felix Radensky wrote:

Is the broadcom module also compiled into the kernel?

Quoted 9 lines
Quoted 2 lines

Yes.

I bet this is all because the tg3 driver is linked into the kernel before the PHY layer and drivers subdirectory or something like that.

Link order determines the order in which built-in initializations occur (within the same init type).

Yes, moving CONFIG_TIGON3 right after CONFIG_PHYLIB in drivers/net/Makefile fixes the problem for me.

Thanks a lot.

Felix.

maintainer
#5 lore raw

From: Felix Radensky <[email protected]>
Date: Mon, 28 Sep 2009 23:52:54 +0200

Quoted 2 lines

Yes, moving CONFIG_TIGON3 right after CONFIG_PHYLIB in drivers/net/Makefile fixes the problem for me.

Thanks for testing.

We really need to fix this generically.

Does anyone think that moving the MDIO/MII/PHY layer objects to the top of drivers/net/Makefile will break anything?

If not, that's what we should do I think.

#6 lore raw
Quoted 6 lines · David Miller

From: Felix Radensky <[email protected]>
Date: Mon, 28 Sep 2009 23:52:54 +0200

Quoted 2 lines

Yes, moving CONFIG_TIGON3 right after CONFIG_PHYLIB in drivers/net/Makefile fixes the problem for me.

Quoted 8 lines

Thanks for testing.

We really need to fix this generically.

Does anyone think that moving the MDIO/MII/PHY layer objects to the top of drivers/net/Makefile will break anything?

If not, that's what we should do I think.

Only the phylib drivers actually need to be moved to fix the initialisation order, but moving the others shouldn't hurt.

Ben.

Signature · 3 lines
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
maintainer
#7 lore raw

From: Ben Hutchings <[email protected]>
Date: Tue, 29 Sep 2009 01:53:59 +0100

Quoted 11 lines · David Miller
Quoted 10 lines

From: Felix Radensky <[email protected]>
Date: Mon, 28 Sep 2009 23:52:54 +0200

Quoted 2 lines

Yes, moving CONFIG_TIGON3 right after CONFIG_PHYLIB in drivers/net/Makefile fixes the problem for me.

Thanks for testing.

We really need to fix this generically.

Quoted 7 lines
Quoted 4 lines

Does anyone think that moving the MDIO/MII/PHY layer objects to the top of drivers/net/Makefile will break anything?

If not, that's what we should do I think.

Only the phylib drivers actually need to be moved to fix the initialisation order, but moving the others shouldn't hurt.

Ok, I'm adding the following to net-2.6 to resolve this and will queue it up for -stable too.

Thanks everyone.

net: Link in PHY drivers before others.

We need PHY drivers to initialize in a static kernel before the MAC drivers that use them. So link them in first.

Based upon a report by Felix Radensky.

Signed-off-by David S. Miller <[email protected]>
---
 drivers/net/Makefile |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)
drivers/net/Makefile +4 -4
index d866b8c..48d82e9 100644
@@ -2,6 +2,10 @@
 # Makefile for the Linux network (ethercard) device drivers.
 #
 
+obj-$(CONFIG_MII) += mii.o
+obj-$(CONFIG_MDIO) += mdio.o
+obj-$(CONFIG_PHYLIB) += phy/
+
 obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
 
 obj-$(CONFIG_E1000) += e1000/

@@ -100,10 +104,6 @@ obj-$(CONFIG_SH_ETH) += sh_eth.o
 # end link order section
 #
 
-obj-$(CONFIG_MII) += mii.o
-obj-$(CONFIG_MDIO) += mdio.o
-obj-$(CONFIG_PHYLIB) += phy/
-
 obj-$(CONFIG_SUNDANCE) += sundance.o
 obj-$(CONFIG_HAMACHI) += hamachi.o
 obj-$(CONFIG_NET) += Space.o loopback.o
Signature · 1 line
1.6.4.4