From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752464AbcKGUx5 (ORCPT ); Mon, 7 Nov 2016 15:53:57 -0500 Received: from mx2.suse.de ([195.135.220.15]:32879 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750988AbcKGUxx (ORCPT ); Mon, 7 Nov 2016 15:53:53 -0500 From: NeilBrown To: Baolin Wang Date: Tue, 08 Nov 2016 07:36:32 +1100 Cc: Felipe Balbi , Greg KH , Sebastian Reichel , Dmitry Eremin-Solenikov , David Woodhouse , robh@kernel.org, Jun Li , Marek Szyprowski , Ruslan Bilovol , Peter Chen , Alan Stern , grygorii.strashko@ti.com, Yoshihiro Shimoda , Lee Jones , Mark Brown , John Stultz , Charles Keepax , patches@opensource.wolfsonmicro.com, Linux PM list , USB , device-mainlining@lists.linuxfoundation.org, LKML Subject: Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation In-Reply-To: References: <87k2cttptn.fsf@notabene.neil.brown.name> <87a8dls7yn.fsf@notabene.neil.brown.name> <871sytqrqh.fsf@notabene.neil.brown.name> User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-suse-linux-gnu) Message-ID: <87a8dbni27.fsf@notabene.neil.brown.name> 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 On Mon, Nov 07 2016, Baolin Wang wrote: > On 3 November 2016 at 09:25, NeilBrown wrote: >> On Tue, Nov 01 2016, Baolin Wang wrote: > > I agree with your most opinions, but these are optimization.=20 I see them as bug fixes, not optimizations. > Firstly I > think we should upstream the USB charger driver. I think you missed the point. The point is that we don't *need* your "USB charger driver" because all the infrastructure we need is *already* present in the kernel. It is buggy and not used uniformly, and could usefully be polished and improved. But the structure is already present. If everyone just added new infrastructure when they didn't like, or didn't understand, what was already present, the kernel would become like the Mad Hatter's tea party, full of dirty dishes. > What I want to ask is > how can we notify power driver if we don't set the > usb_register_notifier(), then I think you give the answer is: power > driver can register by 'struct usb_phy->notifier'. But why usb phy > should notify the power driver how much current should be drawn, and I > still think we should notify the current in usb charger driver which > is better, and do not need to notify current for power driver in usb > phy driver. I accept that it isn't clear that the phy *should* be involved in communicating the negotiated power availability, but nor is it clear that it shouldn't. The power does travel through the physical interface, so physically it plays a role. But more importantly, it already *does* get told (in some cases). There is an interface "usb_phy_set_power()" which exists explicitly to tell the phy what power has been negotiated. Given that infrastructure exists and works, it make sense to use it. If you think it is a broken design and should be removed, then fine: make a case for that. Examine the history. Make sure you know why it is there (or make sure that information cannot be found), and then present a case as to why it should be removed and replaced with something else. But don't just leave it there and pretend it doesn't exist and create something similar-but-different and hope people will know why yours is better. That way lies madness. NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYIOXQAAoJEDnsnt1WYoG5OrkQAIydklU1Kr3SX42iw75868+X tMZLTDzWZ8mU9uXpkmSv6HZxYmb/2SXv0i4/Z8ugOerT5VP1Wv97L+gg44XZCD0d 9B7dXLVdOS7O34XWQOcyiBY4rqj42Ljk1gWMp0QXhvxhYZk/YUmMwoWfRnZH1HuC Itre2Sci1SNMWY8lXlWTykbTl67KmLuQChHG4EUUem9pcy0SfFwywNJ0UaQLk10S Q+MFj0zSD2Hdqbwsx6NAtSEYUXt0Y825LxY2vKEVAScVUkcZEPtMSOWTAPVm5fRc vOVlt49Ut+aHwCUHkbw5qYqteexAOb2oVrDXOmdWdVVUqZBrX5RAwv4IGoRr/r+W DXZnuJRmGS9ofEc0+v38wCbNV4x4U/OYAm11165zzYsuVeC+vAO4/J3W74K2g8pN XFCqChsneIm70Bbi3d2Ei+zedomfkRdUv1Eh/TzJlPrgpPf9ZlphR2HZ1KTdqkG2 pHXBNWek7mTja6nZ4/WR5D9m8zo+OxjfuM589dEi5bKhRPTB85VdB7G6EwvGv1qp k9Kj+rO2YRCV5qb3xwIci9DI70QX/9YdYTkURzW5ImSRyci2cK/rWu7Igq7oQeKB O33ncngAQXoi29iuBgmUvUHrmQ2uvzuQaZynp/VFmKVngJ7kunJZqh0lOYFti/bx JOlCS08Q/g46rbpn4/Kl =Q+aq -----END PGP SIGNATURE----- --=-=-=--