[PATCH 0/2] iio: GPIO power switch support

[PATCH 0/2] iio: GPIO power switch support

[Bartosz Golaszewski]

This series is aimed at improving the support for baylibre-acme[1]
power measurement capes. 

We would like to add support for power-cycling of devices measured
using TI INA226 ADCs. An example use case would be measuring the power
consumption of a development board during boot and power-cycling it
remotely using a GPIO power switch.

The first patch proposes to add a new DT binding for describing simple
power switches.

The second adds a simple IIO driver exposing a single attribute.

The motivation for using the IIO framework is the fact that we already
use it for reading the data from the ADC and that power-cycling the
measured devices is an integral part of our use case. Users would find
it convenient to be able to use libiio as the single interface.

[1] http://baylibre.com/acme/

Bartosz Golaszewski (2):
  devicetree: power: add bindings for GPIO-driven power switches
  iio: misc: add support for GPIO power switches

 .../bindings/power/gpio-power-switch.txt           |  25 ++++
 drivers/iio/Kconfig                                |   1 +
 drivers/iio/Makefile                               |   1 +
 drivers/iio/misc/Kconfig                           |  17 +++
 drivers/iio/misc/Makefile                          |   6 +
 drivers/iio/misc/gpio-power-switch.c               | 127 +++++++++++++++++++++
 6 files changed, 177 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/gpio-power-switch.txt
 create mode 100644 drivers/iio/misc/Kconfig
 create mode 100644 drivers/iio/misc/Makefile
 create mode 100644 drivers/iio/misc/gpio-power-switch.c

-- 
2.9.3

[PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

[Bartosz Golaszewski]

Some boards are equipped with simple, GPIO-driven power load switches.
An example of such ICs is the TI tps229* series.

Add device tree bindings allowing to describe them.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 .../bindings/power/gpio-power-switch.txt           | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/gpio-power-switch.txt

diff --git a/Documentation/devicetree/bindings/power/gpio-power-switch.txt b/Documentation/devicetree/bindings/power/gpio-power-switch.txt
new file mode 100644
index 0000000..21420ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/gpio-power-switch.txt
@@ -0,0 +1,25 @@
+GPIO Power Switch
+-----------------
+
+This is the device tree binding for simple, GPIO-driven power load switches
+that do not have any control signals.
+
+Required properties:
+
+- compatible:           must be "gpio-power-switch"
+- power-gpios:          phandle for the GPIO driving the power load switch
+
+Optional properties:
+
+- power-switch-name:    the name of the power switch
+- power-switch-on:      the power switch GPIO is driven high by default
+
+Example
+-------
+
+acme_probe0_power_switch: gpio_power_switch@0 {
+	compatible = "gpio-power-switch";
+	power-switch-name = "acme_probe0_switch";
+	power-gpios = <&pca9535 1 GPIO_ACTIVE_HIGH>;
+	power-switch-on;
+};
-- 
2.9.3

Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

[Rob Herring]

On Sun, Dec 11, 2016 at 11:21:44PM +0100, Bartosz Golaszewski wrote:
> Some boards are equipped with simple, GPIO-driven power load switches.
> An example of such ICs is the TI tps229* series.

How is this different than a GPIO regulator? The input and output 
voltages just happen to be the same. I could be convinced this is 
different enough to have a different compatible, but it somewhat seems 
you want to use this for IIO, so you are creating a different binding 
for that usecase.

Rob

Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

[Bartosz Golaszewski]

2016-12-13 20:27 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Sun, Dec 11, 2016 at 11:21:44PM +0100, Bartosz Golaszewski wrote:
>> Some boards are equipped with simple, GPIO-driven power load switches.
>> An example of such ICs is the TI tps229* series.
>
> How is this different than a GPIO regulator? The input and output
> voltages just happen to be the same. I could be convinced this is
> different enough to have a different compatible, but it somewhat seems
> you want to use this for IIO, so you are creating a different binding
> for that usecase.
>

It's more of a fixed regulator I suppose. Do you mean adding a new
compatible to the fixed-regulator binding (e.g. "gpio-power-switch" or
"simple-power-switch") and then providing an iio driver for toggling
the switch?

Thanks,
Bartosz

Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

[Bartosz Golaszewski]

2016-12-14 18:36 GMT+01:00 Jonathan Cameron <jic23@jic23.retrosnub.co.uk>:
>
>
> On 14 December 2016 16:58:21 GMT+00:00, Bartosz Golaszewski
> <bgolaszewski@baylibre.com> wrote:
>>2016-12-13 20:27 GMT+01:00 Rob Herring <robh@kernel.org>:
>>> On Sun, Dec 11, 2016 at 11:21:44PM +0100, Bartosz Golaszewski wrote:
>>>> Some boards are equipped with simple, GPIO-driven power load
>>switches.
>>>> An example of such ICs is the TI tps229* series.
>>>
>>> How is this different than a GPIO regulator? The input and output
>>> voltages just happen to be the same. I could be convinced this is
>>> different enough to have a different compatible, but it somewhat
>>seems
>>> you want to use this for IIO, so you are creating a different binding
>>> for that usecase.
>>>
>>
>>It's more of a fixed regulator I suppose. Do you mean adding a new
>>compatible to the fixed-regulator binding (e.g. "gpio-power-switch" or
>>"simple-power-switch") and then providing an iio driver for toggling
>>the switch?
>
> I am rather torn on whether the IIO interface makes any sense beyond that of
> convenience.
>

The question is: will the iio maintainers be ok with adding support
for interfaces different than iio (I guess so since Lars already
mentioned wanting to support the GPIO chardev)? If so, I'm ok with not
using the iio framework in the kernel.

> A bridge to a regulator in general might make sense to cover the case of a
> reg effectively
> acting as a DAC at the edge of the known hardware.
>
> Lars' point about perhaps adding support for the new gpio userspace stuff to
> libiio would in
> this case also be rather papering over the issue.
> There is known hardware there so we should describe it!
>
> I think we should be considering this as the general case of the Linux
> controlled power supply.
> How do we want to represent that?
> Ultimately does a general regulator userspace interface make sense?
>
> Classic case of people cutting our hardware in half and making boundaries
> beyond which lie dragons.
>
> I would love to see the general case covered.
>

It seems as if this is already covered by the userspace-consumer
regulator driver, but it doesn't speak device tree yet. I guess we
could reuse it by merging the proposed gpio-power-switch binding and
extending it to parse DT.

Best regards,
Bartosz Golaszewski

Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

[Rob Herring]

On Wed, Dec 14, 2016 at 10:58 AM, Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> 2016-12-13 20:27 GMT+01:00 Rob Herring <robh@kernel.org>:
>> On Sun, Dec 11, 2016 at 11:21:44PM +0100, Bartosz Golaszewski wrote:
>>> Some boards are equipped with simple, GPIO-driven power load switches.
>>> An example of such ICs is the TI tps229* series.
>>
>> How is this different than a GPIO regulator? The input and output
>> voltages just happen to be the same. I could be convinced this is
>> different enough to have a different compatible, but it somewhat seems
>> you want to use this for IIO, so you are creating a different binding
>> for that usecase.
>>
>
> It's more of a fixed regulator I suppose. Do you mean adding a new
> compatible to the fixed-regulator binding (e.g. "gpio-power-switch" or
> "simple-power-switch") and then providing an iio driver for toggling
> the switch?

Yes, at least the first part. I view the switch as just a more
specific subtype of a fixed-regulator. Whether an IIO driver is a
separate discussion which is happening.

Rob

P.S. I really don't like compatibles with "simple".

Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

[Geert Uytterhoeven]

On Thu, Dec 15, 2016 at 4:05 PM, Rob Herring <robh@kernel.org> wrote:
> On Wed, Dec 14, 2016 at 10:58 AM, Bartosz Golaszewski
> <bgolaszewski@baylibre.com> wrote:
>> 2016-12-13 20:27 GMT+01:00 Rob Herring <robh@kernel.org>:
>>> On Sun, Dec 11, 2016 at 11:21:44PM +0100, Bartosz Golaszewski wrote:
>>>> Some boards are equipped with simple, GPIO-driven power load switches.
>>>> An example of such ICs is the TI tps229* series.
>>>
>>> How is this different than a GPIO regulator? The input and output
>>> voltages just happen to be the same. I could be convinced this is
>>> different enough to have a different compatible, but it somewhat seems
>>> you want to use this for IIO, so you are creating a different binding
>>> for that usecase.
>>
>> It's more of a fixed regulator I suppose. Do you mean adding a new
>> compatible to the fixed-regulator binding (e.g. "gpio-power-switch" or
>> "simple-power-switch") and then providing an iio driver for toggling
>> the switch?
>
> Yes, at least the first part. I view the switch as just a more
> specific subtype of a fixed-regulator. Whether an IIO driver is a
> separate discussion which is happening.

The switch could also be an opto-isolator (for which I could use gpio-leds,
too, although also without libiio control ;-) or a relay.

While I agree a switch is a degenerate regulator, modelling it as a regulator
feels a bit weird to me. Switches could be extended to e.g. double throw
relays, or H-bridges using 4 GPIOs.

BTW, I'm not an IIO expert, but from my limited knowledge, it looks like "O"
support in IIO is limited to DACs?

P.S. My motiviation is using libiio to control my board farm, which has a bank
     of opto-isolators in addition to BayLibre's ACME.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

[Lars-Peter Clausen]

On 12/23/2016 10:07 AM, Geert Uytterhoeven wrote:
> BTW, I'm not an IIO expert, but from my limited knowledge, it looks like "O"
> support in IIO is limited to DACs?

Depends on what you categorize as DACs. There are also
potentiometer/rheostat drivers. They are kind of like DACs but the unit you
control are ohm, rather than current or voltage.

Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

[Jonathan Cameron]

On 23/12/16 11:40, Lars-Peter Clausen wrote:
> On 12/23/2016 10:07 AM, Geert Uytterhoeven wrote:
>> BTW, I'm not an IIO expert, but from my limited knowledge, it looks like "O"
>> support in IIO is limited to DACs?
> 
> Depends on what you categorize as DACs. There are also
> potentiometer/rheostat drivers. They are kind of like DACs but the unit you
> control are ohm, rather than current or voltage.
Though they are still in staging there are also things like function generators.

I've been mulling doing a driver for the st-powerstep01 parts as well which
is a smart stepper motor controller.  At that level we'd need to start describing
the connected stepper motors in DT :) Whole chunk of API to define to do that
though - might well take longer than writing the driver.

