| Message ID | 1485372609-2498-1-git-send-email-mark.rutland@arm.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Jan 25, 2017 at 07:30:09PM +0000, Mark Rutland wrote: > This reverts commit 13bed58ce8748d430a26e353a09b89f9d613a71f. > > While there does appear to be a practical need to manage regulators on ACPI > systems, using ad-hoc properties to describe regulators to the kernel presents > a number of problems (especially should ACPI gain first class support for such > things), and there are ongoing discussions as to how to manage this. Please submit patches using subject lines reflecting the style for the subsystem. This makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing.
On Wed, Jan 25, 2017 at 8:30 PM, Mark Rutland <mark.rutland@arm.com> wrote: > This reverts commit 13bed58ce8748d430a26e353a09b89f9d613a71f. > > While there does appear to be a practical need to manage regulators on ACPI > systems, using ad-hoc properties to describe regulators to the kernel presents > a number of problems (especially should ACPI gain first class support for such > things), and there are ongoing discussions as to how to manage this. > > Until there is a rough consensus, revert commit 13bed58ce8748d43, FWIW, I overlooked this one somehow and I agree that it shouldn't have been applied in the first place. Did it actually go to linux-acpi, BTW? Thanks, Rafael
On Thu, Jan 26, 2017 at 11:56:07AM +0100, Rafael J. Wysocki wrote:
> Did it actually go to linux-acpi, BTW?
Don't think so.
On Thu, Jan 26, 2017 at 1:31 PM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Jan 26, 2017 at 11:56:07AM +0100, Rafael J. Wysocki wrote: > >> Did it actually go to linux-acpi, BTW? > > Don't think so. Well, that may be why it wasn't caught, then. It generally is a good idea to request patch submitters to CC all ACPI-related changes to that list just in case. :-) Thanks, Rafael
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c index a43b0e8..988a747 100644 --- a/drivers/regulator/fixed.c +++ b/drivers/regulator/fixed.c @@ -30,9 +30,6 @@ #include <linux/of_gpio.h> #include <linux/regulator/of_regulator.h> #include <linux/regulator/machine.h> -#include <linux/acpi.h> -#include <linux/property.h> -#include <linux/gpio/consumer.h> struct fixed_voltage_data { struct regulator_desc desc; @@ -97,44 +94,6 @@ of_get_fixed_voltage_config(struct device *dev, return config; } -/** - * acpi_get_fixed_voltage_config - extract fixed_voltage_config structure info - * @dev: device requesting for fixed_voltage_config - * @desc: regulator description - * - * Populates fixed_voltage_config structure by extracting data through ACPI - * interface, returns a pointer to the populated structure of NULL if memory - * alloc fails. - */ -static struct fixed_voltage_config * -acpi_get_fixed_voltage_config(struct device *dev, - const struct regulator_desc *desc) -{ - struct fixed_voltage_config *config; - const char *supply_name; - struct gpio_desc *gpiod; - int ret; - - config = devm_kzalloc(dev, sizeof(*config), GFP_KERNEL); - if (!config) - return ERR_PTR(-ENOMEM); - - ret = device_property_read_string(dev, "supply-name", &supply_name); - if (!ret) - config->supply_name = supply_name; - - gpiod = gpiod_get(dev, "gpio", GPIOD_ASIS); - if (IS_ERR(gpiod)) - return ERR_PTR(-ENODEV); - - config->gpio = desc_to_gpio(gpiod); - config->enable_high = device_property_read_bool(dev, - "enable-active-high"); - gpiod_put(gpiod); - - return config; -} - static struct regulator_ops fixed_voltage_ops = { }; @@ -155,11 +114,6 @@ static int reg_fixed_voltage_probe(struct platform_device *pdev) &drvdata->desc); if (IS_ERR(config)) return PTR_ERR(config); - } else if (ACPI_HANDLE(&pdev->dev)) { - config = acpi_get_fixed_voltage_config(&pdev->dev, - &drvdata->desc); - if (IS_ERR(config)) - return PTR_ERR(config); } else { config = dev_get_platdata(&pdev->dev); }
This reverts commit 13bed58ce8748d430a26e353a09b89f9d613a71f. While there does appear to be a practical need to manage regulators on ACPI systems, using ad-hoc properties to describe regulators to the kernel presents a number of problems (especially should ACPI gain first class support for such things), and there are ongoing discussions as to how to manage this. Until there is a rough consensus, revert commit 13bed58ce8748d43, which hasn't been in a released kernel yetm as discussed in [1] and the surrounding thread. [1] http://lkml.kernel.org/r/20170125184949.x2wkoo7kbaaajkjk@sirena.org.uk Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Lu Baolu <baolu.lu@linux.intel.com> Cc: Mark Brown <broonie@kernel.org> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: linux-kernel@vger.kernel.org --- drivers/regulator/fixed.c | 46 ---------------------------------------------- 1 file changed, 46 deletions(-) -- 2.7.4