From: Jun Li <jun.li@nxp.com>
To: Baolin Wang <baolin.wang@linaro.org>
CC: "balbi@kernel.org" <balbi@kernel.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "sre@kernel.org" <sre@kernel.org>,
        "dbaryshkov@gmail.com" <dbaryshkov@gmail.com>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "peter.chen@freescale.com" <peter.chen@freescale.com>,
        "stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
        "r.baldyga@samsung.com" <r.baldyga@samsung.com>,
        "yoshihiro.shimoda.uh@renesas.com" <yoshihiro.shimoda.uh@renesas.com>,
        "lee.jones@linaro.org" <lee.jones@linaro.org>,
        "broonie@kernel.org" <broonie@kernel.org>,
        "ckeepax@opensource.wolfsonmicro.com" 
	<ckeepax@opensource.wolfsonmicro.com>,
        "patches@opensource.wolfsonmicro.com" 
	<patches@opensource.wolfsonmicro.com>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "device-mainlining@lists.linuxfoundation.org" 
	<device-mainlining@lists.linuxfoundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v10 1/4] gadget: Introduce the usb charger framework
Thread-Topic: [PATCH v10 1/4] gadget: Introduce the usb charger framework
Thread-Index: AQHRkMPGtHshVOWiT0CKGo87VBT6+J9/ZtSAgABxaYCAAAFrAIAAEIWAgAAAPzCAAA3xAIAAMU2g
Date: Mon, 11 Apr 2016 01:38:39 +0000
Message-ID: <AM4PR04MB2130B1F3D1C9B4DE5CD6B92989940@AM4PR04MB2130.eurprd04.prod.outlook.com>
References: <cover.1460029375.git.baolin.wang@linaro.org>
	<6b323d5168c10ccb47882687b1251c31b6cad587.1460029375.git.baolin.wang@linaro.org>
	<AM4PR04MB2130F2C3DA7EA7140578A46289910@AM4PR04MB2130.eurprd04.prod.outlook.com>
	<CAMz4ku+kriz1biMx6dK3fWfDymJ12FXe+p_Fx+mvLJVQiMz7_g@mail.gmail.com>
	<AM4PR04MB21300E3BA9D6DAC2836C9BE689910@AM4PR04MB2130.eurprd04.prod.outlook.com>
	<CAMz4kuJvCSHpDtRqsO9OcPHbmwH_2iABfeshbs-94aUEo3sKXg@mail.gmail.com>
	<AM4PR04MB2130BB1F1E1FEA35B86DAE7B89910@AM4PR04MB2130.eurprd04.prod.outlook.com>
 <CAMz4kuJVtfxyXuSeq9kEZF-fhvcK9hYhNoj9g-vBD9GF5XVRgA@mail.gmail.com>
In-Reply-To: <CAMz4kuJVtfxyXuSeq9kEZF-fhvcK9hYhNoj9g-vBD9GF5XVRgA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2016 01:38:39.9722
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR04MB2130
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u3B1cwE1030567
Content-Length: 5542
Lines: 141

Hi

> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Friday, April 08, 2016 7:51 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: balbi@kernel.org; gregkh@linuxfoundation.org; sre@kernel.org;
> dbaryshkov@gmail.com; dwmw2@infradead.org; peter.chen@freescale.com;
> stern@rowland.harvard.edu; r.baldyga@samsung.com;
> yoshihiro.shimoda.uh@renesas.com; lee.jones@linaro.org; broonie@kernel.org;
> ckeepax@opensource.wolfsonmicro.com; patches@opensource.wolfsonmicro.com;
> linux-pm@vger.kernel.org; linux-usb@vger.kernel.org; device-
> mainlining@lists.linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework
> 
> On 8 April 2016 at 19:27, Jun Li <jun.li@nxp.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> >> Sent: Friday, April 08, 2016 7:00 PM
> >> To: Jun Li <jun.li@nxp.com>
> >> Cc: balbi@kernel.org; gregkh@linuxfoundation.org; sre@kernel.org;
> >> dbaryshkov@gmail.com; dwmw2@infradead.org; peter.chen@freescale.com;
> >> stern@rowland.harvard.edu; r.baldyga@samsung.com;
> >> yoshihiro.shimoda.uh@renesas.com; lee.jones@linaro.org;
> >> broonie@kernel.org; ckeepax@opensource.wolfsonmicro.com;
> >> patches@opensource.wolfsonmicro.com;
> >> linux-pm@vger.kernel.org; linux-usb@vger.kernel.org; device-
> >> mainlining@lists.linuxfoundation.org; linux-kernel@vger.kernel.org
> >> Subject: Re: [PATCH v10 1/4] gadget: Introduce the usb charger
> >> framework
> >>
> >> Hi Jun,
> >>
> >> >> >> +/*
> >> >> >> + * usb_charger_detect_type() - detect the charger type manually.
> >> >> >> + * @uchger - usb charger device
> >> >> >> + *
> >> >> >> + * Note: You should ensure you need to detect the charger type
> >> >> >> +manually on your
> >> >> >> + * platform.
> >> >> >> + * You should call it at the right gadget state to avoid
> >> >> >> +affecting gadget
> >> >> >> + * enumeration.
> >> >> >> + */
> >> >> >> +int usb_charger_detect_type(struct usb_charger *uchger) {
> >> >> >> +     enum usb_charger_type type;
> >> >> >> +
> >> >> >> +     if (WARN(!uchger->charger_detect,
> >> >> >> +              "charger detection method should not be NULL"))
> >> >> >> +             return -EINVAL;
> >> >> >> +
> >> >> >> +     type = uchger->charger_detect(uchger);
> >> >> >> +
> >> >> >> +     mutex_lock(&uchger->lock);
> >> >> >> +     uchger->type = type;
> >> >> >> +     mutex_unlock(&uchger->lock);
> >> >> >> +
> >> >> >> +     return 0;
> >> >> >> +}
> >> >> >> +EXPORT_SYMBOL_GPL(usb_charger_detect_type);
> >> >> >
> >> >> > I still recommend have a central place to call
> >> >> > usb_charger_detect_type() to cover real charger detection
> >> >> > instead of leaving this question open to diff users. This can be
> >> >> > done after vbus-on is detected and before do gadget connect. I
> >> >> > don't think this
> >> >> will make your framework complicated.
> >> >>
> >> >> This API is used for detecting the charger type manually (software
> >> >> charger detection), so if user's udc driver is needed to do this,
> >> >> then they can issue it at their right place to make it more flexible.
> >> >> But let us see other people's suggestion. Thanks.
> >> >
> >> > Ok, actually this API can be used for what ever charger detection
> >> > type, user can implement any method(manual detection, directly read
> >> > result from some HW...what ever) in uchger->charger_detect(),
> >> > target is
> >>
> >> But reading result from some HW dose not means *detect*, actually is
> *get*.
> >> We can not mix them together with the different semantics.
> >
> > It doesn’t matter here, you already define the _get_ API for just read
> > the charger type from the saved value(uchger->type), so we can think
> > the API to make uchger->type from UNKNOW to ONE KNOWN type is
> > *detect*, because we don't need 2 separate API one for *get* type from
> > HW and another one for *detect* from HW, only one API involve HW access
> is enough.
> 
> But another issue is some users may need to get the charger type from
> power supply by "power_supply_get_property()" function, we need to
> integrate with the power supply things in the usb charger framework, not
> user to implement that.

Why this user(your case) can't put the charger type get by
"power_supply_get_property()" in its uchger->charger_detect(),
any special reason prevent you doing it? I am not sure if this
case is very common, even if it is, you also can put it in
usb_charger_detect_type()

usb_charger_detect_type()
{
	If can get from power_supply_get_property()
		...
	else if uchger->charger_detect
		uchger->charger_detect();
	...
}

I don't know if most design of usb charger detection now days
is as easy as your PMIC for software(HW does the whole detection
process and prevent the vbus generation until detection has completed),
anyway if your framework can guarantee the detection process finished
before gadget connect, then each user don't have to worry about the
HW detection process details and seek a proper place to do it.
 
Li Jun
> 
> >
> > - Detect: (write to and) read from HW to get the charger type,
> >   save to uchger->type;
> > - Get: read the charger type from uchger->type.
> >
> >>
> >> > to have the charger type and set uchger->type, then you no need to
> >> > add the comments/description to limit it usage. Also I do see there
> >> > is
> >> possible central place to do this.
> >> >
> >>
> >> --
> >> Baolin.wang
> >> Best Regards
> 
> 
> 
> --
> Baolin.wang
> Best Regards