So in practice yeah - dac like things, but then on the input side they are almost
all really ADCs with some funny analog stuff on the front end ;)

Arguably switches are 1 bit DACs ;)

The distinction here is whether 'what is passing through' the device is knowable.
So regulators and your power switch are well described.  A relay less so unless
we know what load it is switching...

+ it's IIO.  We are open to almost anything as long as we aren't stepping on
any toes!

Jonathan

> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

[Linus Walleij]

On Sun, Dec 11, 2016 at 11:21 PM, Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:

> Some boards are equipped with simple, GPIO-driven power load switches.
> An example of such ICs is the TI tps229* series.
>
> Add device tree bindings allowing to describe them.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
(...)
>  .../bindings/power/gpio-power-switch.txt           | 25 ++++++++++++++++++++++

Scrap this and use:
Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt

Yours,
Linus Walleij

[PATCH 2/2] iio: misc: add support for GPIO power switches

[Bartosz Golaszewski]

Some power-measuring ADCs work together with power load switches which
allow to power-cycle measured devices.

An example use case would be measuring the power consumption of a
development board during boot using a power monitor such as TI INA226
and power-cycling the board remotely using a TPS229* power switch.

Add an iio driver for simple GPIO power switches and expose a sysfs
attribute allowing to toggle their state.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 drivers/iio/Kconfig                  |   1 +
 drivers/iio/Makefile                 |   1 +
 drivers/iio/misc/Kconfig             |  17 +++++
 drivers/iio/misc/Makefile            |   6 ++
 drivers/iio/misc/gpio-power-switch.c | 127 +++++++++++++++++++++++++++++++++++
 5 files changed, 152 insertions(+)
 create mode 100644 drivers/iio/misc/Kconfig
 create mode 100644 drivers/iio/misc/Makefile
 create mode 100644 drivers/iio/misc/gpio-power-switch.c

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 6743b18..2e896e0 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -80,6 +80,7 @@ source "drivers/iio/gyro/Kconfig"
 source "drivers/iio/health/Kconfig"
 source "drivers/iio/humidity/Kconfig"
 source "drivers/iio/imu/Kconfig"
+source "drivers/iio/misc/Kconfig"
 source "drivers/iio/light/Kconfig"
 source "drivers/iio/magnetometer/Kconfig"
 source "drivers/iio/orientation/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 87e4c43..4008d5a 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -25,6 +25,7 @@ obj-y += frequency/
 obj-y += health/
 obj-y += humidity/
 obj-y += imu/
