Re: [PATCH v1 7/7] power: bq24190_charger: Set bq24190-battery device .type=unknown
From: Liam Breck <hidden>
Date: 2017-03-23 08:55:15
On Thu, Mar 23, 2017 at 1:18 AM, Hans de Goede [off-list ref] wrote:
Hi, On 22-03-17 19:33, Liam Breck wrote:quoted
On Wed, Mar 22, 2017 at 7:41 AM, Hans de Goede [off-list ref] wrote:quoted
Hi, On 22-03-17 14:37, Liam Breck wrote:quoted
On Wed, Mar 22, 2017 at 6:15 AM, Hans de Goede [off-list ref] wrote:quoted
Hi, On 22-03-17 13:25, Hans de Goede wrote:quoted
Hi, On 21-03-17 23:09, Liam Breck wrote:quoted
From: Liam Breck <redacted> Not for upstream. Temporary workaround to prevent bq24190-battery device from interfering with a fuel gauge that has .type=power_supply_type_battery I'll move properties from -battery device to -charger in a subsequent version. Cc: Hans de Goede <redacted>Hmm, I don't like this. I was about to post v2 of my patches (which I will rebase on top of this series)It seems this series does not apply to: https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git/log/?h=for-next It looks like there is another series which sits in between ?Yes, see two patches linked in Depends-on lines. Could you add those and rebase?I can confirm that with those 2 patches thrown in things apply cleanly on linux-power-supply/for-next. I see that these 2 patches add a new devicetree binding for describing a battery. That is really cool stuff and long overdue IMHO I'm glad to see someone doing this. But (sorry) in my experience getting new devicetree bindings upstream often takes a while, while people are discussing the best way to solve things. So I'm not quite sure this will go upstream real soon now and I would like to get my patches into -next in time for 4.12 if possible.Sebastian asked us to write those two patches, and has acked one, I expect ack on the docs for this version (the DT api is settled). The only thing holding up that patchset is a test pass by the TI maintainer of bq27xxx_battery. But we can separate the power_supply_core changes from that if nec.Ok, lets let Sebastian decide on the order in which to merge these.quoted
I would like to run your patches in my environment for some time before acking. For that, I need the -battery back! And also this patchset.If Sebastian decides he wants to wait with merging these till your patches are merged then I'll rebase, otherwise you need to rebase anyways and can do so for your testing.
I'm grateful for your patches, and I do need to test your code before it's merged. Pls do what you can to make that straightforward. If there's a reason to expedite your patchset, do let me know. To clarify my role, I hired Mark to write this driver from scratch four years ago, and since then have hired Tony periodically to test/fix it. I've also invested a significant cash and man-years on the hw design that has this chip. After looking at this code and the docs over all this time, I realized I could be improving it myself, hence the recent commits. If I had a spare board to send to facilitate your efforts, I would, but the yield on last prototype run was abysmal. Later this year I can get you one.
quoted
How's progress on the pmic-gauge battery driver? I'd be curious to see it since I've been adding features to the bq27xxx driver lately.Progress is good I hope to post a v2 today, in the mean time you can find it here: https://github.com/jwrdegoede/linux-sunxi/commit/7b667e5068393afc29c7173c9f4eae46b026a849
Nice!
quoted
quoted
So for now I'm going to hold of on rebasing and just send v2 as is (based on linux-power-supply/for-next). If Sebastian thinks your patches should go first I will happily do a rebased v3. Regards, Hans