From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
To: Guenter Roeck <linux@roeck-us.net>,
"kernelci.org bot" <bot@kernelci.org>,
gtucker@collabora.com, kernelci-results@groups.io
Cc: linux-kernel@vger.kernel.org, Benson Leung <bleung@chromium.org>,
Guenter Roeck <groeck@chromium.org>
Subject: Re: chrome-platform/for-kernelci bisection: baseline.bootrr.rockchip-dp-probed on rk3399-gru-kevin
Date: Thu, 9 Jul 2020 11:17:59 +0200 [thread overview]
Message-ID: <55cb5ce6-4ecb-1203-807f-c24648c0e989@collabora.com> (raw)
In-Reply-To: <a79f116f-2c6d-570d-8e06-95082d26d42d@roeck-us.net>
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" <bot@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 <linux@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 <yuhsuan@chromium.org>
>> Cc: Prashant Malani <pmalani@chromium.org>
>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@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
>
next prev parent reply other threads:[~2020-07-09 9:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-08 18:59 kernelci.org bot
2020-07-08 19:10 ` Guenter Roeck
2020-07-08 20:32 ` Guenter Roeck
2020-07-09 9:17 ` Enric Balletbo i Serra [this message]
2020-07-09 11:05 ` Guillaume Tucker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55cb5ce6-4ecb-1203-807f-c24648c0e989@collabora.com \
--to=enric.balletbo@collabora.com \
--cc=bleung@chromium.org \
--cc=bot@kernelci.org \
--cc=groeck@chromium.org \
--cc=gtucker@collabora.com \
--cc=kernelci-results@groups.io \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®