smsc911x on Gumstix Overo/Tobi doesn't work

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

"ip link show" does not show any available Ethernet port.

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

Hi,

Quoted 15 lines · Thomas Klute

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

Quoted 1 line

"ip link show" does not show any available Ethernet port.

The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3.

Quoted 4 lines

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed.

Care to test the following patch by passing a fixed regulator from board-overo.c?

You can copy the fixed regulator from gpmc-smsc911x.c, or ideally pass the real smsc911x controlling regulator for overo.

Regards,

Tony

From: Tony Lindgren <[email protected]>
Date: Fri, 16 Mar 2012 12:26:25 -0700
Subject: [PATCH] ARM: OMAP2+: Allow passing smsc911x regulator from boards

Otherwise we won't be able to properly support multiple instances of smsc911x.

Signed-off-by Tony Lindgren <[email protected]>

arch/arm/mach-omap2/gpmc-smsc911x.c +16 -7

@@ -97,17 +97,26 @@ void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *board_data)
 {
 	struct platform_device *pdev;
 	unsigned long cs_mem_base;
+	struct platform_device *regulator = NULL;
 	int ret;
 
 	gpmc_cfg = board_data;
 
-	if (!gpmc_cfg->id) {
-		ret = platform_device_register(&gpmc_smsc911x_regulator);
-		if (ret < 0) {
-			pr_err("Unable to register smsc911x regulators: %d\n",
-			       ret);
-			return;
-		}
+	if (gpmc_cfg->regulator)
+		regulator = gpmc_cfg->regulator;
+	else if (!gpmc_cfg->id)
+		regulator = &gpmc_smsc911x_regulator;
+
+	if (!regulator) {
+		pr_err("Missing smsc911x regulator in board_data\n");
+		return;
+	}
+
+	ret = platform_device_register(regulator);
+	if (ret < 0) {
+		pr_err("Unable to register smsc911x regulators: %d\n",
+		       ret);
+		return;
 	}
 
 	if (gpmc_cs_request(gpmc_cfg->cs, SZ_16M, &cs_mem_base) < 0) {

Am 16.03.2012 20:33, schrieb Tony Lindgren:

Quoted 18 lines

Hi,

Quoted 15 lines · Thomas Klute

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

Quoted 5 lines

Quoted 1 line

"ip link show" does not show any available Ethernet port.

The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3.

The Tobi board has only one Ethernet port.

Quoted 9 lines

Quoted 4 lines

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed.

Quoted 2 lines

Care to test the following patch by passing a fixed regulator from board-overo.c?

After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you!

However, I noticed another problem while testing the patch (not sure if it occurs with the previous version, I can check if that helps): A NULL pointer dereference occurs when unloading the module, see attached log.

Quoted 39 lines

Am 16.03.2012 20:33, schrieb Tony Lindgren:

Quoted 18 lines

Hi,

Quoted 15 lines · Thomas Klute

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

Quoted 5 lines

Quoted 1 line

"ip link show" does not show any available Ethernet port.

The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3.

The Tobi board has only one Ethernet port.

Quoted 11 lines

Quoted 4 lines

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed.

Care to test the following patch by passing a fixed regulator from board-overo.c?

Quoted 3 lines

After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you!

Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted?

Quoted 3 lines

However, I noticed another problem while testing the patch (not sure if it occurs with the previous version, I can check if that helps): A NULL pointer dereference occurs when unloading the module, see attached log.

Yes please do check, that needs to be fixed.

Am 19.03.2012 23:51, schrieb Tony Lindgren:

Quoted 40 lines · Thomas Klute

Quoted 39 lines

Am 16.03.2012 20:33, schrieb Tony Lindgren:

Quoted 18 lines

Hi,

Quoted 15 lines · Thomas Klute

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

Quoted 5 lines

Quoted 1 line

"ip link show" does not show any available Ethernet port.

The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3.

The Tobi board has only one Ethernet port.

Quoted 11 lines

Quoted 4 lines

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed.

Care to test the following patch by passing a fixed regulator from board-overo.c?

Quoted 8 lines

Quoted 3 lines

After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you!

Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted?

You're right, during further tests I found that the problem lies
elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after

# modprobe -r smsc911x
[attach cable]
# modprobe smsc911x

it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem.

Quoted 56 lines · Thomas Klute

Am 19.03.2012 23:51, schrieb Tony Lindgren:

Quoted 40 lines · Thomas Klute

Quoted 39 lines

Am 16.03.2012 20:33, schrieb Tony Lindgren:

Quoted 18 lines

Hi,

Quoted 15 lines · Thomas Klute

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

Quoted 5 lines

Quoted 1 line

"ip link show" does not show any available Ethernet port.

The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3.

The Tobi board has only one Ethernet port.

Quoted 11 lines

Quoted 4 lines

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed.

Care to test the following patch by passing a fixed regulator from board-overo.c?

Quoted 8 lines

Quoted 3 lines

After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you!

Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted?

You're right, during further tests I found that the problem lies
elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after

Quoted 7 lines

# modprobe -r smsc911x
[attach cable]
# modprobe smsc911x

it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem.

Hi Thomas,

I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode.

The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful.

I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset.

The commit is:

commit 6386994e03ebbe60338ded3d586308a41e81c0dc

Author: Javier Martinez Canillas <[email protected]>
Date:   Tue Jan 3 13:36:19 2012 +0000

net/smsc911x: Check if PHY is in operational mode before software reset

When I fix the issue I only guarded against generation 4 chips (i.e:
pdata->generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets).

Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode.

Quoted 56 lines · Thomas Klute

Am 19.03.2012 23:51, schrieb Tony Lindgren:

Quoted 40 lines · Thomas Klute

Quoted 39 lines

Am 16.03.2012 20:33, schrieb Tony Lindgren:

Quoted 18 lines

Hi,

Quoted 15 lines · Thomas Klute

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

Quoted 5 lines

Quoted 1 line

"ip link show" does not show any available Ethernet port.

The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3.

The Tobi board has only one Ethernet port.

Quoted 11 lines

Quoted 4 lines

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed.

Care to test the following patch by passing a fixed regulator from board-overo.c?

Quoted 8 lines

Quoted 3 lines

After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you!

Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted?

You're right, during further tests I found that the problem lies
elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after

Quoted 7 lines

# modprobe -r smsc911x
[attach cable]
# modprobe smsc911x

it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem.

Hi Thomas,

I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode.

The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful.

I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset.

The commit is:

commit 6386994e03ebbe60338ded3d586308a41e81c0dc

Author: Javier Martinez Canillas <[email protected]>
Date:   Tue Jan 3 13:36:19 2012 +0000

net/smsc911x: Check if PHY is in operational mode before software reset

When I fix the issue I only guarded against generation 4 chips (i.e:
pdata->generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets).

Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode.

Hi,

I finally had some time to do more tests on this problem. Findings below.

Am 20.03.2012 20:47, schrieb Javier Martinez Canillas:

Quoted 96 lines

Quoted 56 lines · Thomas Klute

Am 19.03.2012 23:51, schrieb Tony Lindgren:

Quoted 40 lines · Thomas Klute

Quoted 39 lines

Am 16.03.2012 20:33, schrieb Tony Lindgren:

Quoted 18 lines

Hi,

Quoted 15 lines · Thomas Klute

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

Quoted 5 lines

Quoted 1 line

"ip link show" does not show any available Ethernet port.

The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3.

The Tobi board has only one Ethernet port.

Quoted 11 lines

Quoted 4 lines

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed.

Care to test the following patch by passing a fixed regulator from board-overo.c?

Quoted 8 lines

Quoted 3 lines

After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you!

Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted?

You're right, during further tests I found that the problem lies
elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after

Quoted 7 lines

# modprobe -r smsc911x
[attach cable]
# modprobe smsc911x

it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem.

Hi Thomas,

I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode.

The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful.

I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset.

The commit is:

commit 6386994e03ebbe60338ded3d586308a41e81c0dc
Author: Javier Martinez Canillas <[email protected]>
Date:   Tue Jan 3 13:36:19 2012 +0000

    net/smsc911x: Check if PHY is in operational mode before software reset

When I fix the issue I only guarded against generation 4 chips (i.e:
pdata->generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets).

Quoted 4 lines

Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode.

After looking at the code I set USE_DEBUG to 3 to get as much information as possible and tested with and without the SMSC PHY driver. Results:

With the Ethernet cable attached, the device is properly initialized with and without the PHY driver (as before).

Without the cable, the smsc911x driver can initialize the card only if the smsc PHY driver had not been loaded previously. Unloading the PHY driver is not enough, even a reboot doesn't help. I have to do a cold boot (or attach the cable).

I guess this confirms Javier's guess, but there's one catch: If you take a look at the attached logs (both without cable attached), you'll see that the device is recognized a generation 4, so the Javier's workaround should actually be used. I added a log output in the if (pdata->generation == 4) block to be sure, and indeed it is used.

Any hints why the reset still fails?

Regards,
Thomas

Quoted 4 lines · Thomas Klute

Hi,

I finally had some time to do more tests on this problem. Findings below.

Great, I guess we are close to find the issue :)

Quoted 106 lines

Am 20.03.2012 20:47, schrieb Javier Martinez Canillas:

Quoted 96 lines

Quoted 56 lines · Thomas Klute

Am 19.03.2012 23:51, schrieb Tony Lindgren:

Quoted 40 lines · Thomas Klute

Quoted 39 lines

Am 16.03.2012 20:33, schrieb Tony Lindgren:

Quoted 18 lines

Hi,

Quoted 15 lines · Thomas Klute

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

Quoted 5 lines

Quoted 1 line

"ip link show" does not show any available Ethernet port.

The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3.

The Tobi board has only one Ethernet port.

Quoted 11 lines

Quoted 4 lines

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed.

Care to test the following patch by passing a fixed regulator from board-overo.c?

Quoted 8 lines

Quoted 3 lines

After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you!

Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted?

You're right, during further tests I found that the problem lies
elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after

Quoted 7 lines

# modprobe -r smsc911x
[attach cable]
# modprobe smsc911x

it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem.

Hi Thomas,

I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode.

The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful.

I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset.

The commit is:

commit 6386994e03ebbe60338ded3d586308a41e81c0dc

Author: Javier Martinez Canillas <[email protected]>
Date:   Tue Jan 3 13:36:19 2012 +0000

net/smsc911x: Check if PHY is in operational mode before software reset

When I fix the issue I only guarded against generation 4 chips (i.e:
pdata->generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets).

Quoted 4 lines

Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode.

After looking at the code I set USE_DEBUG to 3 to get as much information as possible and tested with and without the SMSC PHY driver. Results:

Quoted 8 lines

With the Ethernet cable attached, the device is properly initialized with and without the PHY driver (as before).

Without the cable, the smsc911x driver can initialize the card only if the smsc PHY driver had not been loaded previously. Unloading the PHY driver is not enough, even a reboot doesn't help. I have to do a cold boot (or attach the cable).

This makes sense since is the PHY driver who enables the auto energy detect mode.

Quoted 10 lines

I guess this confirms Javier's guess, but there's one catch: If you take a look at the attached logs (both without cable attached), you'll see that the device is recognized a generation 4, so the Javier's workaround should actually be used. I added a log output in the if (pdata->generation == 4) block to be sure, and indeed it is used.

Any hints why the reset still fails?

Regards,
Thomas

My guess is that the PHY chip is still in a low power down and not being woken up before the MAC chip is tried to be software reseted. I didn't find in the SMSC LAN8700 data-sheet how long it takes to wake up the chip and probably it depends of the PHY chip (I only tried with the 8700) so if I were you I would try increasing the delay time after sending the MII command to disable the auto energy detect mode.

Can you try this patch?

drivers/net/ethernet/smsc/smsc911x.c +0 -0

index 24d2df0..d08709a 100644
@@ -1349,7 +1349,7 @@ static int

smsc911x_phy_disable_energy_detect(struct smsc911x_data *

                        return rc;
                }

drivers/net/ethernet/smsc/smsc911x.c +1 -1

-               mdelay(1);
+               mdelay(100);
        }
 
        return 0;

Best regards,

Am 01.04.2012 21:20, schrieb Javier Martinez Canillas:

Quoted 145 lines

Quoted 4 lines · Thomas Klute

Hi,

I finally had some time to do more tests on this problem. Findings below.

Great, I guess we are close to find the issue :)

Quoted 106 lines

Am 20.03.2012 20:47, schrieb Javier Martinez Canillas:

Quoted 96 lines

Quoted 56 lines · Thomas Klute

Am 19.03.2012 23:51, schrieb Tony Lindgren:

Quoted 40 lines · Thomas Klute

Quoted 39 lines

Am 16.03.2012 20:33, schrieb Tony Lindgren:

Quoted 18 lines

Hi,

Quoted 15 lines · Thomas Klute

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

Quoted 5 lines

Quoted 1 line

"ip link show" does not show any available Ethernet port.

The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3.

The Tobi board has only one Ethernet port.

Quoted 11 lines

Quoted 4 lines

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed.

Care to test the following patch by passing a fixed regulator from board-overo.c?

Quoted 8 lines

Quoted 3 lines

After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you!

Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted?

You're right, during further tests I found that the problem lies
elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after

Quoted 7 lines

# modprobe -r smsc911x
[attach cable]
# modprobe smsc911x

it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem.

Hi Thomas,

I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode.

The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful.

I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset.

The commit is:

commit 6386994e03ebbe60338ded3d586308a41e81c0dc
Author: Javier Martinez Canillas <[email protected]>
Date:   Tue Jan 3 13:36:19 2012 +0000

    net/smsc911x: Check if PHY is in operational mode before software reset

