* NeilBrown n...@brown.name [150729 17:28]:
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
static int twl4030_charger_update_current(struct twl4030_bci *bci)
{
int status;
+ int cur;
unsigned reg, cur_reg;
u8 bcictl1, oldreg, fullreg;
* NeilBrown n...@brown.name [150806 20:48]:
Thanks, I did get notified about that by Fengguang's test robot, but
it's still on my list
I guess making CHARGER_TWL4030 auto-select TWL4030_MADC would not be
acceptable? That would pull in IIO (it didn't use to...).
If this OK?
Looks
On Fri, 7 Aug 2015 07:13:09 +0200 Sebastian Reichel s...@kernel.org
wrote:
Hi,
This actually slipped through my review. IMHO madc should be
accessed through IIO, as already done for twl4030-madc-battery
and rx51-battery. That way the custom API can be removed at
some point.
Anyway, I
On Thu, 6 Aug 2015 20:11:16 -0700 Tony Lindgren t...@atomide.com
wrote:
* NeilBrown n...@brown.name [150729 17:28]:
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
static int twl4030_charger_update_current(struct twl4030_bci *bci)
{
int status;
+
Hi,
This actually slipped through my review. IMHO madc should be
accessed through IIO, as already done for twl4030-madc-battery
and rx51-battery. That way the custom API can be removed at
some point.
Anyway, I queued the below patch with Tony's ACK to fix the build
issue in next.
On Fri, Aug
The twl4030 charger has two current sources, 'USB' and 'AC'
(presumably Accessory Charger because it isn't Alternating Current).
If 'AC' is providing current, we should set the current limit
differently to when it isn't (and so USB is used).
So split 'cur' into 'usb_cur' and 'ac_cur' and use
