From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF Date: Wed, 25 Jan 2017 10:44:32 -0800 Message-ID: <20170125184432.GA27255@dtor-ws> References: <20170125000641.25520-1-furquan@chromium.org> <20170125124911.dxveow7bo3zw5jcc@sirena.org.uk> <20170125182319.GB25470@leverpostej> <20170125182955.uznr5ehpx4dabcon@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pf0-f194.google.com ([209.85.192.194]:34543 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751925AbdAYSog (ORCPT ); Wed, 25 Jan 2017 13:44:36 -0500 Content-Disposition: inline In-Reply-To: <20170125182955.uznr5ehpx4dabcon@sirena.org.uk> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Mark Brown Cc: Mark Rutland , Furquan Shaikh , "Rafael J. Wysocki" , "Rafael J . Wysocki" , Liam Girdwood , Tony Lindgren , Len Brown , Greg Kroah-Hartman , Lorenzo Pieralisi , Hanjun Guo , Will Deacon , Rob Herring , Sathyanarayana Nujella , Heikki Krogerus , Adam Thomson , Linus Walleij , Alexandre Courbot , linux-gpio@vger.kernel.org, ACPI Devel Maling List On Wed, Jan 25, 2017 at 06:29:55PM +0000, Mark Brown wrote: > On Wed, Jan 25, 2017 at 06:23:20PM +0000, Mark Rutland wrote: > > On Wed, Jan 25, 2017 at 08:56:42AM -0800, Furquan Shaikh wrote: > > > > That is the reason why the recent change to add ACPI support to fixed > > > regulators was done > > > (https://github.com/torvalds/linux/blob/master/drivers/regulator/fixed.c#L100). > > > To be honest, I'm surprised this got merged. > > My understanding was that it was instantiated from another device as an > implementation detail of that device, letting it say "this GPIO should > be handled as a regulator". > > > Mark, this was added in this cycle; can we please rip that out for now? > > If it's instantiated directly we probably should. > > > We can certainly come up with something that allows drivers to support > > both, but trying to do this without updating drivers opens a huge set of > > problems. > > I think there's a reasonable chance that any ACPI specs could be written > in such a way as to allow transparent support in Linux, the main thing > I'd worry about is naming issues. So if I am reading this correctly, currently ACPI does not expose power supplies directly, but rather ties them to the device power state (D0, D3cold, etc). Linux drivers do not usually follow that state model and expect to have all their power supplies be given to them and then figures out what to do with them itself. Given that, what do we do? Do we map only entries from _PR3 so they are available to drivers via regulator_get()? Or we ask the standard to add method enumerating all supplies? Thanks. -- Dmitry From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752251AbdAYSoj (ORCPT ); Wed, 25 Jan 2017 13:44:39 -0500 Received: from mail-pf0-f194.google.com ([209.85.192.194]:34543 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751925AbdAYSog (ORCPT ); Wed, 25 Jan 2017 13:44:36 -0500 Date: Wed, 25 Jan 2017 10:44:32 -0800 From: Dmitry Torokhov To: Mark Brown Cc: Mark Rutland , Furquan Shaikh , "Rafael J. Wysocki" , "Rafael J . Wysocki" , Liam Girdwood , Tony Lindgren , Len Brown , Greg Kroah-Hartman , Lorenzo Pieralisi , Hanjun Guo , Will Deacon , Rob Herring , Sathyanarayana Nujella , Heikki Krogerus , Adam Thomson , Linus Walleij , Alexandre Courbot , linux-gpio@vger.kernel.org, ACPI Devel Maling List , Linux Kernel Mailing List , Linux OMAP Mailing List , Aaron Durbin , dlaurie@chromium.org Subject: Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF Message-ID: <20170125184432.GA27255@dtor-ws> References: <20170125000641.25520-1-furquan@chromium.org> <20170125124911.dxveow7bo3zw5jcc@sirena.org.uk> <20170125182319.GB25470@leverpostej> <20170125182955.uznr5ehpx4dabcon@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170125182955.uznr5ehpx4dabcon@sirena.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 25, 2017 at 06:29:55PM +0000, Mark Brown wrote: > On Wed, Jan 25, 2017 at 06:23:20PM +0000, Mark Rutland wrote: > > On Wed, Jan 25, 2017 at 08:56:42AM -0800, Furquan Shaikh wrote: > > > > That is the reason why the recent change to add ACPI support to fixed > > > regulators was done > > > (https://github.com/torvalds/linux/blob/master/drivers/regulator/fixed.c#L100). > > > To be honest, I'm surprised this got merged. > > My understanding was that it was instantiated from another device as an > implementation detail of that device, letting it say "this GPIO should > be handled as a regulator". > > > Mark, this was added in this cycle; can we please rip that out for now? > > If it's instantiated directly we probably should. > > > We can certainly come up with something that allows drivers to support > > both, but trying to do this without updating drivers opens a huge set of > > problems. > > I think there's a reasonable chance that any ACPI specs could be written > in such a way as to allow transparent support in Linux, the main thing > I'd worry about is naming issues. So if I am reading this correctly, currently ACPI does not expose power supplies directly, but rather ties them to the device power state (D0, D3cold, etc). Linux drivers do not usually follow that state model and expect to have all their power supplies be given to them and then figures out what to do with them itself. Given that, what do we do? Do we map only entries from _PR3 so they are available to drivers via regulator_get()? Or we ask the standard to add method enumerating all supplies? Thanks. -- Dmitry