When I fix the issue I only guarded against generation 4 chips (i.e:
pdata->generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets).

Quoted 4 lines

Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode.

After looking at the code I set USE_DEBUG to 3 to get as much information as possible and tested with and without the SMSC PHY driver. Results:

Quoted 8 lines

With the Ethernet cable attached, the device is properly initialized with and without the PHY driver (as before).

Without the cable, the smsc911x driver can initialize the card only if the smsc PHY driver had not been loaded previously. Unloading the PHY driver is not enough, even a reboot doesn't help. I have to do a cold boot (or attach the cable).

This makes sense since is the PHY driver who enables the auto energy detect mode.

Quoted 10 lines

I guess this confirms Javier's guess, but there's one catch: If you take a look at the attached logs (both without cable attached), you'll see that the device is recognized a generation 4, so the Javier's workaround should actually be used. I added a log output in the if (pdata->generation == 4) block to be sure, and indeed it is used.

Any hints why the reset still fails?

Regards,
Thomas

My guess is that the PHY chip is still in a low power down and not being woken up before the MAC chip is tried to be software reseted. I didn't find in the SMSC LAN8700 data-sheet how long it takes to wake up the chip and probably it depends of the PHY chip (I only tried with the 8700) so if I were you I would try increasing the delay time after sending the MII command to disable the auto energy detect mode.

