Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Peter Chen <peter.chen@nxp.com>
To:     Mark Brown <broonie@kernel.org>
CC:     "lgirdwood@gmail.com" <lgirdwood@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH 1/1] regulator: fixed: add system pm routines for pinctrl
Thread-Topic: [PATCH 1/1] regulator: fixed: add system pm routines for pinctrl
Thread-Index: AQHV+FpZgufkrsn3KkuJmHgdNm1nAKhE1zoAgAAUhICAABsJgIAAB0wAgAABBgCAAMmjgIAAl32AgAAST4A=
Date:   Fri, 13 Mar 2020 13:16:31 +0000
Message-ID: <20200313131635.GA28281@b29397-desktop>
References: <20200312103804.24174-1-peter.chen@nxp.com>
 <20200312114712.GA4038@sirena.org.uk> <20200312130037.GG14625@b29397-desktop>
 <20200312143723.GF4038@sirena.org.uk> <20200312150330.GH14625@b29397-desktop>
 <20200312150710.GG4038@sirena.org.uk> <20200313030851.GI14625@b29397-desktop>
 <20200313121103.GD5528@sirena.org.uk>
In-Reply-To: <20200313121103.GD5528@sirena.org.uk>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C3ABE5A5AD6A6647B087BE94FA16DFD9@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6fc34e44-45ee-4557-7b5f-08d7c750bf87
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2020 13:16:31.9663
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vnQxNIESk7X0iXRgi0q+GGqI/SX6iCTPPsXzFUuUNs8TtZezWET8A+r8viqfr8ZOckiyjCTarEqhsdDvOLryEQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4495
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 20-03-13 12:11:03, Mark Brown wrote:
> On Fri, Mar 13, 2020 at 03:08:48AM +0000, Peter Chen wrote:
> > On 20-03-12 15:07:10, Mark Brown wrote:
>=20
> > > I'd expect that this would be handled by the GPIO driver, the user
> > > shouldn't need to care.
>=20
> > GPIO function is just our case for this fixed regulator, other users fo=
r
> > this fixed regulator may set pinctrl as other functions.
>=20
> > Here, it is just save and restore pinctrl value for fixed regulator
> > driver, not related to GPIO.
>=20
> My point is that the fixed regulator doesn't have pins in pinctrl,
> whatever is providing the control signal to the fixed voltage regulator
> (if there is one) does.  I'd expect this to be being handled on the
> producer side rather than the consumer.

I am sorry I have different points.

Most of pins for controlling fixed regulator on or off is GPIO, but how
GPIO driver handles this? We usually configure pin as GPIO function at
its user's node (Eg, reset pin for most drivers), but not GPIO node,
GPIO node is usually per SoC, not per board level.

So, I am wondering why fixed regulator can't have a pin in pinctrl.
If you grep the dts, there are already several fixed regulator has
pinctrl.

--=20

Thanks,
Peter Chen=