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  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:	Mon, 7 Feb 2011 02:58:32 +0200
From:	Grazvydas Ignotas <>
To:	Lars-Peter Clausen <>
Cc:	Anton Vorontsov <>,
	Rodolfo Giometti <>,
Subject: Re: [PATCH 00/14] POWER: BQ27x00: New Properties, fixes, bq27000 support

On Sun, Feb 6, 2011 at 2:47 AM, Lars-Peter Clausen <> wrote:
> This patch series contains a few updates for the bq27x00 driver:
> * Support for additional power supply properties
> * Support for the bq27000 battery which is identical to the bq27200 but is
>  connected through the HDQ bus.
> * Adds a register cache to the driver and introduces polling the batteries state
> * Minor improvements and cleanups
> The last patch in this series is not specific to the bq27x00 driver but is
> required for uevents to be generated properly for this driver.
> The patch makes properties which return -ENODATA to be ignored when generating
> uevents. Previously in such a case uevent generation would have been aborted
> with an error. But since the bq27x00 return -ENODATA for the TIME_TO_FULL
> property when the battery is not charging and for the TIME_TO_EMPTY property
> when the battery is not discharging and at least one of them is always true
> uevent generation would always fail.
> This series has so far been tested with the bq27000 and the bq27200 battery, but
> not with the bq27500 battery, so it would be nice if somebody with a board
> containing such a battery could test the patches to make sure that there are no
> regressions.

Trying this on pandora board (bq27500 over i2c) and it seems there is
something wrong with the cache, I'm always getting the old values. I'm
reading them manually over sysfs, uptime is over 25min but values
still match ones on boot, even after turning off the backlight.

Looking at the code delayed_work handling looks suspicious,
bq27x00_battery_get_property() flushes it and nothing ever reschedules
it. Other than that all new property values looks sane.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists