Messages in this thread | | | Date | Thu, 25 Aug 2022 18:11:09 -0700 | From | Brian Norris <> | Subject | Re: [PATCH] power: supply: core: Ignore -EIO for uevent |
| |
Hi Sebastian,
Thanks for the response.
On Thu, Aug 25, 2022 at 04:02:43PM +0200, Sebastian Reichel wrote: > > For uevents, we enumerate all properties. Some battery implementations > > don't implement all standard properties, and may return -EIO for > > properties that aren't recognized. This means we never report uevents > > for such batteries. > > > > It's better to ignore these errors and skip the property, as we do with > > ENODATA and ENODEV. > > > > Example battery implementation: Acer Chromebook Tab 10 (a.k.a. Google > > Gru-Scarlet) has a virtual "SBS" battery implementation in its Embedded > > Controller on top of an otherwise non-SBS battery. > > > > Signed-off-by: Brian Norris <briannorris@chromium.org> > > --- > > -EIO means input/output error. If a driver is reporting that for an > unimplemented feature it's a bug that should be fixed in the driver. > Handling it here means userspace ABI changes for temporary issues.
I suppose I can agree with your last sentence.
But the first part is much easier said than done. This is sbs-battery.c, on top of i2c-cros-ec-tunnel.c, talking to an EC (whose firmware is pretty much unchangeable at this point), which implements a subset of commands.
The intention is that i2c-cros-ec-tunnel.c will see something like a NAK / "invalid argument" response, and it converts that to ENXIO. Unforunately, for reasons I have yet to figure out, it's very common for retries (|i2c_retry_count|) to eventually yield an unexpected response size, which i2c_smbus_xfer_emulated() treats as EIO; so this layer is seeing EIO.
Anyway, I might be able to coax the i2c/sbs-battery driver to return ENXIO instead. Would you consider that to be a better case to handle here? "No such device or address" seems like an appropriate description of a permanent error, and not a temporary IO error.
Brian
| |