smsc911x on Gumstix Overo/Tobi doesn't work

smsc911x on Gumstix Overo/Tobi doesn't work

[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

"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.

Regards,
Thomas Klute

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Tony Lindgren]

Hi,

* Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
> 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.

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.
 
> 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 <tony@atomide.com>
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 <tony@atomide.com>

--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -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) {
--- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
+++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
@@ -19,6 +19,7 @@ struct omap_smsc911x_platform_data {
 	int	gpio_irq;
 	int	gpio_reset;
 	u32	flags;
+	struct platform_device *regulator;
 };
 
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Thomas Klute]

[-- Attachment #1: Type: text/plain, Size: 3745 bytes --]

Am 16.03.2012 20:33, schrieb Tony Lindgren:
> Hi,
> 
> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
>> 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.
> 
> 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.

>> 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?

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.

Regards,
Thomas

> 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 <tony@atomide.com>
> 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 <tony@atomide.com>
> 
> --- a/arch/arm/mach-omap2/gpmc-smsc911x.c
> +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
> @@ -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) {
> --- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
> +++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
> @@ -19,6 +19,7 @@ struct omap_smsc911x_platform_data {
>  	int	gpio_irq;
>  	int	gpio_reset;
>  	u32	flags;
> +	struct platform_device *regulator;
>  };
>  
>  #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)

[-- Attachment #2: smsc911x-unload-error.log --]
[-- Type: text/x-log, Size: 3268 bytes --]

du14:~# modprobe -r smsc911x
[  213.617767] Unable to handle kernel NULL pointer dereference at virtual address 0000073c
[  213.627044] pgd = d56b8000
[  213.630554] [0000073c] *pgd=00000000
[  213.634948] Internal error: Oops: 5 [#1]
[  213.639068] Modules linked in: ipt_MASQUERADE xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables ath9k_htc ath9k_common ath9k_hw carl9170 ath snd_soc_twl4030 smsc ohci_hcd ehci_hcd snd_soc_core regmap_spi regmap_i2c snd_pcm snd_timer smsc911x(-) libertas_sdio snd soundcore snd_page_alloc libertas twl4030_usb
[  213.671844] CPU: 0    Tainted: G        W     (3.3.0-rc7-11899-gb8fe178-dirty #103)
[  213.679901] PC is at regulator_bulk_disable+0x18/0x90
[  213.685211] LR is at smsc911x_drv_remove+0xd4/0xf4 [smsc911x]
[  213.691253] pc : [<c02395fc>]    lr : [<bf0599cc>]    psr: 80000013
[  213.691253] sp : d56b7ed8  ip : 00000002  fp : bea9fdb4
[  213.703277] r10: 00000738  r9 : d56b6000  r8 : 00000002
[  213.708770] r7 : d6c85408  r6 : 00000738  r5 : d6c85400  r4 : 00000000
[  213.715606] r3 : d6534500  r2 : 00000000  r1 : 00000738  r0 : 00000002
[  213.722442] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  213.729919] Control: 10c5387d  Table: 956b8019  DAC: 00000015
[  213.735961] Process modprobe (pid: 2395, stack limit = 0xd56b62f0)
[  213.742431] Stack: (0xd56b7ed8 to 0xd56b8000)
[  213.747009] 7ec0:                                                       d6534500 d6779000
[  213.755584] 7ee0: d6c85400 00000000 d6c85408 c000d484 00000000 bf0599cc bf0598f8 d6c85408
[  213.764160] 7f00: bf05b6dc d6c8543c 00000081 c02618d0 c02618bc c026041c d6c85408 bf05b6dc
[  213.772735] 7f20: d6c8543c c02609f0 bf05b6dc 00000000 c0664b08 c02602f8 bf05b718 00000000
[  213.781311] 7f40: b6f3b1b0 c0064db0 d6c48588 63736d73 78313139 c00a3b00 d6534500 00000001
[  213.789916] 7f60: 00000000 d6534500 00000001 c000d3d4 00000081 60000010 b6f3b208 bea9fdc0
[  213.798492] 7f80: bea9fdb4 0005e8c8 b6f3b180 b6f3b180 b6f3b1b0 00000000 b6f3b180 b6f3b180
[  213.807067] 7fa0: b6f3b1b0 c000d2c0 b6f3b180 b6f3b180 b6f3b1b0 00000000 b6f3a000 00000000
[  213.815643] 7fc0: b6f3b180 b6f3b180 b6f3b1b0 00000081 00000000 b6f3b208 bea9fdc0 bea9fdb4
[  213.824218] 7fe0: 00000000 bea9e990 b6f23988 b6e51b5c 60000010 b6f3b1b0 00000000 00000000
[  213.832824] [<c02395fc>] (regulator_bulk_disable+0x18/0x90) from [<bf0599cc>] (smsc911x_drv_remove+0xd4/0xf4 [smsc911x])
[  213.844268] [<bf0599cc>] (smsc911x_drv_remove+0xd4/0xf4 [smsc911x]) from [<c02618d0>] (platform_drv_remove+0x14/0x18)
[  213.855407] [<c02618d0>] (platform_drv_remove+0x14/0x18) from [<c026041c>] (__device_release_driver+0x7c/0xbc)
[  213.865905] [<c026041c>] (__device_release_driver+0x7c/0xbc) from [<c02609f0>] (driver_detach+0x8c/0xb4)
[  213.875885] [<c02609f0>] (driver_detach+0x8c/0xb4) from [<c02602f8>] (bus_remove_driver+0x8c/0xb4)
[  213.885284] [<c02602f8>] (bus_remove_driver+0x8c/0xb4) from [<c0064db0>] (sys_delete_module+0x1ec/0x280)
[  213.895233] [<c0064db0>] (sys_delete_module+0x1ec/0x280) from [<c000d2c0>] (ret_fast_syscall+0x0/0x3c)
[  213.904998] Code: e1a06001 e1a0a001 e3a04000 ea000006 (e59a0004) 
[  213.913635] ---[ end trace 3dd21d0e580906b5 ]---
Speicherzugriffsfehler
du14:~# 

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Tony Lindgren]

* Thomas Klute <thomas2.klute@uni-dortmund.de> [120319 09:26]:
> Am 16.03.2012 20:33, schrieb Tony Lindgren:
> > Hi,
> > 
> > * Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
> >> 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.
> > 
> > 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.
> 
> >> 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?
> 
> 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?
 
> 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.

Regards,

Tony

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Thomas Klute]

[-- Attachment #1: Type: text/plain, Size: 3213 bytes --]

Am 19.03.2012 23:51, schrieb Tony Lindgren:
> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120319 09:26]:
>> Am 16.03.2012 20:33, schrieb Tony Lindgren:
>>> Hi,
>>>
>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
>>>> 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.
>>>
>>> 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.
>>
>>>> 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?
>>
>> 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.

>> 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.

The NULL pointer dereference occurs with the unpatched kernel as well.
I've attached the log, although I don't see a major difference to the
one from the patched kernel. Note that this only happens when the driver
works properly (that is, eth0 is usable). I can unload the driver
without problems if it is not working as described above.

Regards,
Thomas

[-- Attachment #2: smsc911x-unload-error-unpatched.log --]
[-- Type: text/x-log, Size: 3224 bytes --]

[  286.276245] Unable to handle kernel NULL pointer dereference at virtual address 0000073c
[  286.285308] pgd = ce744000
[  286.288818] [0000073c] *pgd=00000000
[  286.293151] Internal error: Oops: 5 [#1]
[  286.297271] Modules linked in: ipt_MASQUERADE xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables snd_soc_twl4030 ath9k_htc ath9k_common ath9k_hw carl9170 ath ohci_hcd smsc libertas_sdio libertas snd_soc_core regmap_spi regmap_i2c snd_pcm snd_timer smsc911x(-) ehci_hcd snd soundcore snd_page_alloc twl4030_usb
[  286.330047] CPU: 0    Tainted: G        W     (3.3.0-rc7-11899-gb8fe178 #102)
[  286.337554] PC is at regulator_bulk_disable+0x18/0x90
[  286.342895] LR is at smsc911x_drv_remove+0xd4/0xf4 [smsc911x]
[  286.348907] pc : [<c02395fc>]    lr : [<bf03c9cc>]    psr: 80000013
[  286.348907] sp : ce6c7ed8  ip : 00000002  fp : becdfdb4
[  286.360961] r10: 00000738  r9 : ce6c6000  r8 : 00000002
[  286.366424] r7 : cec85408  r6 : 00000738  r5 : cec85400  r4 : 00000000
[  286.373260] r3 : ce628bc0  r2 : 00000000  r1 : 00000738  r0 : 00000002
[  286.380096] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  286.387603] Control: 10c5387d  Table: 8e744019  DAC: 00000015
[  286.393615] Process modprobe (pid: 2393, stack limit = 0xce6c62f0)
[  286.400085] Stack: (0xce6c7ed8 to 0xce6c8000)
[  286.404663] 7ec0:                                                       ce628bc0 ce615800
[  286.413238] 7ee0: cec85400 00000000 cec85408 c000d484 00000000 bf03c9cc bf03c8f8 cec85408
[  286.421813] 7f00: bf03e6dc cec8543c 00000081 c02618d0 c02618bc c026041c cec85408 bf03e6dc
[  286.430389] 7f20: cec8543c c02609f0 bf03e6dc 00000000 c0664b08 c02602f8 bf03e718 00000000
[  286.438995] 7f40: b6f581b0 c0064db0 ce484488 63736d73 78313139 c00a3b00 ce628bc0 00000001
[  286.447570] 7f60: 00000000 ce628bc0 00000001 c000d3d4 00000081 60000010 b6f58208 becdfdc0
[  286.456146] 7f80: becdfdb4 0005e8c8 b6f58180 b6f58180 b6f581b0 00000000 b6f58180 b6f58180
[  286.464721] 7fa0: b6f581b0 c000d2c0 b6f58180 b6f58180 b6f581b0 00000000 b6f57000 00000000
[  286.473297] 7fc0: b6f58180 b6f58180 b6f581b0 00000081 00000000 b6f58208 becdfdc0 becdfdb4
[  286.481872] 7fe0: 00000000 becde990 b6f40988 b6e6eb5c 60000010 b6f581b0 8f2fe821 8f2fec21
[  286.490478] [<c02395fc>] (regulator_bulk_disable+0x18/0x90) from [<bf03c9cc>] (smsc911x_drv_remove+0xd4/0xf4 [smsc911x])
[  286.501922] [<bf03c9cc>] (smsc911x_drv_remove+0xd4/0xf4 [smsc911x]) from [<c02618d0>] (platform_drv_remove+0x14/0x18)
[  286.513061] [<c02618d0>] (platform_drv_remove+0x14/0x18) from [<c026041c>] (__device_release_driver+0x7c/0xbc)
[  286.523590] [<c026041c>] (__device_release_driver+0x7c/0xbc) from [<c02609f0>] (driver_detach+0x8c/0xb4)
[  286.533538] [<c02609f0>] (driver_detach+0x8c/0xb4) from [<c02602f8>] (bus_remove_driver+0x8c/0xb4)
[  286.542938] [<c02602f8>] (bus_remove_driver+0x8c/0xb4) from [<c0064db0>] (sys_delete_module+0x1ec/0x280)
[  286.552917] [<c0064db0>] (sys_delete_module+0x1ec/0x280) from [<c000d2c0>] (ret_fast_syscall+0x0/0x3c)
[  286.562683] Code: e1a06001 e1a0a001 e3a04000 ea000006 (e59a0004) 
[  286.571838] ---[ end trace f0a226828d962479 ]---
Speicherzugriffsfehler

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Javier Martinez Canillas]

On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute
<thomas2.klute@uni-dortmund.de> wrote:
> Am 19.03.2012 23:51, schrieb Tony Lindgren:
>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120319 09:26]:
>>> Am 16.03.2012 20:33, schrieb Tony Lindgren:
>>>> Hi,
>>>>
>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
>>>>> 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.
>>>>
>>>> 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.
>>>
>>>>> 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?
>>>
>>> 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.
>

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 <javier@dowhile0.org>
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.

Hope it helps,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Thomas Klute]

