Re: [RESEND PATCH v3 2/5] charger: tps65090: Allow charger module to be used when no irq

[Olof Johansson]

On Tue, Apr 29, 2014 at 9:39 AM, Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> Anton,
>
> On Wed, Apr 23, 2014 at 8:56 AM, Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
>> 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.
>>
>> For proper functioning, requires (mfd: tps65090: Don't tell child
>> devices we have an IRQ if we don't).  If we don't have that patch
>> we'll simply fail to probe on devices without an interrupt (just like
>> we did before this patch).
>>
>> Signed-off-by: Doug Anderson <dianders@xxxxxxxxxxxx>
>> ---
>> Changes in v3: None
>> Changes in v2:
>> - Split noirq (polling mode) changes into MFD and charger
>>
>>  drivers/power/tps65090-charger.c | 76 +++++++++++++++++++++++++++++++---------
>>  1 file changed, 59 insertions(+), 17 deletions(-)
>
> All the rest of this series has been acked and applied.  Do you have
> time to review this patch?
>
> Thanks!  :)

FWIW, I've seen very little email traffic from Anton this year, he
might have limited time for maintainership at the moment. Usually what
we do in these cases is that we give the maintainer as much time as
possible, but eventually if there's no action, and the patches look
reasonable, we apply them with the maintainer on Cc: line in the
signed-offs. Or we send them to/through akpm, which tends to be the
catch-all for high-latency maintainers, etc.

Since this patch isn't holding anything up, let's give Anton as much
time as possible to review, and revisit in ~2 weeks (so it has time to
land somewhere in time for the merge window).


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/