linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: 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>
Cc: 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 18/18] i2c-cht-wc: Add device-properties for fusb302 integration
Date: Sun, 6 Aug 2017 17:05:47 +0200	[thread overview]
Message-ID: <ae6fcdce-1dd0-d29f-ce04-9d9c77f14730@redhat.com> (raw)
In-Reply-To: <9ba933c6-daae-f30d-2c83-e9c2b756d27f@roeck-us.net>

Hi,

On 06-08-17 16:35, Guenter Roeck wrote:
> On 08/06/2017 05:35 AM, Hans de Goede wrote:
>> Add device-properties to make the bq24292i controller connected to
>> the bus get its input-current-limit from the fusb302 Type-C port
>> controller which is used on boards with the cht-wc PMIC.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>>   drivers/i2c/busses/Kconfig      | 5 +++++
>>   drivers/i2c/busses/i2c-cht-wc.c | 5 ++++-
>>   2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index f20b1f84013a..6de21a81b00b 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -197,6 +197,11 @@ config I2C_CHT_WC
>>         SMBus controller found in the Intel Cherry Trail Whiskey Cove PMIC
>>         found on some Intel Cherry Trail systems.
>> +      Note this controller is hooked up to a TI bq24292i charger-IC,
>> +      combined with a FUSB302 Type-C port-controller as such it is advised
>> +      to also select CONFIG_CHARGER_BQ24190=m and CONFIG_TYPEC_FUSB302=m
>> +      (the fusb302 driver currently is in drivers/staging).
>> +
> 
> Just wondering - is this always the case ? What if someone builds a system with
> different charger and port controller ICs ?

A very valid question, if another charger is used then hopefully it will
have a different i2c address and if it doesn't it should fail the id-register
check in the bq24190 driver unless we get really unlucky. So if this happens
the bq24190 driver should fail to probe.

The code handling the INT33FE ACPI device, which contains the i2c bus
and address info for the FUSB302 has this check:

         /*
          * We expect the Whiskey Cove PMIC to be paired with a TI bq24292i
          * charger-IC, allowing charging with up to 12V, so we set the fusb302
          * "fcs,max-snk-mv" device property to 12000 mV. Allowing 12V with
          * another charger-IC is not a good idea, so we get the bq24292i vbus
          * regulator here, to ensure that things are as expected.
          * Use regulator_get_optional so that we don't get a dummy-regulator.
          */
         regulator = regulator_get_optional(dev, BQ24292I_REGULATOR);
         if (IS_ERR(regulator)) {
                 ret = PTR_ERR(regulator);
                 return (ret == -ENODEV) ? -EPROBE_DEFER : ret;
         }
         regulator_put(regulator);

So if the bq24190 probe fails and it does not register its regulator, the
i2c-client for the fusb302 will never gets instantiated. Which means that
if a different charger-IC is used the user will get a bunch of errors and
nothing will happen.

If a different port-controller is used, then I would expect there to no
be a INT33FE ACPI device, with PTYP==4 as PTYP==4 seems to be used
to describe the Whiskey Cove PMIC + bq24190 charger + fusb302 combo,
but this is all undocumented, so no guarantees. I've added the above
code because of this, because I really don't want to negotiate a voltage
higher then 5V with an unknown charger-IC.

FWIW all DSTDs I've seen are all copy and paste and all declare a INT33FE ACPI
device with identical i2c client addresses which strongly suggests the
use of the same combo. Note that on most devices this part of the DSTD is
not active (_STA returns 0) because they actually use a different config.

The only extra safe-guard I can come up with is a DMI string check, but that
is sub-optimal since the DMI strings on these devices contain useful values
as "Default String" still we could add it as an extra check.

Since I had the same concern I've done a web search and I've been unable
to find any other devices which seem to use a Whiskey Cove PMIC, but that
does not mean that there aren't any.

Regards,

Hans






> 
>>   config I2C_NFORCE2
>>       tristate "Nvidia nForce2, nForce3 and nForce4"
>>       depends on PCI
>> diff --git a/drivers/i2c/busses/i2c-cht-wc.c b/drivers/i2c/busses/i2c-cht-wc.c
>> index ccf0785bcb75..08229fb12615 100644
>> --- a/drivers/i2c/busses/i2c-cht-wc.c
>> +++ b/drivers/i2c/busses/i2c-cht-wc.c
>> @@ -211,8 +211,11 @@ static const struct irq_chip cht_wc_i2c_irq_chip = {
>>       .name            = "cht_wc_ext_chrg_irq_chip",
>>   };
>> +static const char * const bq24190_suppliers[] = { "fusb302-typec-source" };
>> +
>>   static const struct property_entry bq24190_props[] = {
>> -    PROPERTY_ENTRY_STRING("extcon-name", "cht_wcove_pwrsrc"),
>> +    PROPERTY_ENTRY_STRING_ARRAY("supplied-from", bq24190_suppliers),
>> +    PROPERTY_ENTRY_BOOL("input-current-limit-from-supplier"),
>>       PROPERTY_ENTRY_BOOL("omit-battery-class"),
>>       PROPERTY_ENTRY_BOOL("disable-reset"),
>>       { }
>>
> 

  reply	other threads:[~2017-08-06 15:05 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   ` [PATCH 10/18] staging: typec: fusb302: Add support for fcs,vbus-regulator-name device-property 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
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 [this message]
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=ae6fcdce-1dd0-d29f-ce04-9d9c77f14730@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andy@infradead.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.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).