Am 20.03.2012 20:47, schrieb Javier Martinez Canillas:
> On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute
> <thomas2.klute@uni-dortmund.de> wrote:
>> Am 19.03.2012 23:51, schrieb Tony Lindgren:
>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120319 09:26]:
>>>> Am 16.03.2012 20:33, schrieb Tony Lindgren:
>>>>> Hi,
>>>>>
>>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
>>>>>> 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.
>>>>>
>>>>> 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.
>>>>
>>>>>> 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?
>>>>
>>>> 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.
>>
> 
> 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 <javier@dowhile0.org>
> 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 Javier,

thanks for the hint. Deactivating CONFIG_SMSC_PHY didn't help, but I'll
look into activating USE_DEBUG later.

Regards,
Thomas

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Thomas Klute]

[-- Attachment #1: Type: text/plain, Size: 5340 bytes --]

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:
> On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute
> <thomas2.klute@uni-dortmund.de> wrote:
>> Am 19.03.2012 23:51, schrieb Tony Lindgren:
>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120319 09:26]:
>>>> Am 16.03.2012 20:33, schrieb Tony Lindgren:
>>>>> Hi,
>>>>>
>>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
>>>>>> 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.
>>>>>
>>>>> 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.
>>>>
>>>>>> 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?
>>>>
>>>> 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.
>>
> 
> 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 <javier@dowhile0.org>
> 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.

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

[-- Attachment #2: smsc911x-trace-nocable-without_phy.log --]
[-- Type: text/x-log, Size: 2069 bytes --]

[   33.119293] smsc911x: Driver version 2008-10-21
[   33.201568] smsc911x smsc911x.0: (unregistered net_device): Driver Parameters:
[   33.209289] smsc911x smsc911x.0: (unregistered net_device): LAN base: 0xD081E000
[   33.217102] smsc911x smsc911x.0: (unregistered net_device): IRQ: 336
[   33.223815] smsc911x smsc911x.0: (unregistered net_device): PHY will be autodetected.
[   33.232482] smsc911x smsc911x.0: (unregistered net_device): BYTE_TEST: 0x87654321
[   33.240417] smsc911x smsc911x.0: (unregistered net_device): LAN911x identified, idrev: 0x92210000, generation: 4
[   33.254852] smsc911x smsc911x.0: eth0: Network interface: "eth0"
[   33.261260] smsc911x smsc911x.0: eth0: External PHY is not supported, using internal PHY
[   33.868133] smsc911x-mdio: probed
[   33.871826] smsc911x smsc911x.0: eth0: PHY: addr 1, phy_id 0x0007C0C3
[   33.878875] smsc911x smsc911x.0: eth0: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=smsc911x-0:01, irq=-1)
[   33.890411] smsc911x smsc911x.0: eth0: smsc911x_phy_check_loopbackpkt: Failed to transmit during loopback test
[   33.901031] smsc911x smsc911x.0: eth0: Successfully verified loopback packet
[   33.908569] smsc911x smsc911x.0: eth0: Passed Loop Back Test
[   33.914550] smsc911x smsc911x.0: eth0: phy initialised successfully
[   33.921356] smsc911x smsc911x.0: eth0: MAC Address is set to random_ether_addr
[   33.928985] smsc911x smsc911x.0: eth0: MAC Address: 5a:ee:71:05:48:11
[   33.935913] smsc911x: Driver version 2008-10-21
[   33.940856] _regulator_get: smsc911x.1 supply vdd33a not found, using dummy regulator
[   33.949584] _regulator_get: smsc911x.1 supply vddvario not found, using dummy regulator
[   33.965057] smsc911x smsc911x.1: (unregistered net_device): Driver Parameters:
[   33.972778] smsc911x smsc911x.1: (unregistered net_device): LAN base: 0xD090A000
[   33.980590] smsc911x smsc911x.1: (unregistered net_device): IRQ: 225
[   33.987304] smsc911x smsc911x.1: (unregistered net_device): PHY will be autodetected.
[   34.094726] smsc911x: Device not READY in 100ms aborting

