Regulator support for smsc911x

Regulator support for smsc911x

[Fabio Estevam]

Robert,

Since commit c7e963f6 (net/smsc911x: Add regulator support) I am no
longer able to use smsc911x driver due to the lack of regulators for
smsc on mx31_3ds board.

Do you a board example that uses such regulator, so that I can look
for a reference?

Regards,

Fabio Estevam

Re: Regulator support for smsc911x

[Fabio Estevam]

On Thu, Feb 2, 2012 at 11:02 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Robert,
>
> Since commit c7e963f6 (net/smsc911x: Add regulator support) I am no
> longer able to use smsc911x driver due to the lack of regulators for
> smsc on mx31_3ds board.
>
> Do you a board example that uses such regulator, so that I can look
> for a reference?

Ok, I fixed it by enabling CONFIG_REGULATOR_DUMMY on
imx_v6_v7_defconfig, but I am wondering if the patch below would be a
more appropriate fix:

--- a/drivers/net/ethernet/smsc/Kconfig
+++ b/drivers/net/ethernet/smsc/Kconfig
@@ -102,6 +102,8 @@ config SMSC911X
        select NET_CORE
        select MII
        select PHYLIB
+       select REGULATOR
+       select REGULATOR_DUMMY
        ---help---
          Say Y here if you want support for SMSC LAN911x and LAN921x families
          of ethernet controllers.

Please advise if I should fix it in Kconfig or defconfig, so that I
can submit a patch.

Regards,

Fabio Estevam

Re: Regulator support for smsc911x

[Sascha Hauer]

On Fri, Feb 03, 2012 at 01:17:23AM -0200, Fabio Estevam wrote:
> On Thu, Feb 2, 2012 at 11:02 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > Robert,
> >
> > Since commit c7e963f6 (net/smsc911x: Add regulator support) I am no
> > longer able to use smsc911x driver due to the lack of regulators for
> > smsc on mx31_3ds board.
> >
> > Do you a board example that uses such regulator, so that I can look
> > for a reference?
> 
> Ok, I fixed it by enabling CONFIG_REGULATOR_DUMMY on
> imx_v6_v7_defconfig, but I am wondering if the patch below would be a
> more appropriate fix:
> 
> --- a/drivers/net/ethernet/smsc/Kconfig
> +++ b/drivers/net/ethernet/smsc/Kconfig
> @@ -102,6 +102,8 @@ config SMSC911X
>         select NET_CORE
>         select MII
>         select PHYLIB
> +       select REGULATOR
> +       select REGULATOR_DUMMY
>         ---help---
>           Say Y here if you want support for SMSC LAN911x and LAN921x families
>           of ethernet controllers.
> 
> Please advise if I should fix it in Kconfig or defconfig, so that I
> can submit a patch.

The problem with the dummy regulator is that it can hide real problems.
If you enable it every device will get a regulator when it requests one.
If for some reason for example the initialization order of your devices
changes and a device gets probed before the corresponding (real)
regulator is registered, then this device will continue with the dummy
regulator and probably won't work.

We could a) live with this problem and default enable the dummy
regulator. We could also b) apply (a fixed version of) the following
patch which simplifies registration of a dummy regulator. Still it's a
bit annoying to have to fix all users once someone adds regulator
support for a driver.

Sascha

8<------------------------------------------------

regulator: allow boards to bind to the dummy regulator

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/regulator/core.c          |   19 +++++++++++++++++++
 include/linux/regulator/machine.h |    8 ++++++++
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d8e6a42..a7a38ba 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1046,6 +1046,25 @@ static void unset_regulator_supplies(struct regulator_dev *rdev)
 	}
 }
 
+int regulator_add_dummy_supply(struct regulator_consumer_supply *supply,
+		int num_supplies)
+{
+	int i, ret;
+
+	for (i = 0; i < num_supplies; i++) {
+		ret = set_consumer_device_supply(dummy_regulator_rdev, NULL,
+				supply[i].dev_name, supply[i].supply);
+		if (ret)
+			goto err_out;
+	}
+
+	return 0;
+err_out:
+	/* FIXME: unset device supply */
+	return ret;
+}
+EXPORT_SYMBOL_GPL(regulator_add_dummy_supply);
+
 #define REG_STR_SIZE	64
 
 static struct regulator *create_regulator(struct regulator_dev *rdev,
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index ce3127a..89089cd 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -192,6 +192,8 @@ int regulator_suspend_finish(void);
 #ifdef CONFIG_REGULATOR
 void regulator_has_full_constraints(void);
 void regulator_use_dummy_regulator(void);
+int regulator_add_dummy_supply(struct regulator_consumer_supply *supply,
+		int num_supplies);
 #else
 static inline void regulator_has_full_constraints(void)
 {
@@ -200,6 +202,12 @@ static inline void regulator_has_full_constraints(void)
 static inline void regulator_use_dummy_regulator(void)
 {
 }
+
+static inline int regulator_add_dummy_supply(struct regulator_consumer_supply *supply,
+		int num_supplies)
+{
+	return 0;
+}
 #endif
 
 #endif
-- 
1.7.8.3

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Regulator support for smsc911x

[Mark Brown]

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

On Fri, Feb 03, 2012 at 08:44:08AM +0100, Sascha Hauer wrote:
> On Fri, Feb 03, 2012 at 01:17:23AM -0200, Fabio Estevam wrote:

> > Please advise if I should fix it in Kconfig or defconfig, so that I
> > can submit a patch.

> If you enable it every device will get a regulator when it requests one.
> If for some reason for example the initialization order of your devices
> changes and a device gets probed before the corresponding (real)
> regulator is registered, then this device will continue with the dummy
> regulator and probably won't work.

Hrm, yeah - the dummy regulator support will be totally broken by the
stuff Grant is working on for fixing the general issues with probe
ordering.

> We could a) live with this problem and default enable the dummy
> regulator. We could also b) apply (a fixed version of) the following
> patch which simplifies registration of a dummy regulator. Still it's a

