Re: [PATCH v1 7/7] power: bq24190_charger: Set bq24190-battery device .type=unknown

Liam Breck
2017-03-23T08:55:15Z

On Thu, Mar 23, 2017 at 1:18 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 22-03-17 19:33, Liam Breck wrote:
>>
>> On Wed, Mar 22, 2017 at 7:41 AM, Hans de Goede <hdegoede@redhat.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> On 22-03-17 14:37, Liam Breck wrote:
>>>>
>>>>
>>>> On Wed, Mar 22, 2017 at 6:15 AM, Hans de Goede <hdegoede@redhat.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 22-03-17 13:25, Hans de Goede wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 21-03-17 23:09, Liam Breck wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Liam Breck <kernel@networkimprov.net>
>>>>>>>
>>>>>>> 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 <hdegoede@redhat.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>
>> 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.

>> 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!

>
>
>
>>
>>> 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