[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ce0bfe13-38b8-1891-802c-84b4148333d1@roeck-us.net>
Date: Fri, 21 Aug 2020 08:39:40 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Enric Balletbo i Serra <enric.balletbo@...labora.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
Benson Leung <bleung@...omium.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Thierry Reding <thierry.reding@...il.com>,
Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
Lee Jones <lee.jones@...aro.org>,
Gwendal Grignou <gwendal@...omium.org>,
Brian Norris <briannorris@...omium.org>,
Yu-Hsuan Hsu <yuhsuan@...omium.org>,
Prashant Malani <pmalani@...omium.org>,
linux-iio@...r.kernel.org, linux-input@...r.kernel.org,
linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/7] platform/chrome: cros_ec_proto: Convert EC error
codes to Linux error codes
On 8/21/20 1:21 AM, Enric Balletbo i Serra wrote:
> Hi Guenter et all,
>
> On 6/8/20 17:33, Guenter Roeck wrote:
>> 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. In cros_ec_cmd_xfer_status(), convert all EC errors
>> to Linux error codes to report a more meaningful error to the caller to aid
>> debugging.
>>
>> To prepare for this change, handle error codes other than -EPROTO for all
>> callers of cros_ec_cmd_xfer_status(). Specifically, no longer assume that
>> -EPROTO reflects an error from the EC and all other error codes reflect a
>> transfer error.
>>
>> v2: Add patches 1/4 to 3/4 to handle callers of cros_ec_cmd_xfer_status()
>> v3: Add patches 4/6 and 5/6 to handle additional callers of
>> cros_ec_cmd_xfer_status()
>> Use -ENOPROTOOPT for EC_RES_INVALID_VERSION
>> Implement function to convert error codes
>> v4: Add coments describing the functionality of cros_ec_num_pwms().
>> Add patch 7/7 to clean up cros_ec_num_pwms() after the new error code
>> support has been implemented.
>> Rebased series to v5.8.
>>
>> ----------------------------------------------------------------
>> Guenter Roeck (7):
>> iio: cros_ec: Accept -EOPNOTSUPP as 'not supported' error code
>> cros_ec_lightbar: Accept more error codes from cros_ec_cmd_xfer_status
>> platform/chrome: cros_ec_sysfs: Report range of error codes from EC
>> pwm: cros-ec: Accept more error codes from cros_ec_cmd_xfer_status
>> platform/input: cros_ec: Replace -ENOTSUPP with -ENOPROTOOPT
>> platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes
>> pwm: cros-ec: Simplify EC error handling
>>
>> .../iio/common/cros_ec_sensors/cros_ec_sensors.c | 2 +-
>> drivers/input/keyboard/cros_ec_keyb.c | 2 +-
>> drivers/platform/chrome/cros_ec_lightbar.c | 10 ++---
>> drivers/platform/chrome/cros_ec_proto.c | 52 +++++++++++++++++-----
>> drivers/platform/chrome/cros_ec_sysfs.c | 24 ++++------
>> drivers/pwm/pwm-cros-ec.c | 37 +++++++--------
>> 6 files changed, 74 insertions(+), 53 deletions(-)
>>
>
> The patches LGTM, and if the other maintainers are fine, I'd like to queue all
> these through the chrome-platform tree.
>
> I noticed, thought, that KernelCI reported a regression on Kevin that I'll try
> to debug at the beginning of next week.
>
> [ 3.821203] cros-ec-spi spi2.0: Wrong size 1/3: 0 != 4
> [ 3.827320] cros-ec-keyb ff200000.spi:ec@0:keyboard-controller: cannot
> register non-matrix inputs: -71
> [ 3.838506] cros-ec-keyb: probe of ff200000.spi:ec@0:keyboard-controller
> failed with error -71
> [ 3.853492] cros-ec-spi spi2.0: Chrome EC device registered
>
Easy to debug. cros_ec_cmd_xfer_status() now returns 0 for success and < 0 for errors.
It needs to return the receive length if there is no error. I'll send v5 with a fix,
and sorry for the trouble.
Thanks,
Guenter
Powered by blists - more mailing lists