Thread (40 messages) 40 messages, 6 authors, 2017-04-14

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help