linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Chen-Yu Tsai <wens@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: devicetree <devicetree@vger.kernel.org>,
	"open list:THERMAL" <linux-pm@vger.kernel.org>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Sebastian Reichel <sre@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-sunxi <linux-sunxi@googlegroups.com>,
	Chen-Yu Tsai <wens@kernel.org>, Lee Jones <lee.jones@linaro.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [linux-sunxi] Re: [PATCH v3 3/9] power: supply: axp20x_usb_power: allow disabling input current limiting
Date: Mon, 25 Mar 2019 18:12:11 +0800	[thread overview]
Message-ID: <CAGb2v66128Z=K1NHRqFBNA5RewvWRYZxhXpZgmysZTzrme6DVA@mail.gmail.com> (raw)
In-Reply-To: <3a896485-d7d4-e221-6e66-34bbdb0c0f6e@redhat.com>

On Mon, Mar 25, 2019 at 4:58 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 25-03-19 03:45, Chen-Yu Tsai wrote:
> > On Thu, Mar 21, 2019 at 5:30 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >>
> >> Hi,
> >>
> >> The rest of the series is
> >> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
> >>
> >> On Thu, Mar 21, 2019 at 04:48:44PM +0800, Chen-Yu Tsai wrote:
> >>> From: Chen-Yu Tsai <wens@csie.org>
> >>>
> >>> 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 <wens@csie.org>
> >>
> >> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-25 10:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-21  8:48 [PATCH v3 0/9] ARM: sun8i: a83t: Enable USB OTG Chen-Yu Tsai
2019-03-21  8:48 ` [PATCH v3 1/9] dt-bindings: power: supply: axp20x_usb_power: add axp813 compatible Chen-Yu Tsai
2019-03-21  8:48 ` [PATCH v3 2/9] power: supply: axp20x_usb_power: Fix typo in VBUS current limit macros Chen-Yu Tsai
2019-03-21  8:48 ` [PATCH v3 3/9] power: supply: axp20x_usb_power: allow disabling input current limiting Chen-Yu Tsai
2019-03-21  9:30   ` Maxime Ripard
2019-03-25  2:45     ` [linux-sunxi] " Chen-Yu Tsai
2019-03-25  8:58       ` Hans de Goede
2019-03-25 10:12         ` Chen-Yu Tsai [this message]
2019-03-21  8:48 ` [PATCH v3 4/9] power: supply: axp20x_usb_power: use polling to detect vbus status change Chen-Yu Tsai
2019-03-21  8:48 ` [PATCH v3 5/9] power: supply: axp20x_usb_power: add function to get max current Chen-Yu Tsai
2019-03-21  8:48 ` [PATCH v3 6/9] power: supply: axp20x_usb_power: add support for AXP813 Chen-Yu Tsai
2019-03-21  8:48 ` [PATCH v3 7/9] mfd: axp20x: add USB power supply mfd cell to AXP813 Chen-Yu Tsai
2019-04-02  3:15   ` Lee Jones
2019-03-21  8:48 ` [PATCH v3 8/9] ARM: dtsi: axp81x: add USB power supply node Chen-Yu Tsai
2019-03-21  8:48 ` [PATCH v3 9/9] ARM: dts: sun8i: a83t: Enable USB OTG controller on some boards Chen-Yu Tsai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGb2v66128Z=K1NHRqFBNA5RewvWRYZxhXpZgmysZTzrme6DVA@mail.gmail.com' \
    --to=wens@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=sre@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).