[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <D003BFF9-737D-432D-B522-9AD5E60A6E9A@goldelico.com>
Date: Fri, 22 Aug 2025 15:00:18 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Andreas Kemnade <andreas@...nade.info>
Cc: Sebastian Reichel <sre@...nel.org>,
Jerry Lv <Jerry.Lv@...s.com>,
Pali Rohár <pali@...nel.org>,
linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org,
letux-kernel@...nphoenux.org,
stable@...r.kernel.org,
kernel@...a-handheld.com
Subject: Re: [PATCH] power: supply: bq27xxx: fix error return in case of no
bq27000 hdq battery
Hi,
> Am 22.08.2025 um 08:51 schrieb H. Nikolaus Schaller <hns@...delico.com>:
>
>
> What do you mean with "catched earlier"? What is your proposal?
>
> Well, as proposed by Jerry earlier, it appears as if it can also be handled in bq27xxx_battery_hdq_read()
> by detecting the register BQ27XXX_REG_FLAGS and the read value 0xff and return -ENODEV.
I tried this but there are more locations where BQ27XXX_REG_FLAGS are read and where the reading
code is not prepared to receive an -ENODEV. This will for example emit
[ 293.389831] w1_slave_driver 01-000000000000: error reading flags
each time the battery is removed. And in some race cases (a read of the full /sys properties is
already in progress), there may be more than one such message. That is not nice to replace one
console message with another...
So I am not sure if it is a good idea to make the lowest layer ("catched earlier") read function
detect -ENODEV based on the register number. It can not know what the next layer wants to do with
the result.
BR,
Nikolaus
Powered by blists - more mailing lists