alchemy/gpr: au1000_eth regression with v2.6.37rc2

DISCUSSION Wolfgang Grandegger 2 participants 6 messages Nov 18, 2010 – Nov 23, 2010

Subsystems (3)

Networking Network drivers MIPS

lore

Share & tools

lore

Wolfgang Grandegger

author

2010-11-18 19:58 UTC #0 lore raw

Hello,

I just realized that the v2.6.37-rc2 kernel does not boot any more on the Alchemy GPR board. It works fine with v2.6.36. It hangs in the probe function of the au1000_eth driver when probing the second ethernet port (eth1):

au1000_eth_mii: probed
au1000-eth au1000-eth.0: (unregistered net_device): attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1) au1000-eth au1000-eth.0: eth0: Au1xx0 Ethernet found at 0x10500000, irq 35
au1000_eth: au1000_eth version 1.7 Pete Popov <[email protected]>
... hangs ...

Similar messages should follow for eth1. I narrowed down (bisect'ed) the problem to commit:

commit d0e7cb5d401695809ba8c980124ab1d8c66efc8b
Author: Florian Fainelli <[email protected]>
Date: Wed Sep 8 11:15:13 2010 +0000

au1000-eth: remove volatiles, switch to I/O accessors

Remove all the volatile keywords where they were used, switch to using the proper readl/writel accessors.

Signed-off-by Florian Fainelli <[email protected]>

Signed-off-by David S. Miller <[email protected]>

The kernel actually hangs when accessing "&aup->mac->mii_control" in au1000_mdio_read(), but only for eth1. Any idea what does go wrong?

In principle, I do not want to access the MII regs of the MAC because eth0 and eth1 are connected to switches. But that's not possible, even with "aup->phy_static_config=1" and "aup->phy_addr=0".

TIA,

Wolfgang.

Florian Fainelli

2010-11-18 22:28 UTC #1 lore raw

Hello Wolfgang,

Quoted 22 lines · Wolfgang Grandegger

Hello,
I just realized that the v2.6.37-rc2 kernel does not boot any more on the Alchemy GPR board. It works fine with v2.6.36. It hangs in the probe function of the au1000_eth driver when probing the second ethernet port (eth1):
au1000_eth_mii: probed
au1000-eth au1000-eth.0: (unregistered net_device): attached PHY driver
[Generic PHY] (mii_bus:phy_addr=0:00, irq=-1) au1000-eth au1000-eth.0:
eth0: Au1xx0 Ethernet found at 0x10500000, irq 35 au1000_eth: au1000_eth version 1.7 Pete Popov <[email protected]> ... hangs ...
Similar messages should follow for eth1. I narrowed down (bisect'ed) the problem to commit:
commit d0e7cb5d401695809ba8c980124ab1d8c66efc8b
Author: Florian Fainelli <[email protected]>
Date: Wed Sep 8 11:15:13 2010 +0000
au1000-eth: remove volatiles, switch to I/O accessors

Quoted 8 lines

Remove all the volatile keywords where they were used, switch to using
the proper readl/writel accessors.
Signed-off-by Florian Fainelli <[email protected]>
Signed-off-by David S. Miller <[email protected]>
The kernel actually hangs when accessing "&aup->mac->mii_control" in au1000_mdio_read(), but only for eth1. Any idea what does go wrong?

I do not understand so far while it hangs only for eth1. My device only has one ethernet MAC, so I could not notice the problem. Looking at this close, there are a couple of u32 const* usages in au1000_mdio_{read,write} which are looking wrong to me now. Can you try to remove these?

Quoted 4 lines

In principle, I do not want to access the MII regs of the MAC because eth0 and eth1 are connected to switches. But that's not possible, even with "aup->phy_static_config=1" and "aup->phy_addr=0".

If you think this is another issue, I will fix it in another patch. --
Florian

Wolfgang Grandegger

author

2010-11-19 10:28 UTC #2 lore raw

Hello Florian,

Quoted 31 lines · Florian Fainelli

Hello Wolfgang,
Quoted 28 lines · Wolfgang Grandegger
Hello,
I just realized that the v2.6.37-rc2 kernel does not boot any more on the Alchemy GPR board. It works fine with v2.6.36. It hangs in the probe function of the au1000_eth driver when probing the second ethernet port (eth1):
au1000_eth_mii: probed
au1000-eth au1000-eth.0: (unregistered net_device): attached PHY driver
[Generic PHY] (mii_bus:phy_addr=0:00, irq=-1) au1000-eth au1000-eth.0:
eth0: Au1xx0 Ethernet found at 0x10500000, irq 35 au1000_eth: au1000_eth version 1.7 Pete Popov <[email protected]> ... hangs ...
Similar messages should follow for eth1. I narrowed down (bisect'ed) the problem to commit:
commit d0e7cb5d401695809ba8c980124ab1d8c66efc8b
Author: Florian Fainelli <[email protected]>
Date: Wed Sep 8 11:15:13 2010 +0000
au1000-eth: remove volatiles, switch to I/O accessors
Remove all the volatile keywords where they were used, switch to using
the proper readl/writel accessors.
Signed-off-by Florian Fainelli <[email protected]>
Signed-off-by David S. Miller <[email protected]>

Quoted 7 lines

Quoted 2 lines
The kernel actually hangs when accessing "&aup->mac->mii_control" in au1000_mdio_read(), but only for eth1. Any idea what does go wrong?
I do not understand so far while it hangs only for eth1. My device only has one ethernet MAC, so I could not notice the problem. Looking at this close, there are a couple of u32 const* usages in au1000_mdio_{read,write} which are looking wrong to me now. Can you try to remove these?

That did not help.

Quoted 5 lines

Quoted 3 lines
In principle, I do not want to access the MII regs of the MAC because eth0 and eth1 are connected to switches. But that's not possible, even with "aup->phy_static_config=1" and "aup->phy_addr=0".
If you think this is another issue, I will fix it in another patch.

Accessing the MII registers of the MAC should not hang the system even if I do not need to. First I want to understand why. Looks like a wired optimizer issue.

BTW: why do you use readl() and writel() instead of the usual au_readl() and au_writel() to access memory mapped cpu registers? It did not help, anyway.

Wolfgang

Florian Fainelli

2010-11-19 10:46 UTC #3 lore raw

Hello Wolfgang,

Quoted 41 lines · On Friday 19 November 2010 11:29:45 Wolfgang Grandegger wrote:

Hello Florian,
Quoted 38 lines · Florian Fainelli
Hello Wolfgang,
Quoted 34 lines · Wolfgang Grandegger
Hello,
I just realized that the v2.6.37-rc2 kernel does not boot any more on the Alchemy GPR board. It works fine with v2.6.36. It hangs in the probe function of the au1000_eth driver when probing the second
ethernet port (eth1):
au1000_eth_mii: probed
au1000-eth au1000-eth.0: (unregistered net_device): attached PHY driver
[Generic PHY] (mii_bus:phy_addr=0:00, irq=-1) au1000-eth au1000-eth.0:
eth0: Au1xx0 Ethernet found at 0x10500000, irq 35 au1000_eth: au1000_eth version 1.7 Pete Popov <[email protected]> ... hangs ...
Similar messages should follow for eth1. I narrowed down (bisect'ed) the
problem to commit:
commit d0e7cb5d401695809ba8c980124ab1d8c66efc8b
Author: Florian Fainelli <[email protected]>
Date: Wed Sep 8 11:15:13 2010 +0000
au1000-eth: remove volatiles, switch to I/O accessors
Remove all the volatile keywords where they were used, switch to using
the proper readl/writel accessors.
Signed-off-by Florian Fainelli <[email protected]>
Signed-off-by David S. Miller <[email protected]>
The kernel actually hangs when accessing "&aup->mac->mii_control" in au1000_mdio_read(), but only for eth1. Any idea what does go wrong?

Quoted 7 lines

Quoted 5 lines
I do not understand so far while it hangs only for eth1. My device only has one ethernet MAC, so I could not notice the problem. Looking at this close, there are a couple of u32 const* usages in au1000_mdio_{read,write} which are looking wrong to me now. Can you try to remove these?
That did not help.

I suspected it, but thanks for the confirmation.

Quoted 10 lines

Quoted 6 lines
Quoted 4 lines
In principle, I do not want to access the MII regs of the MAC because eth0 and eth1 are connected to switches. But that's not possible, even with "aup->phy_static_config=1" and "aup->phy_addr=0".
If you think this is another issue, I will fix it in another patch.
Accessing the MII registers of the MAC should not hang the system even if I do not need to. First I want to understand why. Looks like a wired optimizer issue.

I definitively agree, furthermore since there is a timeout for read and write operations. I will look at the assembly and see if I can see anything different.

Quoted 4 lines

BTW: why do you use readl() and writel() instead of the usual au_readl() and au_writel() to access memory mapped cpu registers? It did not help, anyway.

This is just because they are generic accessors, and the au_{readl,writel} variants were not different.
--
Florian

Wolfgang Grandegger

author

2010-11-23 15:00 UTC #4 lore raw

Hi Florian,

Quoted 61 lines · Florian Fainelli

Hello Wolfgang,
Quoted 41 lines · On Friday 19 November 2010 11:29:45 Wolfgang Grandegger wrote:
Hello Florian,
Quoted 38 lines · Florian Fainelli
Hello Wolfgang,
Quoted 34 lines · Wolfgang Grandegger
Hello,
I just realized that the v2.6.37-rc2 kernel does not boot any more on the Alchemy GPR board. It works fine with v2.6.36. It hangs in the probe function of the au1000_eth driver when probing the second
ethernet port (eth1):
au1000_eth_mii: probed
au1000-eth au1000-eth.0: (unregistered net_device): attached PHY driver
[Generic PHY] (mii_bus:phy_addr=0:00, irq=-1) au1000-eth au1000-eth.0:
eth0: Au1xx0 Ethernet found at 0x10500000, irq 35 au1000_eth: au1000_eth version 1.7 Pete Popov <[email protected]> ... hangs ...
Similar messages should follow for eth1. I narrowed down (bisect'ed) the
problem to commit:
commit d0e7cb5d401695809ba8c980124ab1d8c66efc8b
Author: Florian Fainelli <[email protected]>
Date: Wed Sep 8 11:15:13 2010 +0000
au1000-eth: remove volatiles, switch to I/O accessors
Remove all the volatile keywords where they were used, switch to using
the proper readl/writel accessors.
Signed-off-by Florian Fainelli <[email protected]>
Signed-off-by David S. Miller <[email protected]>
The kernel actually hangs when accessing "&aup->mac->mii_control" in au1000_mdio_read(), but only for eth1. Any idea what does go wrong?
Quoted 7 lines
Quoted 5 lines
I do not understand so far while it hangs only for eth1. My device only has one ethernet MAC, so I could not notice the problem. Looking at this close, there are a couple of u32 const* usages in au1000_mdio_{read,write} which are looking wrong to me now. Can you try to remove these?
That did not help.
I suspected it, but thanks for the confirmation.
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
In principle, I do not want to access the MII regs of the MAC because eth0 and eth1 are connected to switches. But that's not possible, even with "aup->phy_static_config=1" and "aup->phy_addr=0".
If you think this is another issue, I will fix it in another patch.

Quoted 7 lines

Quoted 3 lines
Accessing the MII registers of the MAC should not hang the system even if I do not need to. First I want to understand why. Looks like a wired optimizer issue.
I definitively agree, furthermore since there is a timeout for read and write operations. I will look at the assembly and see if I can see anything different.

The attached patch fixes the issue. It's caused by a simple porting error. I'm going to prepare a proper patch later today.

Wolfgang.

drivers/net/au1000_eth.c +5 -5

index 43489f8..53eff9b 100644
@@ -155,10 +155,10 @@ static void au1000_enable_mac(struct net_device *dev, int force_reset)
 	spin_lock_irqsave(&aup->lock, flags);
 
 	if (force_reset || (!aup->mac_enabled)) {
-		writel(MAC_EN_CLOCK_ENABLE, &aup->enable);
+		writel(MAC_EN_CLOCK_ENABLE, aup->enable);
 		au_sync_delay(2);
 		writel((MAC_EN_RESET0 | MAC_EN_RESET1 | MAC_EN_RESET2
-				| MAC_EN_CLOCK_ENABLE), &aup->enable);
+				| MAC_EN_CLOCK_ENABLE), aup->enable);
 		au_sync_delay(2);
 
 		aup->mac_enabled = 1;

@@ -503,9 +503,9 @@ static void au1000_reset_mac_unlocked(struct net_device *dev)
 
 	au1000_hard_stop(dev);
 
-	writel(MAC_EN_CLOCK_ENABLE, &aup->enable);
+	writel(MAC_EN_CLOCK_ENABLE, aup->enable);
 	au_sync_delay(2);
-	writel(0, &aup->enable);
+	writel(0, aup->enable);
 	au_sync_delay(2);
 
 	aup->tx_full = 0;

@@ -1119,7 +1119,7 @@ static int __devinit au1000_probe(struct platform_device *pdev)
 	/* set a random MAC now in case platform_data doesn't provide one */
 	random_ether_addr(dev->dev_addr);
 
-	writel(0, &aup->enable);
+	writel(0, aup->enable);
 	aup->mac_enabled = 0;
 
 	pd = pdev->dev.platform_data;

Florian Fainelli

Acked-by

2010-11-23 15:33 UTC #5 lore raw

Hello Wolfgang,

Quoted 69 lines · On Tuesday 23 November 2010 16:01:37 Wolfgang Grandegger wrote:

Hi Florian,
Quoted 66 lines · Florian Fainelli
Hello Wolfgang,
Quoted 43 lines · On Friday 19 November 2010 11:29:45 Wolfgang Grandegger wrote:
Hello Florian,
Quoted 40 lines · Florian Fainelli
Hello Wolfgang,
Quoted 36 lines · Wolfgang Grandegger
Hello,
I just realized that the v2.6.37-rc2 kernel does not boot any more on the Alchemy GPR board. It works fine with v2.6.36. It hangs in the probe function of the au1000_eth driver when probing the second
ethernet port (eth1):
au1000_eth_mii: probed
au1000-eth au1000-eth.0: (unregistered net_device): attached PHY driver
[Generic PHY] (mii_bus:phy_addr=0:00, irq=-1) au1000-eth au1000-eth.0:
eth0: Au1xx0 Ethernet found at 0x10500000, irq 35 au1000_eth:
au1000_eth version 1.7 Pete Popov <[email protected]> ... hangs ...
Similar messages should follow for eth1. I narrowed down (bisect'ed) the
problem to commit:
commit d0e7cb5d401695809ba8c980124ab1d8c66efc8b
Author: Florian Fainelli <[email protected]>
Date: Wed Sep 8 11:15:13 2010 +0000
au1000-eth: remove volatiles, switch to I/O accessors
Remove all the volatile keywords where they were used, switch to using
the proper readl/writel accessors.
Signed-off-by Florian Fainelli <[email protected]>
Signed-off-by David S. Miller <[email protected]>
The kernel actually hangs when accessing "&aup->mac->mii_control" in au1000_mdio_read(), but only for eth1. Any idea what does go wrong?
Quoted 7 lines
Quoted 5 lines
I do not understand so far while it hangs only for eth1. My device only has one ethernet MAC, so I could not notice the problem. Looking at this close, there are a couple of u32 const* usages in au1000_mdio_{read,write} which are looking wrong to me now. Can you try to remove these?
That did not help.
I suspected it, but thanks for the confirmation.
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
In principle, I do not want to access the MII regs of the MAC because eth0 and eth1 are connected to switches. But that's not possible, even with "aup->phy_static_config=1" and "aup->phy_addr=0".
If you think this is another issue, I will fix it in another patch.
Accessing the MII registers of the MAC should not hang the system even if I do not need to. First I want to understand why. Looks like a wired optimizer issue.

Quoted 6 lines

Quoted 3 lines
I definitively agree, furthermore since there is a timeout for read and write operations. I will look at the assembly and see if I can see anything different.
The attached patch fixes the issue. It's caused by a simple porting error. I'm going to prepare a proper patch later today.

Nasty and simple enough not to be noticed at compile time. Thanks for debugging this. Feel free to add my:

Acked-by Florian Fainelli <[email protected]>

--
Florian