From: Jun Li <jun.li@nxp.com>
To: Felipe Balbi <balbi@kernel.org>, Baolin Wang <baolin.wang@linaro.org>,
        Peter Chen <hzpeterchen@gmail.com>
CC: Greg KH <gregkh@linuxfoundation.org>, Sebastian Reichel <sre@kernel.org>,
        Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Peter Chen <peter.chen@freescale.com>,
        Alan Stern <stern@rowland.harvard.edu>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
        Lee Jones <lee.jones@linaro.org>, "Mark Brown" <broonie@kernel.org>,
        Charles Keepax <ckeepax@opensource.wolfsonmicro.com>,
        "patches@opensource.wolfsonmicro.com" 
	<patches@opensource.wolfsonmicro.com>,
        Linux PM list <linux-pm@vger.kernel.org>,
        USB <linux-usb@vger.kernel.org>,
        "device-mainlining@lists.linuxfoundation.org" 
	<device-mainlining@lists.linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v9 2/4] gadget: Support for the usb charger framework
Thread-Topic: [PATCH v9 2/4] gadget: Support for the usb charger framework
Thread-Index: AQHRi+evqEo8RiU/f0GkOiqzWpmAkZ98kaEAgAA5vgCAABNbsIAABzaAgAABvFCAAAfUgIAAAUlw
Date: Wed, 6 Apr 2016 13:49:04 +0000
Message-ID: <AM4PR04MB2130E03385128C1CD22553E7899F0@AM4PR04MB2130.eurprd04.prod.outlook.com>
References: <cover.1459494743.git.baolin.wang@linaro.org>
 <13c2f4fb71958bf9a5527acbed8b8b60dc569656.1459494744.git.baolin.wang@linaro.org>
 <20160406071956.GA21101@shlinux2.ap.freescale.net>
 <CAMz4kuJkf0Q1JKdc5W8EcDBvr6MccTcdZa-Pse_Z4pFwySTSDA@mail.gmail.com>
 <AM4PR04MB2130F58AA1018FFD367C89E0899F0@AM4PR04MB2130.eurprd04.prod.outlook.com>
 <871t6j2ai2.fsf@intel.com>
 <AM4PR04MB213054CF3F597CE2E6FE976F899F0@AM4PR04MB2130.eurprd04.prod.outlook.com>
 <87oa9m28x0.fsf@intel.com>
In-Reply-To: <87oa9m28x0.fsf@intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 13:49:04.1861
 (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-Length: 3979
Lines: 101

Hi

> -----Original Message-----
> From: Felipe Balbi [mailto:balbi@kernel.org]
> Sent: Wednesday, April 06, 2016 8:56 PM
> To: Jun Li <jun.li@nxp.com>; Baolin Wang <baolin.wang@linaro.org>; Peter
> Chen <hzpeterchen@gmail.com>
> Cc: Greg KH <gregkh@linuxfoundation.org>; Sebastian Reichel
> <sre@kernel.org>; Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David
> Woodhouse <dwmw2@infradead.org>; Peter Chen <peter.chen@freescale.com>;
> Alan Stern <stern@rowland.harvard.edu>; r.baldyga@samsung.com; Yoshihiro
> Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Charles Keepax
> <ckeepax@opensource.wolfsonmicro.com>; patches@opensource.wolfsonmicro.com;
> Linux PM list <linux-pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>;
> device-mainlining@lists.linuxfoundation.org; LKML <linux-
> kernel@vger.kernel.org>
> Subject: RE: [PATCH v9 2/4] gadget: Support for the usb charger framework
> 
> 
> Hi,
> 
> Jun Li <jun.li@nxp.com> writes:
> >> >> On 6 April 2016 at 15:19, Peter Chen <hzpeterchen@gmail.com> wrote:
> >> >> > On Fri, Apr 01, 2016 at 03:21:50PM +0800, Baolin Wang wrote:
> >> >> >>
> >> >> >> @@ -563,6 +564,8 @@ struct usb_gadget_ops {
> >> >> >>       struct usb_ep *(*match_ep)(struct usb_gadget *,
> >> >> >>                       struct usb_endpoint_descriptor *,
> >> >> >>                       struct usb_ss_ep_comp_descriptor *);
> >> >> >> +     /* get the charger type */
> >> >> >> +     enum usb_charger_type (*get_charger_type)(struct
> >> >> >> + usb_gadget *);
> >> >> >>  };
> >> >> >
> >> >> > Since we already have get_charger_type callback at usb_charger
> >> >> > structure, why we still need this API at usb_gadget_ops?
> >> >>
> >> >> In case some users want to get charger type at gadget level.
> >> >>
> >> > Why gadget needs to know charger type? I also don't catch the
> >> > intent of
> >>
> >> because some gadgets need to call usb_gadget_vbus_draw(), although
> >> for that they need power in mA rather.
> >
> > In below change of usb_gadget_vbus_draw(), already can get charger
> > type via usb_charger_get_type().
> >
> > static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget,
> > unsigned mA)  {
> > +       enum usb_charger_type type;
> > +
> > +       if (gadget->charger) {
> > +               type = usb_charger_get_type(gadget->charger);
> > +               usb_charger_set_cur_limit_by_type(gadget->charger, type,
> mA);
> > +       }
> > +
> >         if (!gadget->ops->vbus_draw)
> >                 return -EOPNOTSUPP;
> >         return gadget->ops->vbus_draw(gadget, mA);
> >
> > Could you detail in what situation gadget->ops-> get_charger_type() is
> used?
> 
> isn't it right there in the code ? Isn't usb_gadget_vbus_draw() calling
> it ? What did I miss here ?

Well, that's true, so my real meaning is why gadget need get charger type
via another new api gadget->ops->get_charger_type().
 
> 
> >> > This api, as my understanding, gadget only need report gadget state
> >> changes.
> >> > All information required for usb charger is charger type and gadget
> >> state.
> >>
> >> you're making an assumption about how the HW is laid out which might
> >> not be true.
> >>
> >
> > What other information you refer to here? Or what I am not aware of?
> 
> what I'm trying to say is that you're assuming gadgets don't need to know
> anything other than charger type and gadget state (suspended, resume,
> enumerated, default state, addressed, etc), but that might not be true for
> all UDCs. You can't make that assumption that charger type and gadget
> state is enough. The real question is what do we need *now*, but still
> keep in mind that what we need *now* might be valid 2 years from now, so
> API needs to be a little flexible.

Get your point, flexible, I just thought create an api without any user
for existing case/spec, wouldn't it be better to let the real user add it
later when it's needed.

> 
> cheers
> 
> --
> balbi