From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751999AbcF2IfH (ORCPT ); Wed, 29 Jun 2016 04:35:07 -0400 Received: from mga03.intel.com ([134.134.136.65]:51315 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751308AbcF2IfE (ORCPT ); Wed, 29 Jun 2016 04:35:04 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,545,1459839600"; d="asc'?scan'208";a="1011853227" From: Felipe Balbi To: Baolin Wang Cc: Greg KH , Sebastian Reichel , Dmitry Eremin-Solenikov , David Woodhouse , robh@kernel.org, Jun Li , Marek Szyprowski , Ruslan Bilovol , Peter Chen , Alan Stern , r.baldyga@samsung.com, grygorii.strashko@ti.com, Yoshihiro Shimoda , Lee Jones , Mark Brown , Charles Keepax , patches@opensource.wolfsonmicro.com, Linux PM list , USB , device-mainlining@lists.linuxfoundation.org, LKML Subject: Re: [PATCH v12 2/4] gadget: Support for the usb charger framework In-Reply-To: References: <87bn2uomzd.fsf@linux.intel.com> <87eg7giexn.fsf@linux.intel.com> User-Agent: Notmuch/0.22+51~gcc1a6d2 (http://notmuchmail.org) Emacs/25.0.93.2 (x86_64-pc-linux-gnu) Date: Wed, 29 Jun 2016 11:34:21 +0300 Message-ID: <87bn2kieb6.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Baolin Wang writes: >>>>> For supporting the usb charger, it adds the usb_charger_init() and >>>>> usb_charger_exit() functions for usb charger initialization and exit. >>>>> >>>>> It will report to the usb charger when the gadget state is changed, >>>>> then the usb charger can do the power things. >>>>> >>>>> Signed-off-by: Baolin Wang >>>>> Reviewed-by: Li Jun >>>>> Tested-by: Li Jun >>>> >>>> Before anything, I must say that I really liked this patch. It's >>>> minimaly invasive to udc core and does all the necessary changes. If it >>>> wasn't for the extra charger class, this would've been perfect. >>>> >>>> Can't you just tie a charger to a UDC and avoid the charger class >>>> completely? >>>> >>>>> static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, un= signed mA) >>>>> { >>>>> + if (gadget->charger) >>>> >>>> I guess you could do this check inside >>>> usb_gadget_set_cur_limit_by_type() itself. >>> >>> We will access the 'gadget->charger->type' member when issuing >>> usb_gadget_set_cur_limit_by_type(), so I think I should leave the >>> check here in next new version. >> >> Here's what I mean: >> >> int usb_charger_set_cur_limit(struct usb_gadget *gadget, unsigned int mA) >> { >> struct usb_charger *charger; >> enum usb_charger_type type; >> >> if (!gadget->charger) >> return 0; >> >> charger =3D gadget->charger; >> type =3D charger->type; >> >> return __usb_charger_set_cur_limit(charger, type, mA); >> } > > But that means we need to export both 'usb_charger_set_cur_limit()' > function and '__usb_charger_set_cur_limit()' function in charger.c > file. Cause some user may want to set the current limitation by one > charger type parameter (may be not from charger->type), like by > issuing '__usb_charger_set_cur_limit(charger, SDP_TYPE, mA)'. How do > you think about this situation? Thanks. if we have that requirement, that's totally fine. Just rename __usb_charger_set_cur_limit() back to _usb_charger_set_cur_limit_by_type() and expose both. But set_cur_limit_by_type can assume its arguments are valid at all times. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXc4gNAAoJEIaOsuA1yqREYnAP/1v68H2jDlpR3jC0u7IJmLyy 2VYPI+6UOTWqb6VuwApXbH2knTMQmD2Oi0QzQS0FNvtCzyuG+bhGs4ACgMFxEfAn GXGDHJxLHv/1nbxPEYnB+Tqt/R29IzRombCis5cQbcjveCASVcvYz+EmFaSpJMCm TucZIuMBe5i3cF+8H6xeTSng07vkvXwI5gJqRuTGoISWKBqE11hT/zxYV61pZbIO dc+Q3vrOOol1pw75XGia8GL5DMKlHDdixTHtMWIjfKLn+JQ/bmpS2/lTncJ65Ct+ fYV+2AHI42N/kmXm8dZBbaqqDj+nqYLb1vARpZcKadMdNBE6tuDjbks4PNlnzT8g Uiry1QpKdddWb0bQW/mPu7g+Mz+GOTCckfhAByHJkDVFkYYCCMnD2cMZMEU8xd9p lFWKGhtparZX6poMqSPA0nqB1MR8B0zx0jeibOUct4XPOeCYTmCfcmFPdotfJRS2 XKC0pCA6BkFyidccmPPRQ9LM6bNGbXPy3fpWnrwc+WKJmL/doobQO1K8BVJ5Nh0p tFgrDrAV6uzyp8oLMwsdv9ga+geIwl8veuHCsWytbrvcHrEZKcJWyuEx2AgIp7ez CbQpcjy0Ua5mnJnHtdYecE2ozzj9W1plZ1YvtF3ijmtGFfumtMyZw63IgMJSPFx3 86PAB8//p8gWdMwiAj0M =rg/M -----END PGP SIGNATURE----- --=-=-=--