linux-kernel - Re: [PATCH 2/4] ARM: tegra: nyan: Use external control for bq24735 charger

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 20 Sep 2016 20:02:47 +0200
From:   Paul Kocialkowski <contact@...lk.fr>
To:     Jon Hunter <jonathanh@...dia.com>, linux-kernel@...r.kernel.org
Cc:     devicetree@...r.kernel.org, Stephen Warren <swarren@...dotorg.org>,
        Thierry Reding <thierry.reding@...il.com>,
        linux-tegra@...r.kernel.org, Alexandre Courbot <gnurou@...il.com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/4] ARM: tegra: nyan: Use external control for bq24735
 charger

Le mardi 20 septembre 2016 à 18:40 +0100, Jon Hunter a écrit :
> On 28/08/16 18:32, Paul Kocialkowski wrote:
> > 
> > Nyan boards come with an embedded controller that controls when to
> > enable and disable the charge. Thus, it should not be left up to the
> > kernel to handle that.
> > 
> > Using the ti,external-control property allows specifying this use-case.
> 
> So the bq24735 is populated under the EC's 'i2c-tunnel' property which
> is there to specifically interface it's child devices to the host. So I
> am a bit confused why this is expose to the host if it should not be used?

Well, it needs to access the information in the read-only registers provided by
the chip, which is allowed by the setup in place that you described.

However, the EC has its internal state machine that decides when to start
charging, etc and so should be the only one to write registers, to avoid
conflicts.

> Again you may right and I did find the original series [0] for this
> which specifically references the Acer Chromebook that needs this.
> However, I am not sure why this was never populated? Is there any other
> history here?

I am also confused about why it wasn't applied earlier. However, the cros kernel
is using the very same scheme.

> What is the actual problem you see without making this change?

There is a risk of conflict (even though it's probably not that significant),
given the low variety of possible cases here. The idea is simply to say that the
EC is in charge and to let it do its job without interfering.

> The original series states ...
> 
> "On Acer Chromebook 13 (CB5-311) this module fails to load if the
> charger is not inserted, and will error when it is removed."

I'm confused about that comment. At this point (and with this patch), it works
normally.

> Cheers
> Jon
> 
> [0] http://marc.info/?l=linux-pm&m=145447948705686&w=2

Cheers,

-- 
Paul Kocialkowski, developer of low-level free software for embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)