[-- Attachment #3: smsc911x-trace-nocable-with_phy.log --]
[-- Type: text/x-log, Size: 1681 bytes --]

[  150.724273] smsc911x: Driver version 2008-10-21
[  150.735870] smsc911x smsc911x.0: (unregistered net_device): Driver Parameters:
[  150.743591] smsc911x smsc911x.0: (unregistered net_device): LAN base: 0xD8A5C000
[  150.751403] smsc911x smsc911x.0: (unregistered net_device): IRQ: 336
[  150.758117] smsc911x smsc911x.0: (unregistered net_device): PHY will be autodetected.
[  150.766845] smsc911x smsc911x.0: (unregistered net_device): BYTE_TEST: 0x87654321
[  150.774780] smsc911x smsc911x.0: (unregistered net_device): LAN911x identified, idrev: 0x92210000, generation: 4
[  150.785644] smsc911x smsc911x.0: (unregistered net_device): smsc911x_soft_reset: Failed to complete reset
[  150.797027] smsc911x: Driver version 2008-10-21
[  150.802001] _regulator_get: smsc911x.1 supply vdd33a not found, using dummy regulator
[  150.811035] _regulator_get: smsc911x.1 supply vddvario not found, using dummy regulator
[  150.821990] smsc911x smsc911x.1: (unregistered net_device): Driver Parameters:
[  150.829925] smsc911x smsc911x.1: (unregistered net_device): LAN base: 0xD8A5E000
[  150.837738] smsc911x smsc911x.1: (unregistered net_device): IRQ: 225
[  150.844451] smsc911x smsc911x.1: (unregistered net_device): PHY will be autodetected.
[  150.852722] smsc911x smsc911x.1: (unregistered net_device): BYTE_TEST: 0x00050005
[  150.860626] smsc911x smsc911x.1: (unregistered net_device): smsc911x_init: BYTE_TEST: 0x00050005
[  150.869873] smsc911x smsc911x.1: (unregistered net_device): smsc911x_init: top 16 bits equal to bottom 16 bits
[  150.880401] smsc911x smsc911x.1: (unregistered net_device): This may mean the chip is set for 32 bit while the bus is reading 16 bit

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Javier Martinez Canillas]

On Fri, Mar 30, 2012 at 5:28 PM, Thomas Klute
<thomas2.klute@uni-dortmund.de> wrote:
> 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 :)

> Am 20.03.2012 20:47, schrieb Javier Martinez Canillas:
>> On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute
>> <thomas2.klute@uni-dortmund.de> wrote:
>>> Am 19.03.2012 23:51, schrieb Tony Lindgren:
>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120319 09:26]:
>>>>> Am 16.03.2012 20:33, schrieb Tony Lindgren:
>>>>>> Hi,
>>>>>>
>>>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
>>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>
>>>>>>> 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?
>>>>>
>>>>> 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.
>>>
>>
>> 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 <javier@dowhile0.org>
>> 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.
>
> 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).
>

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

> 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?

diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 24d2df0..d08709a 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -1349,7 +1349,7 @@ static int
smsc911x_phy_disable_energy_detect(struct smsc911x_data *
                        return rc;
                }

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

        return 0;


Best regards,
-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Thomas Klute]

Am 01.04.2012 21:20, schrieb Javier Martinez Canillas:
> On Fri, Mar 30, 2012 at 5:28 PM, Thomas Klute
> <thomas2.klute@uni-dortmund.de> wrote:
>> 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 :)
> 
>> Am 20.03.2012 20:47, schrieb Javier Martinez Canillas:
>>> On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute
>>> <thomas2.klute@uni-dortmund.de> wrote:
>>>> Am 19.03.2012 23:51, schrieb Tony Lindgren:
>>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120319 09:26]:
>>>>>> Am 16.03.2012 20:33, schrieb Tony Lindgren:
>>>>>>> Hi,
>>>>>>>
>>>>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
>>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>>> 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?
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> 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 <javier@dowhile0.org>
>>> 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.
>>
>> 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).
>>
> 
> This makes sense since is the PHY driver who enables the auto energy
> detect mode.
> 
>> 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?

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...)

> diff --git a/drivers/net/ethernet/smsc/smsc911x.c
> b/drivers/net/ethernet/smsc/smsc911x.c
> index 24d2df0..d08709a 100644
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
> @@ -1349,7 +1349,7 @@ static int
> smsc911x_phy_disable_energy_detect(struct smsc911x_data *
>                         return rc;
>                 }
> 
> -               mdelay(1);
> +               mdelay(100);
>         }
> 
>         return 0;
> 
> 
> Best regards,

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Javier Martinez Canillas]

On Wed, May 2, 2012 at 1:42 PM, Thomas Klute
<thomas2.klute@uni-dortmund.de> wrote:
> Am 01.04.2012 21:20, schrieb Javier Martinez Canillas:
>> On Fri, Mar 30, 2012 at 5:28 PM, Thomas Klute
>> <thomas2.klute@uni-dortmund.de> wrote:
>>> 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 :)
>>
>>> Am 20.03.2012 20:47, schrieb Javier Martinez Canillas:
>>>> On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute
>>>> <thomas2.klute@uni-dortmund.de> wrote:
>>>>> Am 19.03.2012 23:51, schrieb Tony Lindgren:
>>>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120319 09:26]:
>>>>>>> Am 16.03.2012 20:33, schrieb Tony Lindgren:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>>>> 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?
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>
>>>> 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 <javier@dowhile0.org>
>>>> 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.
>>>
>>> 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).
>>>
>>
>> This makes sense since is the PHY driver who enables the auto energy
>> detect mode.
>>
>>> 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?
>
> 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.

> (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,

>> diff --git a/drivers/net/ethernet/smsc/smsc911x.c
>> b/drivers/net/ethernet/smsc/smsc911x.c
>> index 24d2df0..d08709a 100644
>> --- a/drivers/net/ethernet/smsc/smsc911x.c
>> +++ b/drivers/net/ethernet/smsc/smsc911x.c
>> @@ -1349,7 +1349,7 @@ static int
>> smsc911x_phy_disable_energy_detect(struct smsc911x_data *
>>                         return rc;
>>                 }
>>
>> -               mdelay(1);
>> +               mdelay(100);
>>         }
>>
>>         return 0;
>>
>>
>> Best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Thomas Klute]

Am 03.05.2012 13:09, schrieb Javier Martinez Canillas:
> On Wed, May 2, 2012 at 1:42 PM, Thomas Klute
> <thomas2.klute@uni-dortmund.de> wrote:
>> Am 01.04.2012 21:20, schrieb Javier Martinez Canillas:
>>> On Fri, Mar 30, 2012 at 5:28 PM, Thomas Klute
>>> <thomas2.klute@uni-dortmund.de> wrote:
>>>> 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 :)
>>>
>>>> Am 20.03.2012 20:47, schrieb Javier Martinez Canillas:
>>>>> On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute
>>>>> <thomas2.klute@uni-dortmund.de> wrote:
>>>>>> Am 19.03.2012 23:51, schrieb Tony Lindgren:
>>>>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120319 09:26]:
>>>>>>>> Am 16.03.2012 20:33, schrieb Tony Lindgren:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> * Thomas Klute <thomas2.klute@uni-dortmund.de> [120316 05:08]:
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>
>>>>>>>> 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.
>>>>>>
>>>>>
>>>>> 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 <javier@dowhile0.org>
>>>>> 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.
>>>>
>>>> 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).
>>>>
>>>
>>> This makes sense since is the PHY driver who enables the auto energy
>>> detect mode.
>>>
>>>> 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?
>>
>> 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.
> 
>> (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.

Same here. :-( Anyways, thanks a lot for your help!

Best regards,
Thomas

> Best regards,
> 
>>> diff --git a/drivers/net/ethernet/smsc/smsc911x.c
>>> b/drivers/net/ethernet/smsc/smsc911x.c
>>> index 24d2df0..d08709a 100644
>>> --- a/drivers/net/ethernet/smsc/smsc911x.c
>>> +++ b/drivers/net/ethernet/smsc/smsc911x.c
>>> @@ -1349,7 +1349,7 @@ static int
>>> smsc911x_phy_disable_energy_detect(struct smsc911x_data *
>>>                         return rc;
>>>                 }
>>>
>>> -               mdelay(1);
>>> +               mdelay(100);
>>>         }
>>>
>>>         return 0;
>>>
>>>
>>> Best regards,
> 

[PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.

[Russ Dill]

Commit c7e963f6888816 (net/smsc911x: Add regulator support) breaks
registration of gpmc connected smcs911x devices on machines with
regulator support, but without dummy regulator support.

Commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add
required smsc911x regulators) fixed the issue for boards with single
smsc911x devices, but attempted to register the fixed voltage regulator
twice for boards with 2 devices which fails.

A proper fix needs to supply a proper regulator/consumer mapping for
each smsc911x device. The below patch does that. However, it also
points out how unmanageable things will become if regulators are required
for each and every device for the sake of the one board where they need
to be enabled.

In the case of the smsc911x driver, the ST-Ericsson Snowball has regulators
that need to be powered up for the smsc911x to function. Robert Marklund
added functionality to the smsc911x driver to power up its regulators at
probe time and power them off at remove time. One can see how quickly
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.

Incidentally, while the patch for the smsc911x regulators is in, it does not
appear that the patch for the snowball to supply these is in.

This patch has been compile tested, but not run tested.

Signed-off-by: Russ Dill <Russ.Dill@ti.com>
---
 arch/arm/mach-omap2/board-cm-t35.c              |   34 +++++-----
 arch/arm/mach-omap2/board-igep0020.c            |   15 +++--
 arch/arm/mach-omap2/board-ldp.c                 |   14 ++--
 arch/arm/mach-omap2/board-omap3evm.c            |   21 ++++--
 arch/arm/mach-omap2/board-omap3logic.c          |   18 +++--
 arch/arm/mach-omap2/board-omap3stalker.c        |   15 +++--
 arch/arm/mach-omap2/board-overo.c               |   32 +++++-----
 arch/arm/mach-omap2/board-zoom-debugboard.c     |   14 ++--
 arch/arm/mach-omap2/gpmc-smsc911x.c             |   79 +++++++++++++++++------
 arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |    6 +-
 10 files changed, 154 insertions(+), 94 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index d73316e..4090ca1 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -65,26 +65,28 @@
 #include <linux/smsc911x.h>
 #include <plat/gpmc-smsc911x.h>
 
-static struct omap_smsc911x_platform_data cm_t35_smsc911x_cfg = {
-	.id		= 0,
-	.cs             = CM_T35_SMSC911X_CS,
-	.gpio_irq       = CM_T35_SMSC911X_GPIO,
-	.gpio_reset     = -EINVAL,
-	.flags		= SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
-};
-
-static struct omap_smsc911x_platform_data sb_t35_smsc911x_cfg = {
-	.id		= 1,
-	.cs             = SB_T35_SMSC911X_CS,
-	.gpio_irq       = SB_T35_SMSC911X_GPIO,
-	.gpio_reset     = -EINVAL,
-	.flags		= SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
+static struct omap_smsc911x_platform_data cm_smsc911x_cfg[] = {
+	{
+		.id		= 0,
+		.cs             = CM_T35_SMSC911X_CS,
+		.gpio_irq       = CM_T35_SMSC911X_GPIO,
+		.gpio_reset     = -EINVAL,
+		.flags		= SMSC911X_USE_32BIT
+				| SMSC911X_SAVE_MAC_ADDRESS,
+	},
+	{
+		.id		= 1,
+		.cs             = SB_T35_SMSC911X_CS,
+		.gpio_irq       = SB_T35_SMSC911X_GPIO,
+		.gpio_reset     = -EINVAL,
+		.flags		= SMSC911X_USE_32BIT
+				| SMSC911X_SAVE_MAC_ADDRESS,
+	}
 };
 
 static void __init cm_t35_init_ethernet(void)
 {
-	gpmc_smsc911x_init(&cm_t35_smsc911x_cfg);
-	gpmc_smsc911x_init(&sb_t35_smsc911x_cfg);
+	gpmc_smsc911x_init(cm_smsc911x_cfg, ARRAY_SIZE(cm_smsc911x_cfg));
 }
 #else
 static inline void __init cm_t35_init_ethernet(void) { return; }
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index a59ace0..b5523b5 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -206,16 +206,19 @@ static void __init igep_flash_init(void) {}
 #include <linux/smsc911x.h>
 #include <plat/gpmc-smsc911x.h>
 
-static struct omap_smsc911x_platform_data smsc911x_cfg = {
-	.cs             = IGEP2_SMSC911X_CS,
-	.gpio_irq       = IGEP2_SMSC911X_GPIO,
-	.gpio_reset     = -EINVAL,
-	.flags		= SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
+static struct omap_smsc911x_platform_data smsc911x_cfg[] = {
+	{
+		.cs             = IGEP2_SMSC911X_CS,
+		.gpio_irq       = IGEP2_SMSC911X_GPIO,
+		.gpio_reset     = -EINVAL,
+		.flags		= SMSC911X_USE_32BIT
+				| SMSC911X_SAVE_MAC_ADDRESS,
+	},
 };
 
 static inline void __init igep2_init_smsc911x(void)
 {
-	gpmc_smsc911x_init(&smsc911x_cfg);
+	gpmc_smsc911x_init(smsc911x_cfg, ARRAY_SIZE(smsc911x_cfg));
 }
 
 #else
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 2d2a61f..af67098 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -171,16 +171,18 @@ static struct platform_device ldp_gpio_keys_device = {
 	},
 };
 
-static struct omap_smsc911x_platform_data smsc911x_cfg = {
-	.cs             = LDP_SMSC911X_CS,
-	.gpio_irq       = LDP_SMSC911X_GPIO,
-	.gpio_reset     = -EINVAL,
-	.flags		= SMSC911X_USE_32BIT,
+static struct omap_smsc911x_platform_data smsc911x_cfg[] = {
+	{
+		.cs             = LDP_SMSC911X_CS,
+		.gpio_irq       = LDP_SMSC911X_GPIO,
+		.gpio_reset     = -EINVAL,
+		.flags		= SMSC911X_USE_32BIT,
+	},
 };
 
 static inline void __init ldp_init_smsc911x(void)
 {
-	gpmc_smsc911x_init(&smsc911x_cfg);
+	gpmc_smsc911x_init(smsc911x_cfg, ARRAY_SIZE(smsc911x_cfg));
 }
 
 /* LCD */
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index c877236..76543b3 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -105,11 +105,14 @@ static void __init omap3_evm_get_revision(void)
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
 #include <plat/gpmc-smsc911x.h>
 
-static struct omap_smsc911x_platform_data smsc911x_cfg = {
-	.cs             = OMAP3EVM_SMSC911X_CS,
-	.gpio_irq       = OMAP3EVM_ETHR_GPIO_IRQ,
-	.gpio_reset     = -EINVAL,
-	.flags		= SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
+static struct omap_smsc911x_platform_data smsc911x_cfg[] = {
+	{
+		.cs             = OMAP3EVM_SMSC911X_CS,
+		.gpio_irq       = OMAP3EVM_ETHR_GPIO_IRQ,
+		.gpio_reset     = -EINVAL,
+		.flags		= SMSC911X_USE_32BIT
+				| SMSC911X_SAVE_MAC_ADDRESS,
+	},
 };
 
 static inline void __init omap3evm_init_smsc911x(void)
@@ -126,12 +129,14 @@ static inline void __init omap3evm_init_smsc911x(void)
 	/* Configure ethernet controller reset gpio */
 	if (cpu_is_omap3430()) {
 		if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
-			smsc911x_cfg.gpio_reset = OMAP3EVM_GEN1_ETHR_GPIO_RST;
+			smsc911x_cfg[0].gpio_reset =
+				OMAP3EVM_GEN1_ETHR_GPIO_RST;
 		else
-			smsc911x_cfg.gpio_reset = OMAP3EVM_GEN2_ETHR_GPIO_RST;
+			smsc911x_cfg[0].gpio_reset =
+				OMAP3EVM_GEN2_ETHR_GPIO_RST;
 	}
 
-	gpmc_smsc911x_init(&smsc911x_cfg);
+	gpmc_smsc911x_init(smsc911x_cfg, ARRAY_SIZE(smsc911x_cfg));
 }
 
 #else
diff --git a/arch/arm/mach-omap2/board-omap3logic.c b/arch/arm/mach-omap2/board-omap3logic.c
index 4198dd0..20b3cd2 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -131,10 +131,12 @@ static void __init board_mmc_init(void)
 	omap2_hsmmc_init(board_mmc_info);
 }
 
-static struct omap_smsc911x_platform_data __initdata board_smsc911x_data = {
-	.cs             = OMAP3LOGIC_SMSC911X_CS,
-	.gpio_irq       = -EINVAL,
-	.gpio_reset     = -EINVAL,
+static struct omap_smsc911x_platform_data __initdata board_smsc911x_data[] = {
+	{
+		.cs             = OMAP3LOGIC_SMSC911X_CS,
+		.gpio_irq       = -EINVAL,
+		.gpio_reset     = -EINVAL,
+	},
 };
 
 /* TODO/FIXME (comment by Peter Barada, LogicPD):
@@ -166,12 +168,13 @@ static inline void __init board_smsc911x_init(void)
 {
 	if (machine_is_omap3530_lv_som()) {
 		/* OMAP3530 LV SOM board */
-		board_smsc911x_data.gpio_irq =
+		board_smsc911x_data[0].gpio_irq =
 					OMAP3530_LV_SOM_SMSC911X_GPIO_IRQ;
 		omap_mux_init_signal("gpio_152", OMAP_PIN_INPUT);
 	} else if (machine_is_omap3_torpedo()) {
 		/* OMAP3 Torpedo board */
-		board_smsc911x_data.gpio_irq = OMAP3_TORPEDO_SMSC911X_GPIO_IRQ;
+		board_smsc911x_data[0].gpio_irq =
+					OMAP3_TORPEDO_SMSC911X_GPIO_IRQ;
 		omap_mux_init_signal("gpio_129", OMAP_PIN_INPUT);
 	} else {
 		/* unsupported board */
@@ -179,7 +182,8 @@ static inline void __init board_smsc911x_init(void)
 		return;
 	}
 
-	gpmc_smsc911x_init(&board_smsc911x_data);
+	gpmc_smsc911x_init(board_smsc911x_data,
+		ARRAY_SIZE(board_smsc911x_data));
 }
 
 #ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index cb089a4..0489826 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -63,11 +63,14 @@
 #define OMAP3STALKER_ETHR_GPIO_IRQ	19
 #define OMAP3STALKER_SMC911X_CS	5
 
-static struct omap_smsc911x_platform_data smsc911x_cfg = {
-	.cs             = OMAP3STALKER_SMC911X_CS,
-	.gpio_irq       = OMAP3STALKER_ETHR_GPIO_IRQ,
-	.gpio_reset     = -EINVAL,
-	.flags		= (SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS),
+static struct omap_smsc911x_platform_data smsc911x_cfg[] = {
+	{
+		.cs             = OMAP3STALKER_SMC911X_CS,
+		.gpio_irq       = OMAP3STALKER_ETHR_GPIO_IRQ,
+		.gpio_reset     = -EINVAL,
+		.flags		= SMSC911X_USE_32BIT
+				| SMSC911X_SAVE_MAC_ADDRESS,
+	},
 };
 
 static inline void __init omap3stalker_init_eth(void)
@@ -82,7 +85,7 @@ static inline void __init omap3stalker_init_eth(void)
 		rate = clk_get_rate(l3ck);
 
 	omap_mux_init_gpio(19, OMAP_PIN_INPUT_PULLUP);
-	gpmc_smsc911x_init(&smsc911x_cfg);
+	gpmc_smsc911x_init(smsc911x_cfg, ARRAY_SIZE(smsc911x_cfg));
 }
 
 #else
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 52c0cef..f4f5b7a 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -118,26 +118,26 @@ static inline void __init overo_ads7846_init(void) { return; }
 #include <linux/smsc911x.h>
 #include <plat/gpmc-smsc911x.h>
 
-static struct omap_smsc911x_platform_data smsc911x_cfg = {
-	.id		= 0,
-	.cs             = OVERO_SMSC911X_CS,
-	.gpio_irq       = OVERO_SMSC911X_GPIO,
-	.gpio_reset     = -EINVAL,
-	.flags		= SMSC911X_USE_32BIT,
-};
-
-static struct omap_smsc911x_platform_data smsc911x2_cfg = {
-	.id		= 1,
-	.cs             = OVERO_SMSC911X2_CS,
-	.gpio_irq       = OVERO_SMSC911X2_GPIO,
-	.gpio_reset     = -EINVAL,
-	.flags		= SMSC911X_USE_32BIT,
+static struct omap_smsc911x_platform_data smsc911x_cfg[] = {
+	{
+		.id		= 0,
+		.cs             = OVERO_SMSC911X_CS,
+		.gpio_irq       = OVERO_SMSC911X_GPIO,
+		.gpio_reset     = -EINVAL,
+		.flags		= SMSC911X_USE_32BIT,
+	},
+	{
+		.id		= 1,
+		.cs             = OVERO_SMSC911X2_CS,
+		.gpio_irq       = OVERO_SMSC911X2_GPIO,
+		.gpio_reset     = -EINVAL,
+		.flags		= SMSC911X_USE_32BIT,
+	}
 };
 
 static void __init overo_init_smsc911x(void)
 {
-	gpmc_smsc911x_init(&smsc911x_cfg);
-	gpmc_smsc911x_init(&smsc911x2_cfg);
+	gpmc_smsc911x_init(smsc911x_cfg, ARRAY_SIZE(smsc911x_cfg));
 }
 
 #else
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c b/arch/arm/mach-omap2/board-zoom-debugboard.c
index 369c2eb..8860dac 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -28,16 +28,18 @@
 #define DEBUG_BASE		0x08000000
 #define ZOOM_ETHR_START	DEBUG_BASE
 
-static struct omap_smsc911x_platform_data zoom_smsc911x_cfg = {
-	.cs             = ZOOM_SMSC911X_CS,
-	.gpio_irq       = ZOOM_SMSC911X_GPIO,
-	.gpio_reset     = -EINVAL,
-	.flags		= SMSC911X_USE_32BIT,
+static struct omap_smsc911x_platform_data zoom_smsc911x_cfg[] = {
+	{
+		.cs             = ZOOM_SMSC911X_CS,
+		.gpio_irq       = ZOOM_SMSC911X_GPIO,
+		.gpio_reset     = -EINVAL,
+		.flags		= SMSC911X_USE_32BIT,
+	},
 };
 
 static inline void __init zoom_init_smsc911x(void)
 {
-	gpmc_smsc911x_init(&zoom_smsc911x_cfg);
+	gpmc_smsc911x_init(zoom_smsc911x_cfg, ARRAY_SIZE(zoom_smsc911x_cfg));
 }
 
 static struct plat_serial8250_port serial_platform_data[] = {
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..9085fcf 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -26,8 +26,6 @@
 #include <plat/gpmc.h>
 #include <plat/gpmc-smsc911x.h>
 
-static struct omap_smsc911x_platform_data *gpmc_cfg;
-
 static struct resource gpmc_smsc911x_resources[] = {
 	[0] = {
 		.flags		= IORESOURCE_MEM,
@@ -41,12 +39,6 @@ static struct smsc911x_platform_config gpmc_smsc911x_config = {
 	.phy_interface	= PHY_INTERFACE_MODE_MII,
 	.irq_polarity	= SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
 	.irq_type	= SMSC911X_IRQ_TYPE_OPEN_DRAIN,
-	.flags		= SMSC911X_USE_16BIT,
-};
-
-static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
-	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
-	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
 };
 
 /* Generic regulator definition to satisfy smsc911x */
@@ -59,8 +51,6 @@ static struct regulator_init_data gpmc_smsc911x_reg_init_data = {
 		.valid_ops_mask		= REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies	= ARRAY_SIZE(gpmc_smsc911x_supply),
-	.consumer_supplies	= gpmc_smsc911x_supply,
 };
 
 static struct fixed_voltage_config gpmc_smsc911x_fixed_reg_data = {
@@ -93,20 +83,13 @@ static struct platform_device gpmc_smsc911x_regulator = {
  * assume that pin multiplexing is done in the board-*.c file,
  * or in the bootloader.
  */
-void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *board_data)
+static void __init gpmc_smsc911x_init_one(
+		struct omap_smsc911x_platform_data *gpmc_cfg)
 {
 	struct platform_device *pdev;
 	unsigned long cs_mem_base;
 	int ret;
 
-	gpmc_cfg = board_data;
-
-	ret = platform_device_register(&gpmc_smsc911x_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) {
 		pr_err("Failed to request GPMC mem region\n");
 		return;
@@ -136,8 +119,7 @@ void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *board_data)
 		gpio_set_value(gpmc_cfg->gpio_reset, 1);
 	}
 
-	if (gpmc_cfg->flags)
-		gpmc_smsc911x_config.flags = gpmc_cfg->flags;
+	gpmc_smsc911x_config.flags = gpmc_cfg->flags ? : SMSC911X_USE_16BIT;
 
 	pdev = platform_device_register_resndata(NULL, "smsc911x", gpmc_cfg->id,
 		 gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
@@ -157,3 +139,58 @@ free1:
 
 	pr_err("Could not initialize smsc911x device\n");
 }
+
+static const char * const smsc911x_refs[] = {
+	"vddvario",
+	"vdd33a",
+};
+
+void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *board_data,
+		unsigned int num)
+{
+	int ret;
+	int i;
+	struct regulator_consumer_supply *supplies;
+
+	supplies = kcalloc(ARRAY_SIZE(smsc911x_refs) * num,
+			sizeof(struct regulator_consumer_supply), GFP_KERNEL);
+	if (!supplies) {
+		pr_err("Failed to allocate memory\n");
+		return;
+	}
+
+	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);
+		if (!name) {
+			pr_err("Failed to allocate memory\n");
+			goto out;
+		}
+
+		supplies[i].dev_name = name;
+		supplies[i].supply = smsc911x_refs[i % num];
+	}
+
+	gpmc_smsc911x_reg_init_data.num_consumer_supplies = num;
+	gpmc_smsc911x_reg_init_data.consumer_supplies = supplies;
+
+	ret = platform_device_register(&gpmc_smsc911x_regulator);
+	if (ret < 0) {
+		pr_err("Unable to register smsc911x regulators: %d\n", ret);
+		goto out;
+	}
+
+	for (i = 0; i < num; i++)
+		gpmc_smsc911x_init_one(&board_data[i]);
+
+out:
+	for (i = 0; i < ARRAY_SIZE(smsc911x_refs) * num; i++)
+		kfree(supplies[i].dev_name);
+	kfree(supplies);
+}
diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
index ea6c9c8..16c709f 100644
--- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
+++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
@@ -23,11 +23,13 @@ struct omap_smsc911x_platform_data {
 
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
 
-extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
+extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d,
+	unsigned int num);
 
 #else
 
-static inline void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d)
+static inline void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d,
+	unsigned int num)
 {
 }
 
-- 
1.7.9.1

Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

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

> 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.

> +	supplies = kcalloc(ARRAY_SIZE(smsc911x_refs) * num,
> +			sizeof(struct regulator_consumer_supply), GFP_KERNEL);
> +	if (!supplies) {
> +		pr_err("Failed to allocate memory\n");
> +		return;
> +	}
> +
> +	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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.

[Porter, Matt]

On Mar 21, 2012, at 2:13 PM, Mark Brown wrote:

> On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:
> 
>> 
>> +	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.

The original patch for the problem was specific to the fixed regulator
on the OMAP3EVM/AMDM37xxEVM board...it was rejected. I was asked to
put something generic in gpmc-smsc911x.c like this.

-Matt

Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.

[Porter, Matt]

On Mar 21, 2012, at 2:13 PM, Mark Brown wrote:

> On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:
> 
>> 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

-Matt

Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.

[Tony Lindgren]

* Porter, Matt <mporter@ti.com> [120321 11:27]:
> 
> On Mar 21, 2012, at 2:13 PM, Mark Brown wrote:
> 
> > On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:
> > 
> >> 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.

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.
 
> 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

Regards,

Tony

Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

On Wed, Mar 21, 2012 at 11:39:57AM -0700, Tony Lindgren wrote:
> * Porter, Matt <mporter@ti.com> [120321 11:27]:

> > > 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.

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.

> > 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.

> 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

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).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [120321 12:03]:
> On Wed, Mar 21, 2012 at 11:39:57AM -0700, Tony Lindgren wrote:
> > * Porter, Matt <mporter@ti.com> [120321 11:27]:
> 
> > > > 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.
> 
> 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.

Right I guess that's a one liner macro now.

> > > 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.
> 
> > 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
> 
> 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.

Regards,

Tony

Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Wed, Mar 21, 2012 at 12:30:47PM -0700, Tony Lindgren wrote:
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [120321 12:03]:

> > 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.

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

> 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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [120321 12:41]:
> On Wed, Mar 21, 2012 at 12:30:47PM -0700, Tony Lindgren wrote:
> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [120321 12:03]:
> 
> > > 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.
> 
> 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.
 
> > 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.

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

Regards,

Tony

Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.

[Russ Dill]

On Wed, Mar 21, 2012 at 12:41 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [120321 12:41]:
>> On Wed, Mar 21, 2012 at 12:30:47PM -0700, Tony Lindgren wrote:
>> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [120321 12:03]:
>>
>> > > 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.
>>
>> 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.
>
>> > 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.
>
> Russ, care to update your patch accordingly? Those helpers are queued
> in linux-next.
>

No problem.

[PATCH 00/13] Fixup gmpc smsc911x regulator handling

[Russ Dill]

This patchset cleans up some problems with gpmc connected smsc911x
chips. Commit c7e963f6888816 (net/smsc911x: Add regulator support)
broke registration of gpmc connected smcs911x devices on machines with
regulator support, but without dummy regulator support by requiring
regulators.

Commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) fixed the issue for boards with single smsc911x devices,
but attempted to register the fixed voltage regulator twice for boards
with 2 devices which fails.

bb60424af5 (ARM: OMAP2+: gpmc-smsc911x: only register regulator for
first instance) cleaned this up a little bit by only automatically
registering regulators for the first device, but still did not allow
the second device to function because it lacked regulators.

The new patchset pushes register regulation back to where it belongs, 
in the board files. It eliminates a lot of boilerplate by utilizing
the new regulator_register_fixed function.

Additionally, there are 4 cleanup patches in this patch series. One is
a kdoc fix for regulator_register_fixed, 1 is a fix for potential
stale data usage in gpmc-smsc911x, another removes dead code, and the
final one eliminates an unneeded static variable in gpmc-smsc911x.

These patches have been compile tested on next-20120321 with an  
additional patch to fix the omap boot failures and have been tested
on omap3evm (am37x-evm) hardware.

Russ Dill (13):
  Remove odd gpmc_cfg/board_data redirection.
  Fix possible stale smsc911x flags.
  Remove unused rate calculation.
  Remove non-existent parameter from fixed-helper.c kernel doc.
  Remove regulator support from gmpc-smsc911x
  Add dummy smsc911x regulators to cm-t35.
  Add dummy smsc911x regulators to igep0020.
  Add dummy smsc911x regulators to ldp.
  Add dummy smsc911x regulators to omap3evm.
  Add dummy smsc911x regulators to omap3logic.
  Add dummy smsc911x regulators to omap3stalker.
  Add dummy smsc911x regulators to overo.
  Add dummy smsc911x regulators to zoom-debugboard.

 arch/arm/mach-omap2/board-cm-t35.c          |    9 ++++
 arch/arm/mach-omap2/board-igep0020.c        |    6 +++
 arch/arm/mach-omap2/board-ldp.c             |    7 +++
 arch/arm/mach-omap2/board-omap3evm.c        |   15 +++----
 arch/arm/mach-omap2/board-omap3logic.c      |    7 +++
 arch/arm/mach-omap2/board-omap3stalker.c    |   16 +++----
 arch/arm/mach-omap2/board-overo.c           |    8 +++
 arch/arm/mach-omap2/board-zoom-debugboard.c |    9 ++++
 arch/arm/mach-omap2/gpmc-smsc911x.c         |   65 +--------------------------
 drivers/regulator/fixed-helper.c            |    1 -
 10 files changed, 61 insertions(+), 82 deletions(-)

-- 
1.7.9.1

[PATCH 01/13] Remove odd gpmc_cfg/board_data redirection.

[Russ Dill]

This seems to be a leftover from when gpmc-smsc911x.c was copied
from gpmc-smc91x.c.

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/gpmc-smsc911x.c |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 5e5880d..aa0c296 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -26,8 +26,6 @@
 #include <plat/gpmc.h>
 #include <plat/gpmc-smsc911x.h>
 
-static struct omap_smsc911x_platform_data *gpmc_cfg;
-
 static struct resource gpmc_smsc911x_resources[] = {
 	[0] = {
 		.flags		= IORESOURCE_MEM,
@@ -93,14 +91,12 @@ static struct platform_device gpmc_smsc911x_regulator = {
  * assume that pin multiplexing is done in the board-*.c file,
  * or in the bootloader.
  */
-void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *board_data)
+void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
 {
 	struct platform_device *pdev;
 	unsigned long cs_mem_base;
 	int ret;
 
-	gpmc_cfg = board_data;
-
 	if (!gpmc_cfg->id) {
 		ret = platform_device_register(&gpmc_smsc911x_regulator);
 		if (ret < 0) {
-- 
1.7.9.1

[PATCH 02/13] Fix possible stale smsc911x flags.

[Russ Dill]

If this function is called the first time with flags set, and the
second time without flags set then the leftover flags from the first
called will be used rather than the desired default flags.

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/gpmc-smsc911x.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
index aa0c296..f9446ea 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -39,7 +39,6 @@ static struct smsc911x_platform_config gpmc_smsc911x_config = {
 	.phy_interface	= PHY_INTERFACE_MODE_MII,
 	.irq_polarity	= SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
 	.irq_type	= SMSC911X_IRQ_TYPE_OPEN_DRAIN,
-	.flags		= SMSC911X_USE_16BIT,
 };
 
 static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
@@ -135,8 +134,7 @@ void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
 		gpio_set_value(gpmc_cfg->gpio_reset, 1);
 	}
 
-	if (gpmc_cfg->flags)
-		gpmc_smsc911x_config.flags = gpmc_cfg->flags;
+	gpmc_smsc911x_config.flags = gpmc_cfg->flags ? : SMSC911X_USE_16BIT;
 
 	pdev = platform_device_register_resndata(NULL, "smsc911x", gpmc_cfg->id,
 		 gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
-- 
1.7.9.1

[PATCH 03/13] Remove unused rate calculation.

[Russ Dill]

Looking back into git history, this code was never used and was
probably left over from a copy/paste.

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/board-omap3evm.c     |    9 ---------
 arch/arm/mach-omap2/board-omap3stalker.c |    9 ---------
 2 files changed, 0 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index a659e19..548e1ef 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -114,15 +114,6 @@ 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)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index 6410043..de95352 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -72,15 +72,6 @@ static struct omap_smsc911x_platform_data smsc911x_cfg = {
 
 static inline void __init omap3stalker_init_eth(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);
-
 	omap_mux_init_gpio(19, OMAP_PIN_INPUT_PULLUP);
 	gpmc_smsc911x_init(&smsc911x_cfg);
 }
-- 
1.7.9.1

[PATCH 04/13] Remove non-existent parameter from fixed-helper.c kernel doc.

[Russ Dill]

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 drivers/regulator/fixed-helper.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/regulator/fixed-helper.c b/drivers/regulator/fixed-helper.c
index 30d0a15..961e2c9 100644
--- a/drivers/regulator/fixed-helper.c
+++ b/drivers/regulator/fixed-helper.c
@@ -18,7 +18,6 @@ static void regulator_fixed_release(struct device *dev)
 
 /**
  * regulator_register_fixed - register a no-op fixed regulator
- * @name: supply name
  * @id: platform device id
  * @supplies: consumers for this regulator
  * @num_supplies: number of consumers
-- 
1.7.9.1

Re: [PATCH 04/13] Remove non-existent parameter from fixed-helper.c kernel doc.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 194 bytes --]

On Wed, Mar 21, 2012 at 10:19:45PM -0700, Russ Dill wrote:
> Signed-off-by: Russ Dill <russ.dill@ti.com>

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 04/13] Remove non-existent parameter from fixed-helper.c kernel doc.

[Russ Dill]

On Thu, Mar 22, 2012 at 4:36 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, Mar 21, 2012 at 10:19:45PM -0700, Russ Dill wrote:
>> Signed-off-by: Russ Dill <russ.dill@ti.com>
>
> I'll apply this once -rc1 comes out, it's totally orthogonal to the rest
> of the series.

I'll drop it from the patch series on the next resend then.

[PATCH 05/13] Remove regulator support from gmpc-smsc911x

[Russ Dill]

Adding in support for regulators here creates several headaches.
 - Boards that declare their own regulator cannot use this function.
 - Multiple calls to this function require special handling.
 - Boards that declare id's other than '0' need special handling.

Now that there is a simple regulator_register_fixed, we can push
this registration back into the board files.

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/gpmc-smsc911x.c |   55 -----------------------------------
 1 files changed, 0 insertions(+), 55 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
index f9446ea..b6c77be 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -19,8 +19,6 @@
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/smsc911x.h>
-#include <linux/regulator/fixed.h>
-#include <linux/regulator/machine.h>
 
 #include <plat/board.h>
 #include <plat/gpmc.h>
@@ -41,50 +39,6 @@ static struct smsc911x_platform_config gpmc_smsc911x_config = {
 	.irq_type	= SMSC911X_IRQ_TYPE_OPEN_DRAIN,
 };
 
-static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
-	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
-	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
-};
-
-/* Generic regulator definition to satisfy smsc911x */
-static struct regulator_init_data gpmc_smsc911x_reg_init_data = {
-	.constraints = {
-		.min_uV			= 3300000,
-		.max_uV			= 3300000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-	.num_consumer_supplies	= ARRAY_SIZE(gpmc_smsc911x_supply),
-	.consumer_supplies	= gpmc_smsc911x_supply,
-};
-
-static struct fixed_voltage_config gpmc_smsc911x_fixed_reg_data = {
-	.supply_name		= "gpmc_smsc911x",
-	.microvolts		= 3300000,
-	.gpio			= -EINVAL,
-	.startup_delay		= 0,
-	.enable_high		= 0,
-	.enabled_at_boot	= 1,
-	.init_data		= &gpmc_smsc911x_reg_init_data,
-};
-
-/*
- * Platform device id of 42 is a temporary fix to avoid conflicts
- * with other reg-fixed-voltage devices. The real fix should
- * involve the driver core providing a way of dynamically
- * assigning a unique id on registration for platform devices
- * in the same name space.
- */
-static struct platform_device gpmc_smsc911x_regulator = {
-	.name		= "reg-fixed-voltage",
-	.id		= 42,
-	.dev = {
-		.platform_data	= &gpmc_smsc911x_fixed_reg_data,
-	},
-};
-
 /*
  * Initialize smsc911x device connected to the GPMC. Note that we
  * assume that pin multiplexing is done in the board-*.c file,
@@ -96,15 +50,6 @@ void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
 	unsigned long cs_mem_base;
 	int ret;
 
-	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_cs_request(gpmc_cfg->cs, SZ_16M, &cs_mem_base) < 0) {
 		pr_err("Failed to request GPMC mem region\n");
 		return;
-- 
1.7.9.1

[PATCH 06/13] Add dummy smsc911x regulators to cm-t35.

[Russ Dill]

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/board-cm-t35.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index 41b0a2f..289ded3 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -26,6 +26,7 @@
 
 #include <linux/i2c/at24.h>
 #include <linux/i2c/twl.h>
+#include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/mmc/host.h>
 
@@ -630,10 +631,18 @@ static inline void cm_t3730_init_mux(void) {}
 static struct omap_board_config_kernel cm_t35_config[] __initdata = {
 };
 
+static struct regulator_consumer_supply dummy_supplies[] = {
+	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
+	REGULATOR_SUPPLY("vddvario", "smsc911x.1"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x.1"),
+};
+
 static void __init cm_t3x_common_init(void)
 {
 	omap_board_config = cm_t35_config;
 	omap_board_config_size = ARRAY_SIZE(cm_t35_config);
+	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CUS);
 	omap_serial_init();
 	omap_sdrc_init(mt46h32m32lf6_sdrc_params,
-- 
1.7.9.1

[PATCH 07/13] Add dummy smsc911x regulators to igep0020.

[Russ Dill]

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/board-igep0020.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index e558800..930c0d3 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -634,8 +634,14 @@ static void __init igep_wlan_bt_init(void)
 static inline void __init igep_wlan_bt_init(void) { }
 #endif
 
+static struct regulator_consumer_supply dummy_supplies[] = {
+	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
+};
+
 static void __init igep_init(void)
 {
+	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 
 	/* Get IGEP2 hardware revision */
-- 
1.7.9.1

[PATCH 08/13] Add dummy smsc911x regulators to ldp.

[Russ Dill]

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/board-ldp.c      |    7 +++++++
 arch/arm/mach-omap2/board-omap3evm.c |    9 +++++++++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index d50a562a..1b60495 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -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();
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 548e1ef..a659e19 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -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)
-- 
1.7.9.1

Re: [PATCH 08/13] Add dummy smsc911x regulators to ldp.

[Koen Kooi]

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

> Signed-off-by: Russ Dill <russ.dill@ti.com>
> ---
> arch/arm/mach-omap2/board-ldp.c      |    7 +++++++
> arch/arm/mach-omap2/board-omap3evm.c |    9 +++++++++

Is that evm hunk intentional?

regards,

Koen

> 2 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
> index d50a562a..1b60495 100644
> --- a/arch/arm/mach-omap2/board-ldp.c
> +++ b/arch/arm/mach-omap2/board-ldp.c
> @@ -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();
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
> index 548e1ef..a659e19 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -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)
> -- 
> 1.7.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH 09/13] Add dummy smsc911x regulators to omap3evm.

[Russ Dill]

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/board-omap3evm.c |   15 ++++++---------
 1 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index a659e19..6a5e57c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -114,15 +114,6 @@ 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)
@@ -632,9 +623,15 @@ static void __init omap3_evm_wl12xx_init(void)
 #endif
 }
 
+static struct regulator_consumer_supply dummy_supplies[] = {
+	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
+};
+
 static void __init omap3_evm_init(void)
 {
 	omap3_evm_get_revision();
+	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
 
 	if (cpu_is_omap3630())
 		omap3_mux_init(omap36x_board_mux, OMAP_PACKAGE_CBB);
-- 
1.7.9.1

Re: [PATCH 09/13] Add dummy smsc911x regulators to omap3evm.

[Koen Kooi]

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

> Signed-off-by: Russ Dill <russ.dill@ti.com>
> ---
> arch/arm/mach-omap2/board-omap3evm.c |   15 ++++++---------
> 1 files changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
> index a659e19..6a5e57c 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -114,15 +114,6 @@ 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);

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

regards,

Koen

Re: [PATCH 09/13] Add dummy smsc911x regulators to omap3evm.

[Russ Dill]

On Thu, Mar 22, 2012 at 12:07 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 22 mrt. 2012, om 06:19 heeft Russ Dill het volgende geschreven:
>
>> Signed-off-by: Russ Dill <russ.dill@ti.com>
>> ---
>> arch/arm/mach-omap2/board-omap3evm.c |   15 ++++++---------
>> 1 files changed, 6 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
>> index a659e19..6a5e57c 100644
>> --- a/arch/arm/mach-omap2/board-omap3evm.c
>> +++ b/arch/arm/mach-omap2/board-omap3evm.c
>> @@ -114,15 +114,6 @@ 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);
>
> The above hunk gets added/removed multiple times during this patch series, a rebase -i mishap?

Yes, its a rebase -i mishap. I have no idea how it did that as all I
was doing was rewording. I can resend the series
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/13] Add dummy smsc911x regulators to omap3logic.

[Russ Dill]

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/board-omap3logic.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3logic.c b/arch/arm/mach-omap2/board-omap3logic.c
index 4a7d8c8..9b3c141 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -23,6 +23,7 @@
 #include <linux/io.h>
 #include <linux/gpio.h>
 
+#include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 
 #include <linux/i2c/twl.h>
@@ -188,8 +189,14 @@ static struct omap_board_mux board_mux[] __initdata = {
 };
 #endif
 
+static struct regulator_consumer_supply dummy_supplies[] = {
+	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
+};
+
 static void __init omap3logic_init(void)
 {
+	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	omap3torpedo_fix_pbias_voltage();
 	omap3logic_i2c_init();
-- 
1.7.9.1

[PATCH 11/13] Add dummy smsc911x regulators to omap3stalker.

[Russ Dill]

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/board-omap3stalker.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index de95352..4dffc95 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -24,6 +24,7 @@
 #include <linux/input.h>
 #include <linux/gpio_keys.h>
 
+#include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/i2c/twl.h>
 #include <linux/mmc/host.h>
@@ -410,8 +411,14 @@ static struct omap_board_mux board_mux[] __initdata = {
 };
 #endif
 
+static struct regulator_consumer_supply dummy_supplies[] = {
+	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
+};
+
 static void __init omap3_stalker_init(void)
 {
+	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CUS);
 	omap_board_config = omap3_stalker_config;
 	omap_board_config_size = ARRAY_SIZE(omap3_stalker_config);
-- 
1.7.9.1

[PATCH 12/13] Add dummy smsc911x regulators to overo.

[Russ Dill]

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/board-overo.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 668533e..33aa391 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -498,10 +498,18 @@ static struct gpio overo_bt_gpios[] __initdata = {
 	{ OVERO_GPIO_BT_NRESET, GPIOF_OUT_INIT_HIGH,	"lcd bl enable" },
 };
 
+static struct regulator_consumer_supply dummy_supplies[] = {
+	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
+	REGULATOR_SUPPLY("vddvario", "smsc911x.1"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x.1"),
+};
+
 static void __init overo_init(void)
 {
 	int ret;
 
+	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	omap_hsmmc_init(mmc);
 	overo_i2c_init();
-- 
1.7.9.1

[PATCH 13/13] Add dummy smsc911x regulators to zoom-debugboard.

[Russ Dill]

Signed-off-by: Russ Dill <russ.dill@ti.com>
---
 arch/arm/mach-omap2/board-zoom-debugboard.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c b/arch/arm/mach-omap2/board-zoom-debugboard.c
index 369c2eb..f68b616 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -14,6 +14,9 @@
 #include <linux/smsc911x.h>
 #include <linux/interrupt.h>
 
+#include <linux/regulator/fixed.h>
+#include <linux/regulator/machine.h>
+
 #include <plat/gpmc.h>
 #include <plat/gpmc-smsc911x.h>
 
@@ -116,11 +119,17 @@ static struct platform_device *zoom_devices[] __initdata = {
 	&zoom_debugboard_serial_device,
 };
 
+static struct regulator_consumer_supply dummy_supplies[] = {
+	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
+};
+
 int __init zoom_debugboard_init(void)
 {
 	if (!omap_zoom_debugboard_detect())
 		return 0;
 
+	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
 	zoom_init_smsc911x();
 	zoom_init_quaduart();
 	return platform_add_devices(zoom_devices, ARRAY_SIZE(zoom_devices));
-- 
1.7.9.1

Re: [PATCH 13/13] Add dummy smsc911x regulators to zoom-debugboard.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

On Wed, Mar 21, 2012 at 10:19:54PM -0700, Russ Dill wrote:

> +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?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 13/13] Add dummy smsc911x regulators to zoom-debugboard.

[Russ Dill]

On Thu, Mar 22, 2012 at 4:37 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, Mar 21, 2012 at 10:19:54PM -0700, Russ Dill wrote:
>
>> +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?

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] Add dummy smsc911x regulators to zoom-debugboard.

[Igor Grinberg]

Hi Russ, Mark,

On 03/22/12 20:29, Russ Dill wrote:
> On Thu, Mar 22, 2012 at 4:37 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
>> On Wed, Mar 21, 2012 at 10:19:54PM -0700, Russ Dill wrote:
>>
>>> +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?
> 
> 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.

IIRC, everybody were very sensible to each new l-o-f back then,
so making the id = 0 (leaving it uninitialized) helped with
reducing some ~10 lines more...
Of course we can change this now, but what is the real problem
with having device id = 0 and not -1?


-- 
Regards,
Igor.