Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp3071837img; Mon, 25 Mar 2019 03:13:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqxU2mpnNcl3QvH0RqMVIkMxlTGvtD1IevQRPKi0AlJT/kWqVplsOykAVdGEAU12XFQ6kmGr X-Received: by 2002:a63:c84c:: with SMTP id l12mr22518721pgi.287.1553508796894; Mon, 25 Mar 2019 03:13:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553508796; cv=none; d=google.com; s=arc-20160816; b=m8WSNYi+WT7BnIQKJg+hxDw5k6IypOT2UjC88sEEMwleBfMC/2rzTbnerTycW41Fj5 dj6JAwjp/5VnKbHrnss66T2pw1uzgAxbi6vuTEa9v2cTTzxKnrmKbDoAMMKmuwsx8Dur vt3mtKIE+l2X5wUUMWrSDZnyX79CEJay2+zescLp3vNSxGoupIxvTcTpFPFx/HO/l4GX pFJLOFHrei2ZLRpjCVf7LQlfstj/JDqqPRv6mg1ctfY4JcvEWH2PVsB7DWdKBjXbb7YU zsV9e8rXlZvtjRGgiq5gCE8nJDb20EvtKWnJRGFPz70J91b+l/db4FVhngNDR8gTNd3t yCXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=yl8AeyEc+3dizoPrLibP0sCwDZGzJ2uIaMKkz+mrL/c=; b=hWO6TAaEw+y+fNYq+/VV2vBblyDYa6BOzr+NQ6Oq8tQ3TXCcWK//lGl1WhYMROvtoy bwxJLSySB222kUvilWeZ5hctmCy0pzCYiaU893mdqRdCJKpEtfSH2ZEjVRtTKd8nR5++ lArRn2c4t+H1s2Cr7my+N/8aucO/Pxh8AF9FQO4iHUlC7xiQNTTMDC4NsVyDpUZpYUPO MP2jDuh8w3Dk7t9HQCmWUrAzSrp2/TdZGHLT+e6AWtCZ3S3LEkjuJXJ4av/IW22dmhtl SNjBk2vsvDqJ7V4lxsVYE7iX+R1cuyqkG0QIOzRLEDk4ARqxBZc2Ws5HSYBZk5RkjuUi B1PA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=EbFm6fUp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c142si381601pfb.32.2019.03.25.03.13.01; Mon, 25 Mar 2019 03:13:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=EbFm6fUp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730584AbfCYKMZ (ORCPT + 99 others); Mon, 25 Mar 2019 06:12:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:48438 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730456AbfCYKMZ (ORCPT ); Mon, 25 Mar 2019 06:12:25 -0400 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3B68A208E4; Mon, 25 Mar 2019 10:12:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553508743; bh=0dcTvGmvdH8hkzdvGKePclLuSk+RLnqL0pIjWo67ZE8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EbFm6fUp+EcFnc93Fp3Azv8GQhMNv2tbiaLTkt4rV7cp06ExWQN3+qTSmkriA4SdO hO2NWo5CRhX99xdcAsows3D3pHqNZezKvjY5rlraZskc6KZgL2ZpSDiGSL4NvF4eZy 7arN8HOcJ3P+0AJwH2c4J1GTOgEKV72zOMm/2coQ= Received: by mail-wr1-f42.google.com with SMTP id q1so9406717wrp.0; Mon, 25 Mar 2019 03:12:23 -0700 (PDT) X-Gm-Message-State: APjAAAXYUtjmgYmy7NWXiNy/IqpelOKUXM2AJ6ssjKtMgH9EiHgE3FFU lNfJ3pKbmW3mSKepk228zsU02hlJik/oqcWvdxU= X-Received: by 2002:a5d:458f:: with SMTP id p15mr15881410wrq.188.1553508741746; Mon, 25 Mar 2019 03:12:21 -0700 (PDT) MIME-Version: 1.0 References: <20190321084850.20769-1-wens@kernel.org> <20190321084850.20769-4-wens@kernel.org> <20190321093012.kg72voxs5kw5xtzu@flea> <3a896485-d7d4-e221-6e66-34bbdb0c0f6e@redhat.com> In-Reply-To: <3a896485-d7d4-e221-6e66-34bbdb0c0f6e@redhat.com> From: Chen-Yu Tsai Date: Mon, 25 Mar 2019 18:12:11 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [linux-sunxi] Re: [PATCH v3 3/9] power: supply: axp20x_usb_power: allow disabling input current limiting To: Hans de Goede Cc: Chen-Yu Tsai , Maxime Ripard , Lee Jones , Sebastian Reichel , devicetree , linux-arm-kernel , "open list:THERMAL" , linux-kernel , linux-sunxi Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 25, 2019 at 4:58 PM Hans de Goede wrote: > > Hi, > > On 25-03-19 03:45, Chen-Yu Tsai wrote: > > On Thu, Mar 21, 2019 at 5:30 PM Maxime Ripard wrote: > >> > >> Hi, > >> > >> The rest of the series is > >> Acked-by: Maxime Ripard > >> > >> On Thu, Mar 21, 2019 at 04:48:44PM +0800, Chen-Yu Tsai wrote: > >>> From: Chen-Yu Tsai > >>> > >>> The AXP PMICs allow the user to disable current limiting on the VBUS > >>> input. While read-out of this setting was already supported by the > >>> driver, it did not allow the user to configure the PMIC to disable > >>> current limiting. > >>> > >>> Add support for this. > >>> > >>> Signed-off-by: Chen-Yu Tsai > >> > >> Do we really want to do that though? That could have some pretty bad > >> consequences. > > > > If I understand the manual correctly, the PMIC has two mode of operation > > with regards to VBUS. Normal operation means the PMIC will try to limit > > the current draw to maintain VBUS above the set V_hold (defaults to 4.4V). > > This is in addition to the current limit set in this patch. > > > > The other mode of operation is bypass, where it ignores the voltage limit. > > Not sure if it also ignores the current limit, but probably not. In any > > case we don't support this mode in the driver. > > > > So I can think of a few cases where this might be bad: > > > > 1. High current draw results in excessive voltage drop and heating over > > line / traces due to insufficient conductor area. This should be covered > > by the voltage holding mechanism. > > > > 2. Over taxing the external power supply. This should also result in some > > voltage drop for simple power bricks. Advanced ones would either have > > current limiting or over-current protection. > > > > What bad consequences are you thinking of? > > Lets say you use a typical 5v / 2A charger-plug, lets also say that at full > load this brick has an efficiency of 90%. At full load it delivers 10W of > power, while consuming 11.1W dissipating 1.1W of losses as heat. > > Now lets say we disable current-limiting and rely only on the V_hold > mechanism, lets say that we end up with 4.5 volts at 2.4 amps because of > this and since we are now operating in overload conditions the > efficiency has fallen to 80% (approx. 4.5/5.0 * 90%) so now at full load > it delivers 10.8W of power, while consuming 13.5W dissipating 2.7W of > losses as heat. Chances are the the small plastic enclosure of your > typical charger-plug cannot dissipate this much and will start warming > up, until it bursts into flames. > > Disabling current limit protection is a very bad idea because you will > end up in an equilibrium between the Vhold from the charger-ic and the > over-current protection from the power-brick where you are over the > design limit of the power-brick. > > I actually like what the TI charger-ics are doing here a lot more then > what the AXP series is doing, with TI charger-ics if you set a current > limit > 500mA and the power-brick's voltages drops too much because of > this (or because of a bad cable) it automatically falls back to 500mA. > Where as at least with the AXP288, it simply starts drawing 1.5A at 4.5V > with a bad cable, but in this case the dissipation at least is happening > inside the cable rather then inside the charger-plug, which typically > already gets quite hot under normal operation conditions. > > Disabling the current limit is basically the same as what bad USB-A > to USB-C cables which have a Rp-3.0 resistor in the C plug do, these tell > the device with the Type-C plug it can safely draw 3A from the A-port the > A plug is plugged into. The web is full of stories about this causing > damage to machines, e.g.: > > "Bohn's Nexus 6P drew too much power from his MacBook Air while using a third-party cord, frying the machine and making the USB Type-C ports work only intermittently." > > From: https://www.laptopmag.com/articles/how-to-find-safe-usb-type-c-cables > > Another good link about the problems caused by these bad Rp resistor > values in Type-C to Type-A cables (which also effectively disable the > current-limit on the device charging on the C-end of the cable): > https://plus.google.com/102617628172847077584/posts/HakwCMmd346 > > Note this second link is going away in 6 days as google is retiring > google+. > > Anyways TL;DR: Disabling the current-limit is a bad idea and really > nothing good can come from this. OK. I'll respin the series without this. ChenYu