linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Hans de Goede <hdegoede@redhat.com>,
	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 04/18] staging: typec: tcpm: Add helpers for exporting current-limit through a psy
Date: Sun, 6 Aug 2017 07:41:48 -0700	[thread overview]
Message-ID: <492365cb-7a3b-b8e4-8d47-e4ae34eb0ed2@roeck-us.net> (raw)
In-Reply-To: <b27b0571-f888-ec26-19fe-0f82adb9d5b2@redhat.com>

On 08/06/2017 07:21 AM, Hans de Goede wrote:
> Hi,
> 
> On 06-08-17 16:13, Guenter Roeck wrote:
>> On 08/06/2017 05:35 AM, Hans de Goede wrote:
>>> Not all type-c port-controller can control the current-limit directly,
>>> in cases where the current limit can not be controlled directly it needs
>>> to be exported so that another driver (e.g. the charger driver) can pick
>>> the limit up and configure the system accordingly.
>>>
>>> The power-supply subsys already provides infrastructure for this,
>>> power-supply devices have the notion of being supplied by another
>>> power-supply and have properties through which we can export the
>>> current-limit.
>>>
>>> This commits adds 2 helper functions for use by port-controller drivers
>>> which want to export the current-limit info in this way:
>>>
>>> int tcpm_register_psy(struct device *dev, struct tcpc_dev *tcpc,
>>>               const char *name);
>>> int tcpm_set_current_limit_psy(struct tcpc_dev *tcpc, u32 max_ma, u32 mv);
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>>   drivers/staging/typec/tcpm-helpers.c | 66 ++++++++++++++++++++++++++++++++++++
>>>   drivers/staging/typec/tcpm.h         |  9 +++++
>>>   2 files changed, 75 insertions(+)
>>>
>>> diff --git a/drivers/staging/typec/tcpm-helpers.c b/drivers/staging/typec/tcpm-helpers.c
>>> index 0c87ec9936e1..8f7699576878 100644
>>> --- a/drivers/staging/typec/tcpm-helpers.c
>>> +++ b/drivers/staging/typec/tcpm-helpers.c
>>> @@ -20,6 +20,60 @@
>>>   #include "tcpm.h"
>>> +static int tcpm_psy_get_property(struct power_supply *psy,
>>> +                 enum power_supply_property psp,
>>> +                 union power_supply_propval *val)
>>> +{
>>> +    struct tcpc_dev *tcpc = power_supply_get_drvdata(psy);
>>> +
>>> +    switch (psp) {
>>> +    case POWER_SUPPLY_PROP_VOLTAGE_NOW:
>>> +        val->intval = tcpc->supply_voltage * 1000; /* mV -> µV */
>>> +        break;
>>> +    case POWER_SUPPLY_PROP_CURRENT_MAX:
>>> +        val->intval = tcpc->current_limit * 1000; /* mA -> µA */
>>> +        break;
>>> +    default:
>>> +        return -ENODATA;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static enum power_supply_property tcpm_psy_properties[] = {
>>> +    POWER_SUPPLY_PROP_VOLTAGE_NOW,
>>> +    POWER_SUPPLY_PROP_CURRENT_MAX,
>>> +};
>>> +
>>> +int tcpm_register_psy(struct device *dev, struct tcpc_dev *tcpc,
>>> +              const char *name)
>>
>> This is misleading since it relies on devm functions, and there is no unregister function.
> 
> The reliance on devm functions is intentional, that makes cleanup on probe() failure for users
> of this a lot easier. I guess we could rename this tcpm_initialize_psy(), although it does
> actually register a psy, so maybe: devm_tcpm_register_psy() to explain why there is no
> unregister counter-part ?
> 

I don't question the use of devm functions. Yes, I think devm_tcpm_register_psy() would be better.

>> Overall I am not too happy with tying this all into tcpm. The functions are not really tcpm
>> related. Not that I have a better idea how to handle this right now, but conceptually it
>> doesn't seem correct.
> 
> Note that no changes are made to the tcpm core in this entire patch-set, with the exception
> of the first patch which adds the get_usb2_current_limit callback.
> 
Yes, but you are using tcpm data structures. Of this entire series, I think only the callback
(renamed to get_usb_current_limit) should really be in tcpm code. Maybe it makes sense to find
a way to provide helpers in a generic way, if it turns out that the same code is needed by multiple
drivers, but right now they are only used by fusb302 and might as well stay there.

Until other drivers need them, we don't really know if the helpers are useful for multiple drivers.
I would prefer to add such helpers if and when we have more than one driver using them.

Thanks,
Guenter

> This really only ties into the port-controller driver, and as such uses tcpc_dev to store some
> stuff. I could make this more clear by prefixing the helper function names with tcpc instead of
> tcpm if you think that is better ?
> 
> Regards,
> 
> Hans
> 
> 
>>
>>> +{
>>> +    struct power_supply_config psy_cfg = {};
>>> +    struct power_supply_desc *desc;
>>> +    int ret = 0;
>>> +
>>> +    desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
>>> +    if (!desc)
>>> +        return -ENOMEM;
>>> +
>>> +    desc->name        = name;
>>> +    desc->type        = POWER_SUPPLY_TYPE_USB;
>>> +    desc->properties    = tcpm_psy_properties;
>>> +    desc->num_properties    = ARRAY_SIZE(tcpm_psy_properties);
>>> +    desc->get_property    = tcpm_psy_get_property;
>>> +    psy_cfg.drv_data    = tcpc;
>>> +
>>> +    tcpc->psy = devm_power_supply_register(dev, desc, &psy_cfg);
>>> +    if (IS_ERR(tcpc->psy)) {
>>> +        ret = PTR_ERR(tcpc->psy);
>>> +        tcpc->psy = NULL;
>>> +        dev_err(dev, "Error registering power-supply: %d\n", ret);
>>> +    }
>>> +
>>> +    return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(tcpm_register_psy);
>>> +
>>>   /* Generic (helper) implementations for some tcpc_dev callbacks */
>>>   int tcpm_get_usb2_current_limit_extcon(struct tcpc_dev *tcpc)
>>>   {
>>> @@ -58,3 +112,15 @@ int tcpm_get_usb2_current_limit_extcon(struct tcpc_dev *tcpc)
>>>       return current_limit;
>>>   }
>>>   EXPORT_SYMBOL_GPL(tcpm_get_usb2_current_limit_extcon);
>>> +
>>> +int tcpm_set_current_limit_psy(struct tcpc_dev *tcpc, u32 max_ma, u32 mv)
>>> +{
>>> +    tcpc->supply_voltage = mv;
>>> +    tcpc->current_limit = max_ma;
>>> +
>>> +    if (tcpc->psy)
>>> +        power_supply_changed(tcpc->psy);
>>> +
>>> +    return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(tcpm_set_current_limit_psy);
>>> diff --git a/drivers/staging/typec/tcpm.h b/drivers/staging/typec/tcpm.h
>>> index 35e8c1e7dba0..1b1475b487b5 100644
>>> --- a/drivers/staging/typec/tcpm.h
>>> +++ b/drivers/staging/typec/tcpm.h
>>> @@ -17,6 +17,7 @@
>>>   #include <linux/bitops.h>
>>>   #include <linux/extcon.h>
>>> +#include <linux/power_supply.h>
>>>   #include <linux/usb/typec.h>
>>>   #include "pd.h"
>>> @@ -129,6 +130,10 @@ struct tcpc_dev {
>>>       struct tcpc_mux_dev *mux;
>>>       /* Used by tcpm_get_usb2_current_limit_extcon helpers */
>>>       struct extcon_dev *usb2_extcon;
>>> +    /* Used by tcpm_set_current_limit_psy helpers */
>>> +    struct power_supply *psy;
>>> +    u32 current_limit;
>>> +    u32 supply_voltage;
>>>   };
>>>   struct tcpm_port;
>>> @@ -154,7 +159,11 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
>>>   void tcpm_pd_hard_reset(struct tcpm_port *port);
>>>   void tcpm_tcpc_reset(struct tcpm_port *port);
>>> +int tcpm_register_psy(struct device *dev, struct tcpc_dev *tcpc,
>>> +              const char *name);
>>> +
>>>   /* Generic (helper) implementations for some tcpc_dev callbacks */
>>>   int tcpm_get_usb2_current_limit_extcon(struct tcpc_dev *tcpc);
>>> +int tcpm_set_current_limit_psy(struct tcpc_dev *tcpc, u32 max_ma, u32 mv);
>>>   #endif /* __LINUX_USB_TCPM_H */
>>>
>>
> 

  reply	other threads:[~2017-08-06 14:41 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 [this message]
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
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=492365cb-7a3b-b8e4-8d47-e4ae34eb0ed2@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=andy@infradead.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --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=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).