On 30/12/16 13:05, Linus Walleij wrote: > n Thu, Dec 29, 2016 at 5:29 PM, Sebastian Reichel <sre@xxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> >>> >>> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
