[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Aug 2017 10:39:47 +0100
From: Mark Brown <broonie@...nel.org>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Guenter Roeck <linux@...ck-us.net>,
Darren Hart <dvhart@...radead.org>,
Andy Shevchenko <andy@...radead.org>,
Wolfram Sang <wsa@...-dreams.de>,
Sebastian Reichel <sre@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Liam Girdwood <lgirdwood@...il.com>,
platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-i2c@...r.kernel.org, Liam Breck <liam@...workimprov.net>,
Tony Lindgren <tony@...mide.com>, linux-pm@...r.kernel.org,
devel@...verdev.osuosl.org
Subject: Re: [PATCH 10/18] staging: typec: fusb302: Add support for
fcs,vbus-regulator-name device-property
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.
> 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"?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists