Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4615442yba; Wed, 10 Apr 2019 00:56:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqwCP9/Li5BceFusikcnQHg0GkmVJi8oFghCq5uXYwkJpuCq8oR7mXu69BOoRNh0b/GZNV+j X-Received: by 2002:a62:424f:: with SMTP id p76mr41876759pfa.141.1554882993519; Wed, 10 Apr 2019 00:56:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554882993; cv=none; d=google.com; s=arc-20160816; b=UxCVpoNsWpJR0CyzxEPormwBeEVnAoDyChbJ0YyJDAISdtwlj/jha4E4wb8BFSk4UG alxCwZ0D624Ob2dikUu5aan9ycnzTnON6LtwGi8zW7xgKP/UlhVT1ZRsIZe9hrmPjPki en8oAVhpOFCiasQaReVLzCBYuUqgncan7Gz7YPtths9Nt58zCjLCIHxddnApomlyUsdk bNv7Pauadw6v5dgz230B6jrKdvFovzbOvhi7vAII4qxANAtxtH+B1ZbEH/Ur/9mMhay2 8zLqtP43pI1M5INuZcs6O0W0YXUPzGJ7P6alQGVSWaAaty+WWm2n+z8sXT7YS9nj4oH8 Qqmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Ojoo3K0wQ8GNFdkjmLZu9Gij19qrJE1tiYR1OIRA5/w=; b=J807GZ2PnT0ahElp6lgwZGE/YvJfcBejtjSW71WqohRa6Hs4j/hfziWT5OV7IC+v8K z1rHbNMOT5XhHuVLrRUTbOtwmIFBVS/TFQATKoMhaj2PGoWT469c8G2EET1sSOl9oPpB vDZSEAJD8s2Qw+5BcA4A72igyl/snS30sNyLwumQDpuoo9Jvym4obrqp5jokNljMPKD0 bceJGSUSjBWuJIESWMhBBLx669caQSkPEaYOdcNBUDidG3STUSUklW3aIwW4cOuh0Z8b zMEaN2Binwuka5qSi3Nhd6XPfng2X0XOXXCHCBIE2Pn65vVE4RFx1i91ZxVWYmyWlMKM 0bQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=PXXQMjK1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y14si20671543pge.547.2019.04.10.00.56.17; Wed, 10 Apr 2019 00:56:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=PXXQMjK1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727196AbfDJHNu (ORCPT + 99 others); Wed, 10 Apr 2019 03:13:50 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:34314 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726052AbfDJHNu (ORCPT ); Wed, 10 Apr 2019 03:13:50 -0400 Received: by mail-ed1-f68.google.com with SMTP id x14so1069276eds.1 for ; Wed, 10 Apr 2019 00:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ojoo3K0wQ8GNFdkjmLZu9Gij19qrJE1tiYR1OIRA5/w=; b=PXXQMjK1FMeAS/PRGOKqgKlvax/2cwir+UR9ZjIFMGUr0poPK9i9V4tJvUUQbxwegA reK3IFfCumUXkq5qZn4CsG/EN9ZzvHqvbWX+ZuBrScDRV/s4s8qcyVWUsqgQgjzwotyg kDKRa2Gi0P21YNdyRuvCeyWsMwXxtSLzm3TYU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ojoo3K0wQ8GNFdkjmLZu9Gij19qrJE1tiYR1OIRA5/w=; b=DXMGrZWgT4yvqe3hwFwyalUNjIz7eAzaWYZN9D+/dM/CWav7xxs2hykU/nUkLU8mrH 0DKWaynahLUoP4elo3sYR1Ux5yh5WoyYQ+zjmrm+qWsRReyO6yCEBdPoTmD9vOLCmnAI ny6RVs5BK/11cyoPYC2MGVNkT2hY1GUNK5ih3+IRZMENGPBghoYOTR6Zl8rYVyemPzlC jJ8pYCjh9k0Xgd59pdg5SxzZAO7vJKsEO5iAQVF6VyrUdYmJHSrZk4s+u4Qrkix3KK+8 KmsrOJtdewEqvHRCnw7MpUXAiKvtvC+Mv6c4T7T0hhIUrK2rEimmFViW9Ph+hGt0d3Nw hwUQ== X-Gm-Message-State: APjAAAX1y3YmGG5KJtQMfebK/ZuaxRLgY0f7+ktFEjj8g4hox4CQQWuu ZEv8ZmCOZEMe0tMw0zqdNkIXi28Tuanw1gPTstxWMQ== X-Received: by 2002:a17:906:3153:: with SMTP id e19mr18295563eje.47.1554880427651; Wed, 10 Apr 2019 00:13:47 -0700 (PDT) MIME-Version: 1.0 References: <20190327051450.16222-1-pihsun@chromium.org> <20190327051450.16222-7-pihsun@chromium.org> In-Reply-To: From: Pi-Hsun Shih Date: Wed, 10 Apr 2019 15:13:10 +0800 Message-ID: Subject: Re: [PATCH v7 6/7] platform/chrome: cros_ec: add EC host command support using rpmsg. To: Enric Balletbo Serra Cc: Benson Leung , Enric Balletbo i Serra , Guenter Roeck , open list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, Mar 28, 2019 at 7:16 PM Enric Balletbo Serra wrote: > > Hi > > Thanks for sending this upstream, Some few comments and questions > below. Apart from these LGTM. > > Missatge de Peter Shih del dia dc., 27 de mar=C3=A7 > 2019 a les 6:17: > > > > From: Pi-Hsun Shih > > > > Add EC host command support through rpmsg. > > > > Signed-off-by: Pi-Hsun Shih > > --- > > ... > > diff --git a/drivers/platform/chrome/cros_ec_rpmsg.c b/drivers/platform= /chrome/cros_ec_rpmsg.c > > new file mode 100644 > > index 000000000000..2ecae806cfc5 > > --- /dev/null > > +++ b/drivers/platform/chrome/cros_ec_rpmsg.c > > ... > > +static int cros_ec_rpmsg_callback(struct rpmsg_device *rpdev, void *da= ta, > > + int len, void *priv, u32 src) > > +{ > > + struct cros_ec_device *ec_dev =3D dev_get_drvdata(&rpdev->dev); > > + struct cros_ec_rpmsg *ec_rpmsg =3D ec_dev->priv; > > + struct cros_ec_rpmsg_response *resp; > > + > > + if (!len) { > > + dev_warn(ec_dev->dev, "rpmsg received empty response"); > > Is this is unlikely to happen? Yes this should not happen unless the firmware is broken. Should I change this to `if(unlikely(!len))`, or use dev_err instead ? > > > + return -EINVAL; > > + } > > + > > + resp =3D data; > > + len -=3D offsetof(struct cros_ec_rpmsg_response, data); > > + if (resp->type =3D=3D HOST_COMMAND_MARK) { > > + if (len > ec_dev->din_size) { > > + dev_warn( > > + ec_dev->dev, > > + "received length %d > din_size %d, trun= cating", > > + len, ec_dev->din_size); > > How often this warning appears? Should be this a dev_dbg? This also should not happen unless the firmware is broken, so I think it's better to have a warning here when there's something wrong. > > > + len =3D ec_dev->din_size; > > + } > > + > > + memcpy(ec_dev->din, resp->data, len); > > + complete(&ec_rpmsg->xfer_ack); > > + } else if (resp->type =3D=3D HOST_EVENT_MARK) { > > + schedule_work(&ec_rpmsg->host_event_work); > > + } else { > > + dev_warn(ec_dev->dev, "rpmsg received invalid type =3D = %d", > > + resp->type); > > Is this is unlikely to happen? Same as above, this should not happen unless the firmware is broken. > > > + return -EINVAL; > > + } > > + > > + return 0; > > +} > > + > > +static int cros_ec_rpmsg_probe(struct rpmsg_device *rpdev) > > +{ > > + struct device *dev =3D &rpdev->dev; > > + struct cros_ec_device *ec_dev; > > + struct cros_ec_rpmsg *ec_rpmsg; > > + int ret; > > + > > + ec_dev =3D devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL); > > + if (!ec_dev) > > + return -ENOMEM; > > + > > + ec_rpmsg =3D devm_kzalloc(dev, sizeof(*ec_rpmsg), GFP_KERNEL); > > + if (!ec_rpmsg) > > + return -ENOMEM; > > + > > + ec_dev->dev =3D dev; > > + ec_dev->priv =3D ec_rpmsg; > > + ec_dev->cmd_xfer =3D cros_ec_cmd_xfer_rpmsg; > > + ec_dev->pkt_xfer =3D cros_ec_pkt_xfer_rpmsg; > > + ec_dev->phys_name =3D dev_name(&rpdev->dev); > > + ec_dev->din_size =3D sizeof(struct ec_host_response) + > > + sizeof(struct ec_response_get_protocol_info)= ; > > + ec_dev->dout_size =3D sizeof(struct ec_host_request); > > + dev_set_drvdata(dev, ec_dev); > > + > > + ec_rpmsg->rpdev =3D rpdev; > > + init_completion(&ec_rpmsg->xfer_ack); > > + INIT_WORK(&ec_rpmsg->host_event_work, > > + cros_ec_rpmsg_host_event_function); > > + > > + ret =3D cros_ec_register(ec_dev); > > + if (ret) { > > + dev_err(dev, "cannot register EC\n"); > > + return ret; > > + } > > + > > + return 0; > > cros_ec_register returns 0 on success and prints an error message if > something went wrong. Remove the above and just do: > > return cros_ec_register(ec_dev); > Ack, would change this in v7. > > > +} > > + > > +static void cros_ec_rpmsg_remove(struct rpmsg_device *rpdev) > > +{ > > + struct cros_ec_device *ec_dev =3D dev_get_drvdata(&rpdev->dev); > > + struct cros_ec_rpmsg *ec_rpmsg =3D ec_dev->priv; > > + > > + cancel_work_sync(&ec_rpmsg->host_event_work); > > +} > > + > > +static const struct of_device_id cros_ec_rpmsg_of_match[] =3D { > > + { .compatible =3D "google,cros-ec-rpmsg", }, > > + { } > > +}; > > +MODULE_DEVICE_TABLE(of, cros_ec_rpmsg_of_match); > > + > > +static struct rpmsg_driver cros_ec_driver_rpmsg =3D { > > + .drv =3D { > > + .name =3D KBUILD_MODNAME, > > + .of_match_table =3D cros_ec_rpmsg_of_match, > > + }, > > + .probe =3D cros_ec_rpmsg_probe, > > + .remove =3D cros_ec_rpmsg_remove, > > + .callback =3D cros_ec_rpmsg_callback, > > +}; > > + > > +module_rpmsg_driver(cros_ec_driver_rpmsg); > > + > > +MODULE_LICENSE("GPL v2"); > > +MODULE_DESCRIPTION("ChromeOS EC multi function device (rpmsg)"); > > -- > > 2.21.0.392.gf8f6787159e-goog > >