On Sat, 16 Jun 2018, Thomas Weißschuh wrote: > The error codes for ACPI failures when setting battery start and stop > thresholds were gobbling the real error code and also inconsistent.
Well, we do not care for ACPI failure codes (other than the fact it failed): we care for proper errno return to userspace, which is to be enforced on *this* function, so, "return rval" is not what we want here... > - if (tpacpi_battery_set(THRESHOLD_START, battery, value)) > - return -ENODEV; > + rval = tpacpi_battery_set(THRESHOLD_START, battery, value); > + if (rval) > + return rval; Before, a side-effect of this was to report that the device isn't there, I very much think this was done on purpose. Ognjen, what would be the best interpretation of a failure on THRESHOLD_START ? -ENODEV (current code) or -EINVAL ? -- Henrique Holschuh ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
