Hi, On 8/7/20 22:32, Guenter Roeck wrote: > On 7/8/20 11:59 AM, kernelci.org bot wrote: >> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >> * This automated bisection report was sent to you on the basis * >> * that you may be involved with the breaking commit it has * >> * found. No manual investigation has been done to verify it, * >> * and the root cause of the problem may be somewhere else. * >> * * >> * If you do send a fix, please include this trailer: * >> * Reported-by: "kernelci.org bot" <b...@kernelci.org> * >> * * >> * Hope this helps! * >> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >> >> chrome-platform/for-kernelci bisection: baseline.bootrr.rockchip-dp-probed >> on rk3399-gru-kevin >> >> Summary: >> Start: 154353417996 KERNELCI: x86_64_defconfig: Enable support for >> Chromebooks devices >> Plain log: >> https://storage.kernelci.org/chrome-platform/for-kernelci/v5.8-rc1-20-g154353417996/arm64/defconfig/gcc-8/lab-collabora/baseline-rk3399-gru-kevin.txt >> HTML log: >> https://storage.kernelci.org/chrome-platform/for-kernelci/v5.8-rc1-20-g154353417996/arm64/defconfig/gcc-8/lab-collabora/baseline-rk3399-gru-kevin.html >> Result: 8c9a6ef40bf4 platform/chrome: cros_ec_proto: Convert EC error >> codes to Linux error codes >> >> Checks: >> revert: PASS >> verify: PASS >> >> Parameters: >> Tree: chrome-platform >> URL: >> https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git >> Branch: for-kernelci >> Target: rk3399-gru-kevin >> CPU arch: arm64 >> Lab: lab-collabora >> Compiler: gcc-8 >> Config: defconfig >> Test case: baseline.bootrr.rockchip-dp-probed >> >> Breaking commit found: >> >> ------------------------------------------------------------------------------- >> commit 8c9a6ef40bf400c64c9907031bd32b59f9d4aea2 >> Author: Guenter Roeck <li...@roeck-us.net> >> Date: Sat Jul 4 07:26:07 2020 -0700 >> >> platform/chrome: cros_ec_proto: Convert EC error codes to Linux error >> codes >> >> The EC reports a variety of error codes. Most of those, with the >> exception >> of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the >> actual >> error code gets lost. Convert all EC errors to Linux error codes to >> report >> a more meaningful error to the caller to aid debugging. >> >> Cc: Yu-Hsuan Hsu <yuhs...@chromium.org> >> Cc: Prashant Malani <pmal...@chromium.org> >> Signed-off-by: Guenter Roeck <li...@roeck-us.net> >> Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com> >>
So, as Guenter pointed I dropped this patch now. > > So, just FTR, turns out that there are callers which specifically check for > -EPROTO and examine the EC error code if it is returned, or just accept > -EPROTO as generic failure (but nothing else). Example is > drivers/pwm/pwm-cros-ec.c: > cros_ec_num_pwms(). Such commands now fail, in this case because > EC_RES_INVALID_PARAM is now returned as -EINVAL and cros_ec_num_pwms() > doesn't expect that. > Right, that's interesting, and I'll take in consideration for future reworks of the above patch and also take a deeper look at those specific cases reported. BTW, Guillaume, I queued that patch to give a try and test 3 days ago. Is the bisection job expected to take that time to run? In this case I think it also took some time to receive the build test, so probably is just a matter of having lot of jobs in the queue? I am not complaining at all, just curious, and just want to know to improve my maintainer workflow. Thanks, Enric > drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c has a similar problem; > it only accepts -EPROTO as "valid" error, but nothing else. I didn't check > for others. > > Guenter >
