linux-kernel - Re: [PATCH resend v2] power: supply: bq27xxx: enable writing capacity values for bq27421

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 9 Sep 2017 00:08:03 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Liam Breck <liam@...workimprov.net>
Cc:     Sebastian Reichel <sre@...nel.org>,
        Pali Rohár <pali.rohar@...il.com>,
        "Andrew F. Davis" <afd@...com>,
        Linux PM mailing list <linux-pm@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, kernel@...a-handheld.com
Subject: Re: [PATCH resend v2] power: supply: bq27xxx: enable writing capacity values for bq27421


> Am 08.09.2017 um 22:57 schrieb Liam Breck <liam@...workimprov.net>:
> 
> Howdy,
> 
> On Fri, Sep 8, 2017 at 1:28 PM, H. Nikolaus Schaller <hns@...delico.com> wrote:
>> Hi Liam,
>> 
>>> Am 08.09.2017 um 22:19 schrieb Liam Breck <liam@...workimprov.net>:
>>> 
>>> Hi Nikolaus,
>>> 
>>> On Fri, Sep 8, 2017 at 10:38 AM, H. Nikolaus Schaller <hns@...delico.com> wrote:
>>>> Hi Liam,
>>>> I finally continues testing on OpenPandora.
>>>> 
>>>>> Am 31.08.2017 um 22:19 schrieb Liam Breck <liam@...workimprov.net>:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> This may be a fix that allows >0 input from DT, but won't try to
>>>>> program the register since the first 3 fields aren't compatible:
>>>>> 
>>>>> ... bq27500_dm_regs[] = {
>>>>> ...
>>>>> [bq27xxx_dm_design_energy] = {  0,  0, 0,    0, 65535 }, /* missing on chip */
>>>>> NB: align columns with other rows
>>>> 
>>>> I have tried with this DT
>>>> 
>>>>       bat: battery {
>>>>               compatible = "simple-battery", "openpandora-battery";
>>>>               voltage-min-design-microvolt = <3250000>;
>>>>               energy-full-design-microwatt-hours = <14800000>;
>>>>               charge-full-design-microamp-hours = <4100000>;
>>>>       };
>>>> 
>>>> and here is the result:
>>>> 
>>>>> root@...ux:~# dmesg|fgrep bq27
>>>>> [   10.391235] bq27xxx_battery_setup
>>>>> [   10.391265] bq27xxx_battery_setup: dm_regs=bf0520e0
>>>>> [   10.393798] (NULL device *): hwmon: 'bq27500-1-0' is not a valid name attribute, please fix
>>>>> [   10.432678] bq27xxx_battery_settings
>>>>> [   10.432952] bq27xxx_battery_set_config
>>>>> [   10.432952] bq27xxx_battery_unseal
>>>>> [   10.485168] bq27xxx_battery_update_dm_block
>>>>> [   10.485198] bq27xxx-battery 2-0055: update design-capacity to 4100
>>>> 
>>>> looks good
>>>> 
>>>>> [   10.485229] bq27xxx_battery_update_dm_block
>>>>> [   10.485229] bq27xxx-battery 2-0055: buffer does not match design-energy dm spec
>>>> 
>>>> ok, ignored
>>>> 
>>>>> [   10.511718] bq27xxx_battery_update_dm_block
>>>>> [   10.511749] bq27xxx-battery 2-0055: update terminate-voltage to 3250
>>>> 
>>>> looks good
>>>> 
>>>>> [   10.826446] bq27xxx_battery_seal
>>>>> [   12.150939] bq27xxx_battery_platform_probe
>>>>> [   12.151031] bq27xxx_battery_setup
>>>>> [   12.151062] bq27xxx_battery_setup: dm_regs=  (null)
>>>>> [   12.153411] (NULL device *): hwmon: 'bq27000-battery' is not a valid name attribute, please fix
>>>>> [   12.154327] bq27xxx_battery_settings
>>>>> [   12.154357] power_supply bq27000-battery: power_supply_get_battery_info currently only supports devicetree
>>>>> [   12.154388] bq27xxx_battery_settings: power_supply_get_battery_info failed ret=-6
>>> 
>>> Is there also a bq27000 chip on this device, or a battery with it
>>> embedded? If so, it doesn't appear to have a DT node (correct for
>>> embedded), hence that warning, which isn't useful in that case. Prob
>>> battery_settings() should do:
>>>   if (!di->dev->of_node || power_supply_get_battery_info(...) < 0) return;
>>> altho that would be wrong once get_battery_info() supports ACPI config...
>> 
>> No it is not available, but could be. The bq27000 can be connected through
>> HDQ to an OMAP3 and therefore there is no auto-detection. If it is configured
>> the driver will be loaded. Even if there is no battery_info.
>> 
>> In fact we use the same defconfig for several devices and there is one (GTA04)
>> which only has a bq27000 inside the battery.
> 
> Any idea why the driver detects a non-present bq27000 and calls
> probe() for it? defconfig with battery_bq27xxx=y ?

Yes.

The key reason is that hdq can't detect presence of a device
without support of the device driver. Which means as soon as
you have hdq and the battery driver it will be present and
create /sys/class/power entry. Which says "battery not present".

It is the best it can do. Especially for removeable batteries
(which might be installed some time after boot and probing).

If you want to study further, there is some code in the hdq
subsystem to load the bq27000.

BR,
Nikolaus