Quoted 1 line

Can you try this patch?

The longer delay did not help, even with mdelay(1000) the reset still failed. There's one exception: After a cold boot, the device is discovered correctly without cable and with the smsc PHY driver loaded.

(Sorry about the delay, this problem isn't really an issue for our project now that we have a reliable workaround...)

Quoted 18 lines

drivers/net/ethernet/smsc/smsc911x.c +0 -0

index 24d2df0..d08709a 100644
@@ -1349,7 +1349,7 @@ static int

smsc911x_phy_disable_energy_detect(struct smsc911x_data * return rc;
                }

-               mdelay(1);
+               mdelay(100);
        }

        return 0;

Best regards,

Quoted 146 lines · Thomas Klute

Am 01.04.2012 21:20, schrieb Javier Martinez Canillas:

Quoted 145 lines

Quoted 4 lines · Thomas Klute

Hi,

I finally had some time to do more tests on this problem. Findings below.

Great, I guess we are close to find the issue :)

Quoted 106 lines

Am 20.03.2012 20:47, schrieb Javier Martinez Canillas:

Quoted 96 lines

Quoted 56 lines · Thomas Klute

Am 19.03.2012 23:51, schrieb Tony Lindgren:

Quoted 40 lines · Thomas Klute

Quoted 39 lines

