Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752035AbdHHJkx (ORCPT ); Tue, 8 Aug 2017 05:40:53 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:57386 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751464AbdHHJkv (ORCPT ); Tue, 8 Aug 2017 05:40:51 -0400 Date: Tue, 8 Aug 2017 10:39:47 +0100 From: Mark Brown To: Hans de Goede Cc: Guenter Roeck , Darren Hart , Andy Shevchenko , Wolfram Sang , Sebastian Reichel , Greg Kroah-Hartman , Heikki Krogerus , Liam Girdwood , platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, Liam Breck , Tony Lindgren , linux-pm@vger.kernel.org, devel@driverdev.osuosl.org Message-ID: <20170808093947.ezczjb6stdgek4hy@sirena.org.uk> References: <5f3d7cfa-c993-0cda-fae6-a975f7d4ca1c@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ujy25oqi53cn24gn" Content-Disposition: inline In-Reply-To: <5f3d7cfa-c993-0cda-fae6-a975f7d4ca1c@redhat.com> X-Cookie: Do you like "TENDER VITTLES"? User-Agent: NeoMutt/20170609 (1.8.3) X-SA-Exim-Connect-IP: 2001:470:1f1d:6b5:7e7a:91ff:fede:4a45 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 10/18] staging: typec: fusb302: Add support for fcs,vbus-regulator-name device-property X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: No (on mezzanine.sirena.org.uk); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2145 Lines: 60 --ujy25oqi53cn24gn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 07, 2017 at 09:20:05PM +0200, Hans de Goede wrote: > On 07-08-17 17:41, Mark Brown wrote: > > I2C has a perfectly good platform_data pointer in the board info for > > this stuff. > True, so you are suggesting that I define a bq24190_platform_data > struct with a regulator_init_data pointer in there I guess? Yes. =20 > I don't think the power-supply maintainers will be enthusiastic > about this (hi Sebastian). But that does make sense and is > actually a good idea for tackling the problem of regulator_init_data. Why not? This is just really standard usage of platform data. > Would extending the struct regulator_map with a const char *provider_name: > struct regulator_map { > struct list_head list; > const char *dev_name; /* The dev_name() for the consumer */ > const char *supply; > struct regulator_dev *regulator; > const char *provider; /* The dev_name() for the regulator parent-dev */ > }; Please don't invent new terminology like this. Just call it a regulator name. > Alternatively the entry could additionally contain a provider_supply_name > so that we can make arbitrary consumer-dev-name + consumer-supply-name > provider-dev-name + provider-supply-name matches. That would probably > be more flexible then requiring the supply name to match. I'm sorry but I can't follow what you mean here. What do you mean by "provider_supply_name"? --ujy25oqi53cn24gn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlmJhuIACgkQJNaLcl1U h9BGaAf+LfNpR+egdlA8mhuvZKvRfRMpSLj3MJmOAgN+nMwlvJvp7fXnGRfmnwCO QY6hxGv4Ty3bA3FKnOagmeHves1tQTIkIJJkm7iOkXx+xzFXbi33PuoI3+VrSPXO /hKepOXFZfkKRvZKEZMZjz8CQC+qSjTf1JtpDbQ5GPBCTHklhIfntU9mtS5UxJ+V QYTL80l75NhlsNKMNGyxJHq8iho671pU+rEzBugkV84vROYjU0OxLYjsy0Jf1pdM p7hqw68epC6S86LpE2H02J2zHUvhUTE887y95lV+UKwydKkDZD9VohqMIkGadF5a c8rEB0ysFBkOEOMXvE4YkIH2qCINrw== =u3k9 -----END PGP SIGNATURE----- --ujy25oqi53cn24gn--