From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752019AbcFUMsp (ORCPT ); Tue, 21 Jun 2016 08:48:45 -0400 Received: from mga03.intel.com ([134.134.136.65]:1850 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751432AbcFUMsn (ORCPT ); Tue, 21 Jun 2016 08:48:43 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,504,1459839600"; d="asc'?scan'208";a="722813728" 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> <87twgmn4m7.fsf@linux.intel.com> <87inx2n2vs.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: Tue, 21 Jun 2016 15:36:54 +0300 Message-ID: <87d1nan2ft.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: >> Baolin Wang writes: >>>> Baolin Wang writes: >>>>>> Can't you just tie a charger to a UDC and avoid the charger class >>>>>> completely? >>>>> >>>>> Yeah, I also hope so. But we really want something to manage the >>>>> charger devices, do you have any good suggestion to avoid the 'class' >>>>> but also can manage the charger devices? >>>> >>>> manage in what way? It seems to me that they don't need to be real >>>> devices, just a handle as part of struct usb_gadget, no? >>> >>> Although charger device is not one real hardware device, we also use >>> one 'struct device' to describe it in charger.c file. So we should >>> manage the 'struct device' with one proper way. >> >> that's fine, but why do you think they need a struct device to start wit= h? > > We can get/put usb charger and mange usb charger attributes with the > device model if we use a struct device. We already have that as part of struct usb_udc. Why don't you just create a subdirectory called charger which will hold all your charger-related attributes. That directory will only be created if a valid ->charger pointer exists. USB Charging is always tied to a peripheral side controller, anyway. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXaTTmAAoJEIaOsuA1yqRE2goP/19Jcq8xiFQauQxQ2rygQOPu rc9Rcu0XG9b9XDkj7AB/0DIBK7m3la/ZxH3SsZALFGAFcAulK2Xs009ThPeo4CmF Wxa6iuUx0fYGNF/S6T+3OflFa0HCEEZO02CRmlzcBbV71vXwoeNCgMR4DrxnYasd +DFpxV3neZc+mdFNs489C9e1fCLKJdzc8ruty+UA3lcrELK3TIC3orXmYM2YvIUb zZUxeUOUomeRj7399fE8LHDwkwYvX1eYSQTiaXWh7oPZ5MHxg8ewXSTxNoYhvhqn C8DJiRqDbxsGS7de+c0YsHy3tnA35QmkBuO7p6ZQzVoSWyRXx1MRlXpHI67BuFNo jqVGpatW4nr9UQxRtqTnLutTX0hSmHnARTQFXA9v/qtLk+rLUdi1178uA/gY+H5R xgV8SzOMEuBDarsqjSCGCp2RKjsx9GQe/cGlM1lRlFjB8Drmvhx9/cJlTsBwHFTt ShrZZz4s8W1PTM6rEfkCRB0RE8tbKYDWXx157aFYdrHUzVkyl611rCOmNd5kFA2R ce6vrS3zB6riGYNze/tpitHbYF4d47p55nmwZ2p/2RiV8//BkLt2nJ1B7MopgWww P2pZQ8s0iVj6qkxebWFT3WMZkWzeTEezfHDYC5QAJWV8Xsj6nwLwl748I5KzegOx YmcicTon6GNBCR7bVmv8 =deYk -----END PGP SIGNATURE----- --=-=-=--