From: Hans de Goede <hdegoede@redhat.com>
To: Mark Brown <broonie@kernel.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
Wolfram Sang <wsa@the-dreams.de>,
Sebastian Reichel <sre@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Liam Girdwood <lgirdwood@gmail.com>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
Liam Breck <liam@networkimprov.net>,
Tony Lindgren <tony@atomide.com>,
linux-pm@vger.kernel.org, devel@driverdev.osuosl.org
Subject: Re: [PATCH 10/18] staging: typec: fusb302: Add support for fcs,vbus-regulator-name device-property
Date: Mon, 7 Aug 2017 21:20:05 +0200 [thread overview]
Message-ID: <5f3d7cfa-c993-0cda-fae6-a975f7d4ca1c@redhat.com> (raw)
In-Reply-To: <20170807154152.wt5b4y3s3oe4cnam@sirena.org.uk>
Hi,
On 07-08-17 17:41, Mark Brown wrote:
> On Mon, Aug 07, 2017 at 04:41:18PM +0200, Hans de Goede wrote:
>> On 07-08-17 13:10, Mark Brown wrote:
>
>> Problem 1)
>
>> The regulator in question is part of the bq24292i charger-IC attached to
>> a private i2c bus between the PMIC and the charger. The driver for the i2c
>> controller inside the PMIC which drivers this bus currently also instantiates
>> the i2c-client for the charger:
>
> ...
>
>> Note that the bq24190 driver is a generic driver, so to pass the
>> board specific regulator_init_data to it I would need to somehow
>> pass it here, but I don't see how, except by storing a pointer to
>> it in an u64 device-property which seems like a bad idea
>
> 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?
At least I would not want to just claim that pointer for
just regulator_init_data and more-over assuming that what
is in there will be regulator_init_data feels wrong.
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.
>> Problem 2)
>
>> Even if I could add the mapping through regulator_init_data
>> then it may well be too late, if the regulator_get happens
>> before the bq24190 driver registers its regulator (and thus
>> the mapping) the regulator_get for it may have already
>> happened and returned a dummy-regulator, or another regulator
>> with the rather generic vbus name.
>
> If you don't have control over the instantiation ordering
It is not just device-instantiation ordering, it is also driver
loading order, the event around which ordering needs to happen is
the registration of the regulator (as things are now).
> but you have a firmware which claims to provide a complete description of regulators
> then you'd need to add an interface that allows mappings to be
> registered separately to regulator registration.
So the pwm subsys has this pwm_add_table thing which can add lookup
entries indepdentent of pwm_registration and which uses supply/device_name
matching to find the entry for the caller of pwm_get which is the same as
the current lookup code in the regulator-core, but since it is
independent of the registration the lookup-table does not contain
direct pointers to pwmchip-s instead it uses a string which gets
matches against the pwm (parent) dev's dev_name().
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 */
};
And having a regulator_add_lookup function which adds an entry to the
regulator_map_list which sets provider_name instead of regulator
be acceptable ?
lookup of such entries would look for regulators where supply
matches the regulator-name and provider matches the
regulators parent-dev-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.
So would something like this (including returning -EPROBE_DEFER if there
is a pwm_map_list entry and no matching regulator can be found) acceptable ?
> Whatever you're doing the answer isn't to try to specify the name of the
> supply through some firmware binding, that's just obviously not sensible
> both in terms of a firmware abstraction and in terms of how the
> abstractions in Linux work.
Ok.
Regards,
Hans
next prev parent reply other threads:[~2017-08-07 19:20 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-06 12:35 [PATCH 00/18] Hookup typec power-negotation to the PMIC and charger Hans de Goede
2017-08-06 12:35 ` [PATCH 01/18] staging: typec: tcpm: Add get_usb2_current_limit tcpc_dev callback Hans de Goede
2017-08-06 14:18 ` Guenter Roeck
2017-08-06 14:29 ` Hans de Goede
2017-08-06 14:52 ` Guenter Roeck
2017-08-06 12:35 ` [PATCH 02/18] staging: typec: tcpm: Add extcon helper functions for USB2 current limit detect Hans de Goede
2017-08-06 14:07 ` Guenter Roeck
2017-08-06 12:35 ` [PATCH 03/18] staging: typec: tcpm: Split tcpm code into tcpm-core.c and tcpm-helpers.c Hans de Goede
2017-08-06 12:35 ` [PATCH 04/18] staging: typec: tcpm: Add helpers for exporting current-limit through a psy Hans de Goede
2017-08-06 14:13 ` Guenter Roeck
2017-08-06 14:21 ` Hans de Goede
2017-08-06 14:41 ` Guenter Roeck
2017-08-06 12:35 ` [PATCH 05/18] staging: typec: fusb302: Set max supply voltage to 5V Hans de Goede
2017-08-06 12:35 ` [PATCH 06/18] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties Hans de Goede
2017-08-06 14:03 ` Guenter Roeck
2017-08-06 12:35 ` [PATCH 07/18] staging: typec: fusb302: Use client->irq as irq if set Hans de Goede
2017-08-06 12:35 ` [PATCH 08/18] staging: typec: fusb302: Add support for USB2 charger detection through extcon Hans de Goede
2017-08-06 14:22 ` Guenter Roeck
2017-08-06 14:36 ` Hans de Goede
2017-08-06 14:58 ` Guenter Roeck
2017-08-06 12:35 ` [PATCH 09/18] staging: typec: fusb302: Use tcpm_set_current_limit_psy Hans de Goede
2017-08-06 14:24 ` Guenter Roeck
2017-08-06 12:35 ` [PATCH 10/18] staging: typec: fusb302: Add support for fcs,vbus-regulator-name device-property Hans de Goede
2017-08-06 14:30 ` Guenter Roeck
2017-08-06 14:52 ` Hans de Goede
2017-08-06 15:20 ` Guenter Roeck
2017-08-06 15:44 ` Hans de Goede
2017-08-07 11:10 ` Mark Brown
2017-08-07 14:41 ` Hans de Goede
2017-08-07 15:41 ` Mark Brown
2017-08-07 19:20 ` Hans de Goede [this message]
2017-08-08 9:39 ` Mark Brown
[not found] ` <0b75c318-0f71-c536-7c7f-9ba16b215690@redhat.com>
[not found] ` <20170808144217.c2fm25uge75p4lo2@sirena.org.uk>
2017-08-08 20:53 ` Hans de Goede
2017-08-06 12:35 ` [PATCH 11/18] power: supply: Fix power_supply_am_i_supplied to return -ENODEV when apropriate Hans de Goede
2017-08-06 14:31 ` Guenter Roeck
2017-08-06 14:54 ` Hans de Goede
2017-08-06 12:35 ` [PATCH 12/18] power: supply: Add power_supply_set_input_current_limit_from_supplier helper Hans de Goede
2017-08-06 12:35 ` [PATCH 13/18] power: supply: bq24190_charger: Export 5V boost converter as regulator Hans de Goede
2017-08-08 4:15 ` Tony Lindgren
2017-08-08 8:39 ` Liam Breck
2017-08-08 9:00 ` Hans de Goede
2017-08-08 18:57 ` Liam Breck
2017-08-08 21:09 ` Hans de Goede
2017-08-06 12:35 ` [PATCH 14/18] power: supply: bq24190_charger: Add input_current_limit property Hans de Goede
2017-08-06 12:35 ` [PATCH 15/18] power: supply: bq24190_charger: Get input_current_limit from our supplier Hans de Goede
2017-08-08 8:24 ` Liam Breck
2017-08-08 9:11 ` Hans de Goede
2017-08-06 12:35 ` [PATCH 16/18] power: supply: bq24190_charger: Remove extcon handling Hans de Goede
2017-08-08 8:27 ` Liam Breck
2017-08-08 9:12 ` Hans de Goede
2017-08-06 12:35 ` [PATCH 17/18] platform/x86: intel_cht_int33fe Update fusb302 type string, add properties Hans de Goede
2017-08-06 12:35 ` [PATCH 18/18] i2c-cht-wc: Add device-properties for fusb302 integration Hans de Goede
2017-08-06 14:35 ` Guenter Roeck
2017-08-06 15:05 ` Hans de Goede
2017-08-06 16:29 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5f3d7cfa-c993-0cda-fae6-a975f7d4ca1c@redhat.com \
--to=hdegoede@redhat.com \
--cc=andy@infradead.org \
--cc=broonie@kernel.org \
--cc=devel@driverdev.osuosl.org \
--cc=dvhart@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=lgirdwood@gmail.com \
--cc=liam@networkimprov.net \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=platform-driver-x86@vger.kernel.org \
--cc=sre@kernel.org \
--cc=tony@atomide.com \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).