Hi,
Am Mon, 21 Jul 2025 14:46:09 +0200 schrieb "H. Nikolaus Schaller" hns@goldelico.com:
Since commit
commit f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy")
the console log of some devices with hdq but no bq27000 battery (like the Pandaboard) is flooded with messages like:
[ 34.247833] power_supply bq27000-battery: driver failed to report 'status' property: -1
as soon as user-space is finding a /sys entry and trying to read the "status" property.
It turns out that the offending commit changes the logic to now return the value of cache.flags if it is <0. This is likely under the assumption that it is an error number. In normal errors from bq27xxx_read() this is indeed the case.
But there is special code to detect if no bq27000 is installed or accessible through hdq/1wire and wants to report this. In that case, the cache.flags are set (historically) to constant -1 which did make reading properties return -ENODEV. So everything appeared to be fine before the return value was fixed. Now the -1 is returned as -ENOPERM instead of -ENODEV, triggering the error condition in power_supply_format_property() which then floods the console log.
So we change the detection of missing bq27000 battery to simply set
cache.flags = -ENODEV
instead of -1.
This all is a bit inconsistent, the offending commit makes it worse. Normally devices appear only in /sys if they exist. Regarding stuff in /sys/class/power_supply, input power supplies might be there or not, but there you can argument that the entry in /sys/class/power_supply only means that there is a connector for connecting a supply. But having the battery entry everywhere looks like waste. If would expect the existence of a battery bay in the device where the common battery is one with a bq27xxx.
Regards, Andreas