There's also options c) set up the regulators for the board and d) don't
enable the regulator API if the board doesn't use regulators.

> bit annoying to have to fix all users once someone adds regulator
> support for a driver.

Yeah, it's a shame.  I really can't see anything else useful we can do
though.

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

Re: Regulator support for smsc911x

[Fabio Estevam]

Hi Mark,

On Fri, Feb 3, 2012 at 9:11 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:

> There's also options c) set up the regulators for the board and d) don't
> enable the regulator API if the board doesn't use regulators.

Option c would require that we change every single board.

The patch below does option d.

What do you think?

diff --git a/arch/arm/mach-ux500/board-mop500.c
b/arch/arm/mach-ux500/board-mop500.c
index 5c00712..3fdd1c2 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -157,7 +157,8 @@ static struct platform_device snowball_key_dev = {
 static struct smsc911x_platform_config snowball_sbnet_cfg = {
 	.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH,
 	.irq_type = SMSC911X_IRQ_TYPE_PUSH_PULL,
-	.flags = SMSC911X_USE_16BIT | SMSC911X_FORCE_INTERNAL_PHY,
+	.flags = SMSC911X_USE_16BIT | SMSC911X_FORCE_INTERNAL_PHY |
+							SMSC911X_USE_REGULATOR,
 	.shift = 1,
 };

diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 6a1cd23..b9f6e67 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -377,8 +377,9 @@ static int smsc911x_enable_resources(struct
platform_device *pdev)
 	struct smsc911x_data *pdata = netdev_priv(ndev);
 	int ret = 0;

-	ret = regulator_bulk_enable(ARRAY_SIZE(pdata->supplies),
-			pdata->supplies);
+	if (pdata->config.flags & SMSC911X_USE_REGULATOR)
+		ret = regulator_bulk_enable(ARRAY_SIZE(pdata->supplies),
+				pdata->supplies);
 	if (ret)
 		netdev_err(ndev, "failed to enable regulators %d\n",
 				ret);
@@ -394,8 +395,9 @@ static int smsc911x_disable_resources(struct
platform_device *pdev)
 	struct smsc911x_data *pdata = netdev_priv(ndev);
 	int ret = 0;

-	ret = regulator_bulk_disable(ARRAY_SIZE(pdata->supplies),
-			pdata->supplies);
+	if (pdata->config.flags & SMSC911X_USE_REGULATOR)
+		ret = regulator_bulk_disable(ARRAY_SIZE(pdata->supplies),
+				pdata->supplies);
 	return ret;
 }

@@ -415,9 +417,11 @@ static int smsc911x_request_resources(struct
platform_device *pdev)
 	/* Request regulators */
 	pdata->supplies[0].supply = "vdd33a";
 	pdata->supplies[1].supply = "vddvario";
-	ret = regulator_bulk_get(&pdev->dev,
-			ARRAY_SIZE(pdata->supplies),
-			pdata->supplies);
+	
+	if (pdata->config.flags & SMSC911X_USE_REGULATOR)
+		ret = regulator_bulk_get(&pdev->dev,
+				ARRAY_SIZE(pdata->supplies),
+				pdata->supplies);
 	if (ret)
 		netdev_err(ndev, "couldn't get regulators %d\n",
 				ret);
@@ -434,8 +438,9 @@ static void smsc911x_free_resources(struct
platform_device *pdev)
 	struct smsc911x_data *pdata = netdev_priv(ndev);

 	/* Free regulators */
