linux-kernel - Re: [PATCH 1/3] mfd: tps65090: Allow charger module to be used when no irq

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:	Wed, 16 Apr 2014 17:26:21 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Anton Vorontsov <anton@...msg.org>,
	Olof Johansson <olof@...om.net>,
	Sachin Kamat <sachin.kamat@...aro.org>,
	AJAY KUMAR RAMAKRISHNA SHYMALAMMA <ajaykumar.rs@...sung.com>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] mfd: tps65090: Allow charger module to be used when
 no irq

> >> On the ARM Chromebook tps65090 has two masters: the AP (the main
> >> processor running linux) and the EC (the embedded controller).  The AP
> >> is allowed to mess with FETs but the EC is in charge of charge control.
> >>
> >> The tps65090 interupt line is routed to both the AP and the EC, which
> >> can cause quite a headache.  Having two people adjusting masks and
> >> acking interrupts is a recipe for disaster.
> >>
> >> In the shipping kernel we had a hack to have the AP pay attention to
> >> the IRQ but not to ack it.  It also wasn't supposed to configure the
> >> IRQ in any way.  That hack allowed us to detect when the device was
> >> charging without messing with the EC's state.
> >>
> >> The current tps65090 infrastructure makes the above difficult, and it
> >> was a bit of a hack to begin with.  Rather than uglify the driver to
> >> support it, just extend the driver's existing notion of "no irq" to
> >> the charger.  This makes the charger code poll every 2 seconds for AC
> >> detect, which is sufficient.
> >>
> >> Signed-off-by: Doug Anderson <dianders@...omium.org>
> >> ---
> >>  drivers/mfd/tps65090.c           | 14 ++++++--
> >>  drivers/power/tps65090-charger.c | 76 +++++++++++++++++++++++++++++++---------
> >>  2 files changed, 70 insertions(+), 20 deletions(-)
> >
> > For the MFD part:
> >   Acked-by: Lee Jones <lee.jones@...aro.org>
> >
> > Anton,
> >   If you are okay with this patch I'd be happy to create an immutable
> > branch for you to pull from?
> >
> > Doug,
> >   What is the relationship (dependencies) between this and the other
> > patches in the set?
> 
> This patch can be applied irrespective of other others in the series.

What about the files in the patch? Could you make two separate patches
from this one patch and it would still compile okay? I'm _guessing_
the answer is yes?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/