+obj-y += misc/
 obj-y += light/
 obj-y += magnetometer/
 obj-y += orientation/
diff --git a/drivers/iio/misc/Kconfig b/drivers/iio/misc/Kconfig
new file mode 100644
index 0000000..8d73751
--- /dev/null
+++ b/drivers/iio/misc/Kconfig
@@ -0,0 +1,17 @@
+#
+# Miscellaneous iio drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Miscellaneous iio drivers"
+
+config GPIO_POWER_SWITCH
+	tristate "GPIO power switch driver"
+	depends on GPIOLIB
+	help
+	  Say yes here to build support for gpio power switches.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called gpio-power-switch.
+
+endmenu
diff --git a/drivers/iio/misc/Makefile b/drivers/iio/misc/Makefile
new file mode 100644
index 0000000..cebd0c4
--- /dev/null
+++ b/drivers/iio/misc/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO misc drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_GPIO_POWER_SWITCH) += gpio-power-switch.o
diff --git a/drivers/iio/misc/gpio-power-switch.c b/drivers/iio/misc/gpio-power-switch.c
new file mode 100644
index 0000000..25fbeb7
--- /dev/null
+++ b/drivers/iio/misc/gpio-power-switch.c
@@ -0,0 +1,127 @@
+/*
+ * GPIO power switch driver using the industrial IO framework.
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ *   Bartosz Golaszewski <bgolaszewski@baylibre.com.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/gpio/consumer.h>
+
+struct gpio_pwrsw_context {
+	struct gpio_desc *gpio;
+};
+
+static ssize_t gpio_pwrsw_enable_show(struct device *dev,
+				      struct device_attribute *attr,
+				      char *buf)
+{
+	struct gpio_pwrsw_context *ctx = iio_priv(dev_to_iio_dev(dev));
+	int val;
+
+	val = gpiod_get_value_cansleep(ctx->gpio);
+	if (val < 0)
+		return val;
+
+	return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t gpio_pwrsw_enable_store(struct device *dev,
+				       struct device_attribute *attr,
+				       const char *buf, size_t len)
+{
+	struct gpio_pwrsw_context *ctx = iio_priv(dev_to_iio_dev(dev));
+	bool val;
+	int ret;
+
+	ret = strtobool(buf, &val);
+	if (ret)
+		return ret;
+
+	gpiod_set_value_cansleep(ctx->gpio, val ? 1 : 0);
+
+	return len;
+}
+
+static IIO_DEVICE_ATTR(in_active, 0644,
+		       gpio_pwrsw_enable_show,
+		       gpio_pwrsw_enable_store, 0);
+
+static struct attribute *gpio_pwrsw_attributes[] = {
+	&iio_dev_attr_in_active.dev_attr.attr,
+	NULL,
+};
+
+static const struct attribute_group gpio_pwrsw_attribute_group = {
+	.attrs = gpio_pwrsw_attributes,
+};
+
+static const struct iio_info gpio_pwrsw_info = {
+	.driver_module = THIS_MODULE,
+	.attrs = &gpio_pwrsw_attribute_group,
+};
+
+static int gpio_pwrsw_probe(struct platform_device *pdev)
+{
+	struct gpio_pwrsw_context *ctx;
+	struct iio_dev *iio_dev;
+	const char *name = NULL;
+	struct device *dev;
+	bool init_state;
+	int gpio_flags;
+
+	dev = &pdev->dev;
+
+	iio_dev = devm_iio_device_alloc(dev, sizeof(*ctx));
+	if (!iio_dev)
+		return -ENOMEM;
+
+	ctx = iio_priv(iio_dev);
+
+	init_state = of_property_read_bool(dev->of_node, "power-switch-on");
+	gpio_flags = init_state ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
+
+	ctx->gpio = devm_gpiod_get(dev, "power", gpio_flags);
+	if (IS_ERR(ctx->gpio)) {
+		dev_err(dev, "unable to get the power switch gpio: %ld\n",
+			PTR_ERR(ctx->gpio));
+		return PTR_ERR(ctx->gpio);
+	}
+
+	of_property_read_string(dev->of_node, "power-switch-name", &name);
+
+	iio_dev->dev.parent = dev;
+	iio_dev->dev.of_node = dev->of_node;
+	iio_dev->name = name ? name : dev->driver->name;
+	iio_dev->info = &gpio_pwrsw_info;
+
+	return devm_iio_device_register(dev, iio_dev);
+}
+
+static const struct of_device_id gpio_pwrsw_of_match[] = {
+	{ .compatible = "gpio-power-switch", },
+	{ },
+};
+
+static struct platform_driver gpio_pwrsw_platform_driver = {
+	.probe = gpio_pwrsw_probe,
+	.driver = {
+		.name = "gpio-power-switch",
+		.of_match_table = gpio_pwrsw_of_match,
+	},
+};
+module_platform_driver(gpio_pwrsw_platform_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski@baylibre.com>");
+MODULE_DESCRIPTION("GPIO power switch driver for iio");
+MODULE_LICENSE("GPL v2");
-- 
2.9.3

Re: [PATCH 2/2] iio: misc: add support for GPIO power switches

[Linus Walleij]

On Sun, Dec 11, 2016 at 11:21 PM, Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:

> Some power-measuring ADCs work together with power load switches which
> allow to power-cycle measured devices.
>
> An example use case would be measuring the power consumption of a
> development board during boot using a power monitor such as TI INA226
> and power-cycling the board remotely using a TPS229* power switch.
>
> Add an iio driver for simple GPIO power switches and expose a sysfs
> attribute allowing to toggle their state.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

I don't get this, isn't this doing the same as
drivers/power/reset/gpio-poweroff.c
?

With the only difference that the latter uses the standard syscall
from pm_power_off to reboot the system instead of some random
sysfs file.

Yours,
Linus Walleij

Re: [PATCH 2/2] iio: misc: add support for GPIO power switches

[Sebastian Reichel]

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

Hi Linux,

On Wed, Dec 28, 2016 at 01:50:17PM +0100, Linus Walleij wrote:
> On Sun, Dec 11, 2016 at 11:21 PM, Bartosz Golaszewski
> <bgolaszewski@baylibre.com> wrote:
> 
> > Some power-measuring ADCs work together with power load switches which
> > allow to power-cycle measured devices.
> >
> > An example use case would be measuring the power consumption of a
> > development board during boot using a power monitor such as TI INA226
> > and power-cycling the board remotely using a TPS229* power switch.
> >
> > Add an iio driver for simple GPIO power switches and expose a sysfs
> > attribute allowing to toggle their state.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> 
> I don't get this, isn't this doing the same as
> drivers/power/reset/gpio-poweroff.c
> ?
> 
> With the only difference that the latter uses the standard syscall
> from pm_power_off to reboot the system instead of some random
> sysfs file.

As far as I understand it, the TPS229 is used by Barzosz to poweroff
a remote system. The gpio-poweroff driver is used to poweroff the
local system.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] iio: misc: add support for GPIO power switches

[Linus Walleij]

n Thu, Dec 29, 2016 at 5:29 PM, Sebastian Reichel <sre@kernel.org> wrote:
> On Wed, Dec 28, 2016 at 01:50:17PM +0100, Linus Walleij wrote:
>> On Sun, Dec 11, 2016 at 11:21 PM, Bartosz Golaszewski
>> <bgolaszewski@baylibre.com> wrote:
>>
>> > Some power-measuring ADCs work together with power load switches which
>> > allow to power-cycle measured devices.
>> >
>> > An example use case would be measuring the power consumption of a
>> > development board during boot using a power monitor such as TI INA226
>> > and power-cycling the board remotely using a TPS229* power switch.
>> >
>> > Add an iio driver for simple GPIO power switches and expose a sysfs
>> > attribute allowing to toggle their state.
>> >
>> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> I don't get this, isn't this doing the same as
>> drivers/power/reset/gpio-poweroff.c
>> ?
>>
>> With the only difference that the latter uses the standard syscall
>> from pm_power_off to reboot the system instead of some random
>> sysfs file.
>
> As far as I understand it, the TPS229 is used by Barzosz to poweroff
> a remote system. The gpio-poweroff driver is used to poweroff the
> local system.

Thanks yeah I understood this from the context of later patches.

Well if such a property is used it should be the property of the remote
system per se, and the remote system should then also be desribed in
DT, not half-described by dangling references at random nodes.

So this needs to be re-architected to either describe the remote system
in DT and handle it in the kernel, or handle it all from userspace if it
is a one-off non-product thing.

Yours,
Linus Walleij

Re: [PATCH 2/2] iio: misc: add support for GPIO power switches

[Jonathan Cameron]

On 30/12/16 13:05, Linus Walleij wrote:
> n Thu, Dec 29, 2016 at 5:29 PM, Sebastian Reichel <sre@kernel.org> wrote:
>> On Wed, Dec 28, 2016 at 01:50:17PM +0100, Linus Walleij wrote:
>>> On Sun, Dec 11, 2016 at 11:21 PM, Bartosz Golaszewski
>>> <bgolaszewski@baylibre.com> wrote:
>>>
>>>> Some power-measuring ADCs work together with power load switches which
>>>> allow to power-cycle measured devices.
>>>>
>>>> An example use case would be measuring the power consumption of a
>>>> development board during boot using a power monitor such as TI INA226
>>>> and power-cycling the board remotely using a TPS229* power switch.
>>>>
>>>> Add an iio driver for simple GPIO power switches and expose a sysfs
>>>> attribute allowing to toggle their state.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>
>>> I don't get this, isn't this doing the same as
>>> drivers/power/reset/gpio-poweroff.c
>>> ?
>>>
>>> With the only difference that the latter uses the standard syscall
>>> from pm_power_off to reboot the system instead of some random
>>> sysfs file.
>>
>> As far as I understand it, the TPS229 is used by Barzosz to poweroff
>> a remote system. The gpio-poweroff driver is used to poweroff the
>> local system.
> 
> Thanks yeah I understood this from the context of later patches.
> 
> Well if such a property is used it should be the property of the remote
> system per se, and the remote system should then also be desribed in
> DT, not half-described by dangling references at random nodes.
> 
> So this needs to be re-architected to either describe the remote system
> in DT and handle it in the kernel, or handle it all from userspace if it
> is a one-off non-product thing.
I'm not sure this is always true (though it might be here).  There is always
a need to describe the edge of the known world.  Be it that we have
an accelerometer - ultimately we could describe the device generating the
acceleration but we have no way of knowing what it is or what it will do..

What we have here is a rather simple case, but what about an I/O bank on
a PLC.  Obviously we can handle that as a bunch of GPIOs but if we know
more about it we should have means to describe that.  Say we know they are
always driving relays, we should be able to describe that additional known
stuff. Relays have characteristics such as bounce times etc that if described
would allow us to do the relevant filtering on inputs to handle this.

Here the fact it is a power supply switch should be describable.  Hard to
get right in a generic way though so in cases like this perhaps you
are right and it should just be left undescribed and handled in userspace.

Anyhow, here I think leaving it as a gpio interface is probably the way to
go, but I'm not sure that will always be the case.

Jonathan
> 
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 2/2] iio: misc: add support for GPIO power switches

[Linus Walleij]

On Fri, Dec 30, 2016 at 4:15 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 30/12/16 13:05, Linus Walleij wrote:

>> So this needs to be re-architected to either describe the remote system
>> in DT and handle it in the kernel, or handle it all from userspace if it
>> is a one-off non-product thing.
>
> I'm not sure this is always true (though it might be here).  There is always
> a need to describe the edge of the known world.  Be it that we have
> an accelerometer - ultimately we could describe the device generating the
> acceleration but we have no way of knowing what it is or what it will do..
>
> What we have here is a rather simple case, but what about an I/O bank on
> a PLC.  Obviously we can handle that as a bunch of GPIOs but if we know
> more about it we should have means to describe that.  Say we know they are
> always driving relays, we should be able to describe that additional known
> stuff. Relays have characteristics such as bounce times etc that if described
> would allow us to do the relevant filtering on inputs to handle this.
>
> Here the fact it is a power supply switch should be describable.  Hard to
> get right in a generic way though so in cases like this perhaps you
> are right and it should just be left undescribed and handled in userspace.
>
> Anyhow, here I think leaving it as a gpio interface is probably the way to
> go, but I'm not sure that will always be the case.

No you are right. We are at the fuzzy system perimeter.

For GPIO we currently only have asserted/unasserted, polarity
of that, open drain/source and debounce time. But we will need the whole
slew of pin control settings in the future: drive strength, schmitt-trigger
hysteresis etc etc. And if there is a further component beyond that it
may need a driver in turn even if it is "only" a relay.

Let's see about this one...

Yours,
Linus Walleij