-	regulator_bulk_free(ARRAY_SIZE(pdata->supplies),
-			pdata->supplies);
+	if (pdata->config.flags & SMSC911X_USE_REGULATOR)	
+		regulator_bulk_free(ARRAY_SIZE(pdata->supplies),
+				pdata->supplies);
 }

 /* waits for MAC not busy, with timeout.  Only called by smsc911x_mac_read
diff --git a/include/linux/smsc911x.h b/include/linux/smsc911x.h
index 4dde70e..91c59d9 100644
--- a/include/linux/smsc911x.h
+++ b/include/linux/smsc911x.h
@@ -48,6 +48,7 @@ struct smsc911x_platform_config {
 #define SMSC911X_FORCE_INTERNAL_PHY		(BIT(2))
 #define SMSC911X_FORCE_EXTERNAL_PHY 		(BIT(3))
 #define SMSC911X_SAVE_MAC_ADDRESS		(BIT(4))
+#define SMSC911X_USE_REGULATOR			(BIT(5))		

 /*
  * SMSC911X_SWAP_FIFO:
--

Re: Regulator support for smsc911x

[Mark Brown]

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

On Tue, Feb 07, 2012 at 05:25:48PM -0200, Fabio Estevam wrote:
> On Fri, Feb 3, 2012 at 9:11 AM, Mark Brown

> > There's also options c) set up the regulators for the board and d) don't
> > enable the regulator API if the board doesn't use regulators.

> Option c would require that we change every single board.

Well, yes.

> The patch below does option d.

> What do you think?

Absolutely not.  Putting conditional code like this in drivers is nuts,
you would have to do the same thing in every single driver which is not
a useful use of anyone's time.  This is *clearly* a generic thing and
should therefore be handled in generic code for the same reason we don't
have driver specific platform data for actual usage of the API.

Really, anyone who wants this sort of thing should just enable dummy
regulators - it's exactly what you're implementing.  I'm pretty sure
your board does actually have power supplies for the chip, you've just
not told software about them.

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

Re: Regulator support for smsc911x

[Fabio Estevam]

On Tue, Feb 7, 2012 at 5:39 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:

> Really, anyone who wants this sort of thing should just enable dummy
> regulators - it's exactly what you're implementing.  I'm pretty sure
> your board does actually have power supplies for the chip, you've just
> not told software about them.

Ok, I have sent a patch adding the regulators.

Thanks,

Fabio Estevam

Re: Regulator support for smsc911x

[Sascha Hauer]

On Tue, Feb 07, 2012 at 07:39:14PM +0000, Mark Brown wrote:
> On Tue, Feb 07, 2012 at 05:25:48PM -0200, Fabio Estevam wrote:
> > On Fri, Feb 3, 2012 at 9:11 AM, Mark Brown
> 
> > > There's also options c) set up the regulators for the board and d) don't
> > > enable the regulator API if the board doesn't use regulators.
> 
> > Option c would require that we change every single board.
> 
> Well, yes.
> 
> > The patch below does option d.
> 
> > What do you think?
> 
> Absolutely not.  Putting conditional code like this in drivers is nuts,
> you would have to do the same thing in every single driver which is not
> a useful use of anyone's time.  This is *clearly* a generic thing and
> should therefore be handled in generic code for the same reason we don't
> have driver specific platform data for actual usage of the API.
> 
> Really, anyone who wants this sort of thing should just enable dummy
> regulators - it's exactly what you're implementing.  I'm pretty sure
> your board does actually have power supplies for the chip, you've just
> not told software about them.

Yes, my board also has a supply for the smc911x, it's the same as used
for the CPU...

There is also option e), something I've been thinking about for a while.
Implement a list of resources which can be attached to a device. By
resources I mean regulators, clocks and pinmux for example. A device
would then just call a make_me_work(state) function which iterates over
this list and enables/disables all resources as necessary. This way we
could attach everything we need to a device without cluttering the
driver code like we do today.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Regulator support for smsc911x

[Mark Brown]

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

On Wed, Feb 08, 2012 at 09:31:41AM +0100, Sascha Hauer wrote:

> There is also option e), something I've been thinking about for a while.
> Implement a list of resources which can be attached to a device. By
> resources I mean regulators, clocks and pinmux for example. A device
> would then just call a make_me_work(state) function which iterates over
> this list and enables/disables all resources as necessary. This way we
> could attach everything we need to a device without cluttering the
> driver code like we do today.

That gets tricky where you have resources that are only needed some of
the time (for example, many of the CODECs I work with can happily have
some of the supplies disabled while they are operational - some systems
may never enable certain supplies) and there are fun interactions with
things like runtime PM and system suspend to consider (wake on LAN would
be one for an ethernet driver).  Once you start hitting low power states
and pursuing optimisations there you start to find that the driver needs
to make decisions about what's going on that can't easily be completely
removed from it.

I have been meaning to do something like that which devices can
request if they happen to have trivial or common usage patterns (of
which there's a few) so all they need to do is set flags but I'm really
not sure it's a good idea by default.  Gets fiddly with the device core
though.

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