Tzung-Bi Shih tzungbi@google.com 於 2020年7月3日 週五 下午3:32寫道：
On Fri, Jul 3, 2020 at 3:19 PM Yu-Hsuan Hsu yuhsuan@chromium.org 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.
Alternatively, you can still use cros_ec_cmd_xfer_status( ). I guess it is okay to have 2 logs for an error.
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)I am thinking of if it is a better solution to print msg->result here.
The problem is the msg->result is not always meaningful. In cros_ec_cmd_xfer_status, we know that the msg->result is meaningful only when ret == 0. Therefore, we can not print the msg->result directly here.
In addition, adding a conditional operator here to check whether ret is -EPROTO is not a good way, either. We should consider the situation that cros_ec_cmd_xfer may return -EPROTO directly.
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;}So that you don't need this block.