[PATCH v2] ASoC: cros_ec_codec: Log results when EC commands fail

[Yu-Hsuan Hsu]

Enric Balletbo i Serra <enric.balletbo at collabora.com> 於 2020年7月3日 週五 下午5:19寫道：
>
> Hi Yu-Hsuan,
>
> On 3/7/20 10:48, Yu-Hsuan Hsu wrote:
> > Enric Balletbo i Serra <enric.balletbo at collabora.com> 於 2020年7月3日 週五 下午4:38寫道：
> >>
> >> Hi Yu-Hsuan,
> >>
> >> Thank you for your patch
> >>
> >> On 3/7/20 9:19, Yu-Hsuan Hsu wrote:
> >>> Log results of failed EC commands to identify a problem more easily.
> >>>
> >>> Replace cros_ec_cmd_xfer_status with cros_ec_cmd_xfer because the result
> >>> has already been checked in this function. The wrapper is not needed.
> >>>
> >>
> >> Nack, we did an effort to remove all public users of cros_ec_cmd_xfer() in
> >> favour of cros_ec_cmd_xfer_status() and you are reintroducing again. You can do
> >> the same but using cros_ec_cmd_xfer_status(). In fact, your patch will not build
> >> on top of the upcoming changes.
> > Thanks! But I have a question about implementing it. Does it look like
> > the one below?
> > ret = cros_ec_cmd_xfer_status(ec_dev, msg);
> > if (ret < 0) {
>
> In this case will already print an error.
>
> What are you trying to achieve?
>
> If the only reason is of this patch is print a message you should either, or
> enable dynamic printk and enable dev_dbg or event better use the kernel trace
> functionality. There is no need to be more verbose.
>
> Example:
>     $ echo 1 > /sys/kernel/debug/tracing/events/cros_ec/enable
>     $ cat /sys/kernel/debug/tracing/trace
>
>     369.416372: cros_ec_request_start: version: 0, command: EC_CMD_USB_PD_POWER_INFO
>     369.420528: cros_ec_request_done: version: 0, command:
> EC_CMD_USB_PD_POWER_INFO, ec result: EC_RES_SUCCESS, retval: 16
>
> Cheers,
>  Enric
>
Thank Enric,

The situation is that some users encountered errors on ChromeBook.
>From their feedback reports, we only get the message like
'cros-ec-codec GOOG0013:00: ASoC: Failed to set DAI format: -71'.
We know that -71 is -EPROTO but it is not clear enough for us to find
out the root cause. That's why we want the detail of the result.
Because the situation happens on users' side, it is not possible for
them to enable kernel trace (ChromeOS does not allow users to touch
kernel).

The other way we thought is changing dev_dbg to dev_err in
cros_ec_cmd_xfer_status. But we are not sure whether it is also an
error for other usages.

> >   if (ret == -EPROTO)
> >     dev_err(..., msg->result)
> >   goto error;
> > }
> > I'm not sure whether it makes sense to check ret == -EPROTO here.
> >
> >>
> >>> Signed-off-by: Yu-Hsuan Hsu <yuhsuan at chromium.org>
> >>> ---
> >>>  sound/soc/codecs/cros_ec_codec.c | 9 ++++++++-
> >>>  1 file changed, 8 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/sound/soc/codecs/cros_ec_codec.c b/sound/soc/codecs/cros_ec_codec.c
> >>> index 8d45c628e988e..a4ab62f59efa6 100644
> >>> --- a/sound/soc/codecs/cros_ec_codec.c
> >>> +++ b/sound/soc/codecs/cros_ec_codec.c
> >>> @@ -90,10 +90,17 @@ static int send_ec_host_command(struct cros_ec_device *ec_dev, uint32_t cmd,
> >>>       if (outsize)
> >>>               memcpy(msg->data, out, outsize);
> >>>
> >>> -     ret = cros_ec_cmd_xfer_status(ec_dev, msg);
> >>> +     ret = cros_ec_cmd_xfer(ec_dev, msg);
> >>>       if (ret < 0)
> >>>               goto error;
> >>>
> >>> +     if (msg->result != EC_RES_SUCCESS) {
> >>> +             dev_err(ec_dev->dev, "Command %d failed: %d\n", cmd,
> >>> +                     msg->result);
> >>> +             ret = -EPROTO;
> >>> +             goto error;
> >>> +     }
> >>> +
> >>>       if (insize)
> >>>               memcpy(in, msg->data, insize);
> >>>
> >>>