| Message ID | CAOMZO5B2_yq=m8Mer=iV-HsXvF-MZJ-BV2=LTg1CZN+O=yepSQ@mail.gmail.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
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.
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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.
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: