Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1566883 > unrolled thread

[PATCH] Revert "regulator: fixed: add support for ACPI interface"

Back to article view | Back to linux.kernel

Contents

  [PATCH] Revert "regulator: fixed: add support for ACPI interface" Mark Rutland <mark.rutland@arm.com> - 2017-01-25 20:40 +0100
    Re: [PATCH] Revert "regulator: fixed: add support for ACPI interface" Mark Brown <broonie@kernel.org> - 2017-01-25 21:50 +0100
    Re: [PATCH] Revert "regulator: fixed: add support for ACPI interface" "Rafael J. Wysocki" <rafael@kernel.org> - 2017-01-26 12:00 +0100
      Re: [PATCH] Revert "regulator: fixed: add support for ACPI interface" Mark Brown <broonie@kernel.org> - 2017-01-26 13:40 +0100
        Re: [PATCH] Revert "regulator: fixed: add support for ACPI interface" "Rafael J. Wysocki" <rafael@kernel.org> - 2017-01-27 00:50 +0100

#1566883 — [PATCH] Revert "regulator: fixed: add support for ACPI interface"

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

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);
 	}
-- 
2.7.4

[toc] | [next] | [standalone]

#1566937

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1567320

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

[toc] | [prev] | [next] | [standalone]

#1567402

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1567815

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web