All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen-Yu Tsai <wens@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Chen-Yu Tsai <wens@kernel.org>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Lee Jones <lee.jones@linaro.org>,
	Sebastian Reichel <sre@kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"open list:THERMAL" <linux-pm@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-sunxi <linux-sunxi@googlegroups.com>
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

WARNING: multiple messages have this Message-ID
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: 42+ 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 ` Chen-Yu Tsai
2019-03-21  8:48 ` 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   ` 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   ` Chen-Yu Tsai
2019-03-21  8:48   ` 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  8:48   ` Chen-Yu Tsai
2019-03-21  9:30   ` Maxime Ripard
2019-03-21  9:30     ` Maxime Ripard
2019-03-21  9:30     ` Maxime Ripard
2019-03-25  2:45     ` [linux-sunxi] " Chen-Yu Tsai
2019-03-25  2:45       ` Chen-Yu Tsai
2019-03-25  2:45       ` Chen-Yu Tsai
2019-03-25  8:58       ` [linux-sunxi] " Hans de Goede
2019-03-25  8:58         ` Hans de Goede
2019-03-25  8:58         ` Hans de Goede
2019-03-25 10:12         ` Chen-Yu Tsai [this message]
2019-03-25 10:12           ` [linux-sunxi] " Chen-Yu Tsai
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   ` Chen-Yu Tsai
2019-03-21  8:48   ` 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   ` Chen-Yu Tsai
2019-03-21  8:48   ` 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   ` Chen-Yu Tsai
2019-03-21  8:48   ` 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-03-21  8:48   ` Chen-Yu Tsai
2019-03-21  8:48   ` Chen-Yu Tsai
2019-04-02  3:15   ` Lee Jones
2019-04-02  3:15     ` Lee Jones
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   ` Chen-Yu Tsai
2019-03-21  8:48   ` 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
2019-03-21  8:48   ` Chen-Yu Tsai
2019-03-21  8:48   ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.