Am 16.03.2012 20:33, schrieb Tony Lindgren:

Quoted 18 lines

Hi,

Quoted 15 lines · Thomas Klute

Hi,

I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows:

du14:~# modprobe smsc911x
[  254.843811] smsc911x: Driver version 2008-10-21
[  254.854553] smsc911x: Driver version 2008-10-21
[  254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using
dummy regulator
[  254.868377] _regulator_get: smsc911x.1 supply vddvario not found,
using dummy regulator

Quoted 5 lines

Quoted 1 line

"ip link show" does not show any available Ethernet port.

The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3.

The Tobi board has only one Ethernet port.

Quoted 11 lines

Quoted 4 lines

I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case.

The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed.

Care to test the following patch by passing a fixed regulator from board-overo.c?

Quoted 8 lines

Quoted 3 lines

After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you!

Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted?

You're right, during further tests I found that the problem lies
elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after

Quoted 7 lines

# modprobe -r smsc911x
[attach cable]
# modprobe smsc911x

it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem.

Hi Thomas,

I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode.

The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful.

I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset.

The commit is:

commit 6386994e03ebbe60338ded3d586308a41e81c0dc

Author: Javier Martinez Canillas <[email protected]>
Date:   Tue Jan 3 13:36:19 2012 +0000

net/smsc911x: Check if PHY is in operational mode before software reset

When I fix the issue I only guarded against generation 4 chips (i.e:
pdata->generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets).

Quoted 4 lines

Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode.

After looking at the code I set USE_DEBUG to 3 to get as much information as possible and tested with and without the SMSC PHY driver. Results:

Quoted 8 lines

With the Ethernet cable attached, the device is properly initialized with and without the PHY driver (as before).

Without the cable, the smsc911x driver can initialize the card only if the smsc PHY driver had not been loaded previously. Unloading the PHY driver is not enough, even a reboot doesn't help. I have to do a cold boot (or attach the cable).

This makes sense since is the PHY driver who enables the auto energy detect mode.

Quoted 10 lines

I guess this confirms Javier's guess, but there's one catch: If you take a look at the attached logs (both without cable attached), you'll see that the device is recognized a generation 4, so the Javier's workaround should actually be used. I added a log output in the if (pdata->generation == 4) block to be sure, and indeed it is used.

Any hints why the reset still fails?

Regards,
Thomas

My guess is that the PHY chip is still in a low power down and not being woken up before the MAC chip is tried to be software reseted. I didn't find in the SMSC LAN8700 data-sheet how long it takes to wake up the chip and probably it depends of the PHY chip (I only tried with the 8700) so if I were you I would try increasing the delay time after sending the MII command to disable the auto energy detect mode.

Quoted 6 lines

Quoted 1 line

Can you try this patch?

The longer delay did not help, even with mdelay(1000) the reset still failed. There's one exception: After a cold boot, the device is discovered correctly without cable and with the smsc PHY driver loaded.

Hi Thomas,

I'm out of ideas then, sorry.

Without the hardware to test I can not think now why that could happen.

Quoted 3 lines

(Sorry about the delay, this problem isn't really an issue for our project now that we have a reliable workaround...)

Don't worry, is the same for me. With the workaround my platform (IGEPv2 board) works well so I don't have time to dig more on this.

Best regards,

Quoted 18 lines

Quoted 18 lines

drivers/net/ethernet/smsc/smsc911x.c +0 -0

index 24d2df0..d08709a 100644
@@ -1349,7 +1349,7 @@ static int

smsc911x_phy_disable_energy_detect(struct smsc911x_data *

                        return rc;
                }

drivers/net/ethernet/smsc/smsc911x.c +1 -1

-               mdelay(1);
+               mdelay(100);
        }
 
        return 0;

Best regards,

unwieldy this would become if it were done for every device. Either the functionality needs to be moved to Snowball board init code, or a generic framework needs to be made for attaching regulators to arbitrary devices.

arch/arm/mach-omap2/gpmc-smsc911x.c +6 -0

+	supplies = kcalloc(ARRAY_SIZE(smsc911x_refs) * num,
+			sizeof(struct regulator_consumer_supply), GFP_KERNEL);
+	if (!supplies) {
+		pr_err("Failed to allocate memory\n");
+		return;
+	}

arch/arm/mach-omap2/gpmc-smsc911x.c free1: · line 170

Quoted 10 lines · Russ Dill

arch/arm/mach-omap2/gpmc-smsc911x.c +9 -0

+	for (i = 0; i < ARRAY_SIZE(smsc911x_refs) * num; i++) {
+		int id;
+		char *name;
+
+		id = board_data[i / num].id;
+		if (id != -1)
+			name = kasprintf(GFP_KERNEL, "smsc911x.%d", id);
+		else
+			name = kstrdup("smsc911x", GFP_KERNEL);

This seems pretty much insane, it's costing a lot more to faff around like this than it's worth. Just do the setup in the individual boards, if you really have no idea what's supplying the device (which seems a bit unusual, more boards like this have things coming off the PMIC than don't) there's now regulator_register_fixed() which cuts down on the boilerplate a little.

I'd have complained about the original code if I'd noticed it wasn't a patch for a particular board as the breakage you've found is obvious. The regulation constraints it adds are bogus too, it's setting REGULATOR_CHANGE_MODE on a regulator that doesn't support modes and REGULATOR_CHANGE_STATUS without supplying the enable GPIO.

Quoted 3 lines · Russ Dill

unwieldy this would become if it were done for every device. Either the functionality needs to be moved to Snowball board init code, or a generic framework needs to be made for attaching regulators to arbitrary devices.

Hrm? Adding regulator supply mappings anywhere other than the initialisation for a specific board would be extremely unusual and rather suspicious.

Quoted 2 lines · Mark Brown

On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:

Quoted 7 lines

Quoted 3 lines

unwieldy this would become if it were done for every device. Either the functionality needs to be moved to Snowball board init code, or a generic framework needs to be made for attaching regulators to arbitrary devices.

Hrm? Adding regulator supply mappings anywhere other than the initialisation for a specific board would be extremely unusual and rather suspicious.

Just to be clear, here is the thread on the board-specific approach:
https://lkml.org/lkml/2012/2/8/415

Quoted 3 lines · Porter, Matt

Quoted 3 lines

Hrm? Adding regulator supply mappings anywhere other than the initialisation for a specific board would be extremely unusual and rather suspicious.

The issue here is that we don't want to copy paste the dummy fixed regulator all over the board-*.c files, and we don't know how the real regulator is wired up.

Quoted 2 lines

Just to be clear, here is the thread on the board-specific approach:
https://lkml.org/lkml/2012/2/8/415

We should use the real regulator if passed from board file.

And if no real regulator is passed, just use the dummy fixed regulator in gpmc-smsc911x.c.

This patch I posted should fix the situation and allow adding the real regulators to board-*.c files when they become known:

http://www.spinics.net/lists/linux-omap/msg66714.html

Quoted 5 lines · Tony Lindgren

Quoted 3 lines · Porter, Matt

Quoted 3 lines

Hrm? Adding regulator supply mappings anywhere other than the initialisation for a specific board would be extremely unusual and rather suspicious.

Quoted 3 lines

The issue here is that we don't want to copy paste the dummy fixed regulator all over the board-*.c files, and we don't know how the real regulator is wired up.

Well, I don't think it's too unreasonable especially now we've got the fixed helper stuff which slims it right down - it makes it clear there's a missing thing that might need to get filled in and makes it easier to use the same regulator for other devices.

Quoted 7 lines

Quoted 2 lines

Just to be clear, here is the thread on the board-specific approach:
https://lkml.org/lkml/2012/2/8/415

We should use the real regulator if passed from board file.

And if no real regulator is passed, just use the dummy fixed regulator in gpmc-smsc911x.c.

Yes, it should definitely be conditional.

Quoted 2 lines

This patch I posted should fix the situation and allow adding the real regulators to board-*.c files when they become known:

Quoted 1 line

http://www.spinics.net/lists/linux-omap/msg66714.html

That should be changed to pass in a boolean flag rather than a pointer to platform device - the board may not have direct access to the relevant regulator (eg, if it's part of a MFD) or the regulator may be on another bus like I2C (for simpler regulator only devices).

Quoted 4 lines · Mark Brown

That should be changed to pass in a boolean flag rather than a pointer to platform device - the board may not have direct access to the relevant regulator (eg, if it's part of a MFD) or the regulator may be on another bus like I2C (for simpler regulator only devices).

Hmm I see. This means that we need to patch some board files anyways for the boolean flag to use the fixed regulator. This is because for some cases vddvario and vdd33a regulators can come from the mfd/tps/twl chip and it's unsafe to assume that gpmc-smsc911x.c can set up these regulators automatically. Passing a boolean flag to not set up the default regulator would work too, but we'd rather eventually see the real board specific regulators being patched in.

So if that's the case, we might as well patch the board files to add the fixed regulators for each one and drop all the regulator code from gpmc-smsc911x.c.

Quoted 7 lines · Tony Lindgren

Quoted 4 lines · Mark Brown

That should be changed to pass in a boolean flag rather than a pointer to platform device - the board may not have direct access to the relevant regulator (eg, if it's part of a MFD) or the regulator may be on another bus like I2C (for simpler regulator only devices).

Quoted 7 lines

Hmm I see. This means that we need to patch some board files anyways for the boolean flag to use the fixed regulator. This is because for some cases vddvario and vdd33a regulators can come from the mfd/tps/twl chip and it's unsafe to assume that gpmc-smsc911x.c can set up these regulators automatically. Passing a boolean flag to not set up the default regulator would work too, but we'd rather eventually see the real board specific regulators being patched in.

Yes, ideally the boards would do everything and gpmc-smsc911x.c should be able to completely ignore regulators.

Quoted 3 lines

So if that's the case, we might as well patch the board files to add the fixed regulators for each one and drop all the regulator code from gpmc-smsc911x.c.

That's my preferred option, hopefully with the helpers we have for regulator registration we shouldn't need to add device specific helpers.

Quoted 16 lines · Mark Brown

Quoted 7 lines · Tony Lindgren

Quoted 4 lines · Mark Brown

That should be changed to pass in a boolean flag rather than a pointer to platform device - the board may not have direct access to the relevant regulator (eg, if it's part of a MFD) or the regulator may be on another bus like I2C (for simpler regulator only devices).

Quoted 7 lines

Hmm I see. This means that we need to patch some board files anyways for the boolean flag to use the fixed regulator. This is because for some cases vddvario and vdd33a regulators can come from the mfd/tps/twl chip and it's unsafe to assume that gpmc-smsc911x.c can set up these regulators automatically. Passing a boolean flag to not set up the default regulator would work too, but we'd rather eventually see the real board specific regulators being patched in.

Quoted 2 lines

Yes, ideally the boards would do everything and gpmc-smsc911x.c should be able to completely ignore regulators.

OK, great, let's do that then.

Quoted 4 lines

Quoted 3 lines

So if that's the case, we might as well patch the board files to add the fixed regulators for each one and drop all the regulator code from gpmc-smsc911x.c.

Quoted 2 lines

That's my preferred option, hopefully with the helpers we have for regulator registration we shouldn't need to add device specific helpers.

Russ, care to update your patch accordingly? Those helpers are queued in linux-next.

Signed-off-by Russ Dill <[email protected]>

Quoted 1 line · Russ Dill

Signed-off-by Russ Dill <[email protected]>

I'll apply this once -rc1 comes out, it's totally orthogonal to the rest of the series.

Signed-off-by Russ Dill <[email protected]>

---

arch/arm/mach-omap2/board-ldp.c      |    7 +++++++
arch/arm/mach-omap2/board-omap3evm.c |    9 +++++++++

2 files changed, 16 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/board-ldp.c +7 -0

index d50a562a..1b60495 100644
@@ -22,6 +22,7 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/spi/spi.h>
+#include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/i2c/twl.h>
 #include <linux/io.h>

@@ -410,8 +411,14 @@ static struct mtd_partition ldp_nand_partitions[] = {
 
 };
 
+static struct regulator_consumer_supply dummy_supplies[] = {
+	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
+};
+
 static void __init omap_ldp_init(void)
 {
+	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	ldp_init_smsc911x();
 	omap_i2c_init();

arch/arm/mach-omap2/board-omap3evm.c +9 -0

index 548e1ef..a659e19 100644
@@ -114,6 +114,15 @@ static struct omap_smsc911x_platform_data smsc911x_cfg = {
 
 static inline void __init omap3evm_init_smsc911x(void)
 {
+	struct clk *l3ck;
+	unsigned int rate;
+
+	l3ck = clk_get(NULL, "l3_ck");
+	if (IS_ERR(l3ck))
+		rate = 100000000;
+	else
+		rate = clk_get_rate(l3ck);
+
 	/* Configure ethernet controller reset gpio */
 	if (cpu_is_omap3430()) {
 		if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)

Signature · 6 lines

1.7.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Signed-off-by Russ Dill <[email protected]>

---
arch/arm/mach-omap2/board-omap3evm.c | 15 ++++++---------

1 files changed, 6 insertions(+), 9 deletions(-)

arch/arm/mach-omap2/board-omap3evm.c +0 -0

index a659e19..6a5e57c 100644
@@ -114,15 +114,6 @@ static struct omap_smsc911x_platform_data smsc911x_cfg = {
 

Op 22 mrt. 2012, om 06:19 heeft Russ Dill het volgende geschreven:

Quoted 11 lines

Signed-off-by Russ Dill <[email protected]>

---
arch/arm/mach-omap2/board-omap3evm.c |   15 ++++++---------

1 files changed, 6 insertions(+), 9 deletions(-)

arch/arm/mach-omap2/board-omap3evm.c +0 -0

index a659e19..6a5e57c 100644
@@ -114,15 +114,6 @@ static struct omap_smsc911x_platform_data smsc911x_cfg = {
 

arch/arm/mach-omap2/board-omap3evm.c static struct omap_smsc911x_platform_data smsc911x_cfg = { · line 124

Quoted 10 lines

arch/arm/mach-omap2/board-omap3evm.c +0 -8

 static inline void __init omap3evm_init_smsc911x(void)
 {
-     struct clk *l3ck;
-     unsigned int rate;
-
-     l3ck = clk_get(NULL, "l3_ck");
-     if (IS_ERR(l3ck))
-             rate = 100000000;
-     else
-             rate = clk_get_rate(l3ck);

The above hunk gets added/removed multiple times during this patch series, a rebase -i mishap?

Quoted 3 lines · Russ Dill

+static struct regulator_consumer_supply dummy_supplies[] = {
+     REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+     REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),

Why do none of these boards use -1 as the ID for the device?

Quoted 6 lines · Mark Brown

Quoted 3 lines · Russ Dill

arch/arm/mach-omap2/board-zoom-debugboard.c +3 -0

+static struct regulator_consumer_supply dummy_supplies[] = {
+     REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+     REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),

Quoted 1 line

Why do none of these boards use -1 as the ID for the device?

Commit 21b42731 (omap: convert boards that use SMSC911x to use gpmc-smsc911x) changed several board files to use the gpmc-smsc911x.c common code rather than register the device themselves, in the process it changed many of the id's from -1 to 0. This happened in the 3.0 merge window. I can certainly change it back.