* [PATCH] mfd: cros_ec: check for NULL transfer function @ 2019-04-03 18:30 egranata 2019-04-03 18:51 ` Guenter Roeck 0 siblings, 1 reply; 8+ messages in thread From: egranata @ 2019-04-03 18:30 UTC (permalink / raw) To: bleung, groeck, gwendal, amstan Cc: enric.balletbo, linux-kernel, Enrico Granata From: Enrico Granata <egranata@chromium.org> As new transfer mechanisms are added to the EC codebase, they may not support v2 of the EC protocol. If the v3 initial handshake transfer fails, the kernel will try and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer will be NULL, and the code will end up causing a kernel panic. Add a check for NULL before calling the transfer function, along with a helpful comment explaining how one might end up in this situation. Signed-off-by: Enrico Granata <egranata@chromium.org> --- drivers/platform/chrome/cros_ec_proto.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c index 97a068dff192d..953076ab401aa 100644 --- a/drivers/platform/chrome/cros_ec_proto.c +++ b/drivers/platform/chrome/cros_ec_proto.c @@ -56,6 +56,16 @@ static int send_command(struct cros_ec_device *ec_dev, else xfer_fxn = ec_dev->cmd_xfer; + if (xfer_fxn == NULL) { + /* This error can happen if a communication error happened and + * the EC is trying to use protocol v2, on an underlying + * communication mechanism that does not support v2. + */ + dev_err(ec_dev->dev, + "missing EC transfer API, cannot send command\n"); + return -EIO; + } + ret = (*xfer_fxn)(ec_dev, msg); if (msg->result == EC_RES_IN_PROGRESS) { int i; -- 2.21.0.392.gf8f6787159e-goog ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] mfd: cros_ec: check for NULL transfer function 2019-04-03 18:30 [PATCH] mfd: cros_ec: check for NULL transfer function egranata @ 2019-04-03 18:51 ` Guenter Roeck 2019-04-03 19:40 ` Enrico Granata [not found] ` <CAPR809vTZSFtNp61WQsOFRkFacO_8XEdicqFq9uYMkUMdjEsqg@mail.gmail.com> 0 siblings, 2 replies; 8+ messages in thread From: Guenter Roeck @ 2019-04-03 18:51 UTC (permalink / raw) To: egranata Cc: Benson Leung, Guenter Roeck, Gwendal Grignou, Alexandru M Stan, Enric Balletbo i Serra, linux-kernel On Wed, Apr 3, 2019 at 11:31 AM <egranata@chromium.org> wrote: > > From: Enrico Granata <egranata@chromium.org> > > As new transfer mechanisms are added to the EC codebase, they may > not support v2 of the EC protocol. > > If the v3 initial handshake transfer fails, the kernel will try > and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer > will be NULL, and the code will end up causing a kernel panic. > > Add a check for NULL before calling the transfer function, along > with a helpful comment explaining how one might end up in this > situation. > > Signed-off-by: Enrico Granata <egranata@chromium.org> > --- > drivers/platform/chrome/cros_ec_proto.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c > index 97a068dff192d..953076ab401aa 100644 > --- a/drivers/platform/chrome/cros_ec_proto.c > +++ b/drivers/platform/chrome/cros_ec_proto.c > @@ -56,6 +56,16 @@ static int send_command(struct cros_ec_device *ec_dev, > else > xfer_fxn = ec_dev->cmd_xfer; > > + if (xfer_fxn == NULL) { > + /* This error can happen if a communication error happened and > + * the EC is trying to use protocol v2, on an underlying > + * communication mechanism that does not support v2. > + */ I am not personally a friend of networking-style multi-line comments. > + dev_err(ec_dev->dev, > + "missing EC transfer API, cannot send command\n"); That message will be displayed each time a message is sent, ie in practice for each message. Is there any value in that, other than clogging the log ? Guenter > + return -EIO; > + } > + > ret = (*xfer_fxn)(ec_dev, msg); > if (msg->result == EC_RES_IN_PROGRESS) { > int i; > -- > 2.21.0.392.gf8f6787159e-goog > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mfd: cros_ec: check for NULL transfer function 2019-04-03 18:51 ` Guenter Roeck @ 2019-04-03 19:40 ` Enrico Granata [not found] ` <CAPR809vTZSFtNp61WQsOFRkFacO_8XEdicqFq9uYMkUMdjEsqg@mail.gmail.com> 1 sibling, 0 replies; 8+ messages in thread From: Enrico Granata @ 2019-04-03 19:40 UTC (permalink / raw) To: Guenter Roeck Cc: Enrico Granata, Benson Leung, Guenter Roeck, Gwendal Grignou, Alexandru M Stan, Enric Balletbo i Serra, linux-kernel I can certainly add a "did_print_error" flag or some such, but in practice, if the transfer function is NULL, the initial handshake will fail, and this will in turn cause EC registration to fail, and no further communication should occur, so no further log entries will be printed. Thanks Enrico Granata | egranata@google.com | ChromeOS | MTV1600 On Wed, Apr 3, 2019 at 11:51 AM Guenter Roeck <groeck@google.com> wrote: > > On Wed, Apr 3, 2019 at 11:31 AM <egranata@chromium.org> wrote: > > > > From: Enrico Granata <egranata@chromium.org> > > > > As new transfer mechanisms are added to the EC codebase, they may > > not support v2 of the EC protocol. > > > > If the v3 initial handshake transfer fails, the kernel will try > > and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer > > will be NULL, and the code will end up causing a kernel panic. > > > > Add a check for NULL before calling the transfer function, along > > with a helpful comment explaining how one might end up in this > > situation. > > > > Signed-off-by: Enrico Granata <egranata@chromium.org> > > --- > > drivers/platform/chrome/cros_ec_proto.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c > > index 97a068dff192d..953076ab401aa 100644 > > --- a/drivers/platform/chrome/cros_ec_proto.c > > +++ b/drivers/platform/chrome/cros_ec_proto.c > > @@ -56,6 +56,16 @@ static int send_command(struct cros_ec_device *ec_dev, > > else > > xfer_fxn = ec_dev->cmd_xfer; > > > > + if (xfer_fxn == NULL) { > > + /* This error can happen if a communication error happened and > > + * the EC is trying to use protocol v2, on an underlying > > + * communication mechanism that does not support v2. > > + */ > > I am not personally a friend of networking-style multi-line comments. > > > + dev_err(ec_dev->dev, > > + "missing EC transfer API, cannot send command\n"); > > That message will be displayed each time a message is sent, ie in > practice for each message. Is there any value in that, other than > clogging the log ? > > Guenter > > > + return -EIO; > > + } > > + > > ret = (*xfer_fxn)(ec_dev, msg); > > if (msg->result == EC_RES_IN_PROGRESS) { > > int i; > > -- > > 2.21.0.392.gf8f6787159e-goog > > ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <CAPR809vTZSFtNp61WQsOFRkFacO_8XEdicqFq9uYMkUMdjEsqg@mail.gmail.com>]
* Re: [PATCH] mfd: cros_ec: check for NULL transfer function [not found] ` <CAPR809vTZSFtNp61WQsOFRkFacO_8XEdicqFq9uYMkUMdjEsqg@mail.gmail.com> @ 2019-04-03 19:53 ` Guenter Roeck 2019-04-03 19:54 ` Enrico Granata 2019-04-03 22:40 ` [PATCH v2] " egranata 0 siblings, 2 replies; 8+ messages in thread From: Guenter Roeck @ 2019-04-03 19:53 UTC (permalink / raw) To: Enrico Granata Cc: Enrico Granata, Benson Leung, Guenter Roeck, Gwendal Grignou, Alexandru M Stan, Enric Balletbo i Serra, linux-kernel On Wed, Apr 3, 2019 at 12:40 PM Enrico Granata <egranata@google.com> wrote: > > I can certainly add a "did_print_error" flag or some such, but in practice, if the transfer function is NULL, the initial handshake will fail, and this will in turn cause EC registration to fail, and no further communication should occur, so no further log entries will be printed. > Sorry, I am a bit lost. Why would dev_err_once() not work ? Guenter > Thanks > > Enrico Granata | egranata@google.com | ChromeOS | MTV1600 > > > On Wed, Apr 3, 2019 at 11:51 AM Guenter Roeck <groeck@google.com> wrote: >> >> On Wed, Apr 3, 2019 at 11:31 AM <egranata@chromium.org> wrote: >> > >> > From: Enrico Granata <egranata@chromium.org> >> > >> > As new transfer mechanisms are added to the EC codebase, they may >> > not support v2 of the EC protocol. >> > >> > If the v3 initial handshake transfer fails, the kernel will try >> > and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer >> > will be NULL, and the code will end up causing a kernel panic. >> > >> > Add a check for NULL before calling the transfer function, along >> > with a helpful comment explaining how one might end up in this >> > situation. >> > >> > Signed-off-by: Enrico Granata <egranata@chromium.org> >> > --- >> > drivers/platform/chrome/cros_ec_proto.c | 10 ++++++++++ >> > 1 file changed, 10 insertions(+) >> > >> > diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c >> > index 97a068dff192d..953076ab401aa 100644 >> > --- a/drivers/platform/chrome/cros_ec_proto.c >> > +++ b/drivers/platform/chrome/cros_ec_proto.c >> > @@ -56,6 +56,16 @@ static int send_command(struct cros_ec_device *ec_dev, >> > else >> > xfer_fxn = ec_dev->cmd_xfer; >> > >> > + if (xfer_fxn == NULL) { >> > + /* This error can happen if a communication error happened and >> > + * the EC is trying to use protocol v2, on an underlying >> > + * communication mechanism that does not support v2. >> > + */ >> >> I am not personally a friend of networking-style multi-line comments. >> >> > + dev_err(ec_dev->dev, >> > + "missing EC transfer API, cannot send command\n"); >> >> That message will be displayed each time a message is sent, ie in >> practice for each message. Is there any value in that, other than >> clogging the log ? >> >> Guenter >> >> > + return -EIO; >> > + } >> > + >> > ret = (*xfer_fxn)(ec_dev, msg); >> > if (msg->result == EC_RES_IN_PROGRESS) { >> > int i; >> > -- >> > 2.21.0.392.gf8f6787159e-goog >> > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mfd: cros_ec: check for NULL transfer function 2019-04-03 19:53 ` Guenter Roeck @ 2019-04-03 19:54 ` Enrico Granata 2019-04-03 22:40 ` [PATCH v2] " egranata 1 sibling, 0 replies; 8+ messages in thread From: Enrico Granata @ 2019-04-03 19:54 UTC (permalink / raw) To: Guenter Roeck Cc: Enrico Granata, Benson Leung, Guenter Roeck, Gwendal Grignou, Alexandru M Stan, Enric Balletbo i Serra, linux-kernel Because I did not know about it till right now. Thanks for the suggestion. Will upload a v2 as soon as I get a chance. On Wed, Apr 3, 2019 at 12:53 PM Guenter Roeck <groeck@google.com> wrote: > > On Wed, Apr 3, 2019 at 12:40 PM Enrico Granata <egranata@google.com> wrote: > > > > I can certainly add a "did_print_error" flag or some such, but in practice, if the transfer function is NULL, the initial handshake will fail, and this will in turn cause EC registration to fail, and no further communication should occur, so no further log entries will be printed. > > > Sorry, I am a bit lost. Why would dev_err_once() not work ? > > Guenter > > > Thanks > > > > Enrico Granata | egranata@google.com | ChromeOS | MTV1600 > > > > > > On Wed, Apr 3, 2019 at 11:51 AM Guenter Roeck <groeck@google.com> wrote: > >> > >> On Wed, Apr 3, 2019 at 11:31 AM <egranata@chromium.org> wrote: > >> > > >> > From: Enrico Granata <egranata@chromium.org> > >> > > >> > As new transfer mechanisms are added to the EC codebase, they may > >> > not support v2 of the EC protocol. > >> > > >> > If the v3 initial handshake transfer fails, the kernel will try > >> > and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer > >> > will be NULL, and the code will end up causing a kernel panic. > >> > > >> > Add a check for NULL before calling the transfer function, along > >> > with a helpful comment explaining how one might end up in this > >> > situation. > >> > > >> > Signed-off-by: Enrico Granata <egranata@chromium.org> > >> > --- > >> > drivers/platform/chrome/cros_ec_proto.c | 10 ++++++++++ > >> > 1 file changed, 10 insertions(+) > >> > > >> > diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c > >> > index 97a068dff192d..953076ab401aa 100644 > >> > --- a/drivers/platform/chrome/cros_ec_proto.c > >> > +++ b/drivers/platform/chrome/cros_ec_proto.c > >> > @@ -56,6 +56,16 @@ static int send_command(struct cros_ec_device *ec_dev, > >> > else > >> > xfer_fxn = ec_dev->cmd_xfer; > >> > > >> > + if (xfer_fxn == NULL) { > >> > + /* This error can happen if a communication error happened and > >> > + * the EC is trying to use protocol v2, on an underlying > >> > + * communication mechanism that does not support v2. > >> > + */ > >> > >> I am not personally a friend of networking-style multi-line comments. > >> > >> > + dev_err(ec_dev->dev, > >> > + "missing EC transfer API, cannot send command\n"); > >> > >> That message will be displayed each time a message is sent, ie in > >> practice for each message. Is there any value in that, other than > >> clogging the log ? > >> > >> Guenter > >> > >> > + return -EIO; > >> > + } > >> > + > >> > ret = (*xfer_fxn)(ec_dev, msg); > >> > if (msg->result == EC_RES_IN_PROGRESS) { > >> > int i; > >> > -- > >> > 2.21.0.392.gf8f6787159e-goog > >> > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] mfd: cros_ec: check for NULL transfer function 2019-04-03 19:53 ` Guenter Roeck 2019-04-03 19:54 ` Enrico Granata @ 2019-04-03 22:40 ` egranata 2019-04-04 16:00 ` Jett ✈ Rink 1 sibling, 1 reply; 8+ messages in thread From: egranata @ 2019-04-03 22:40 UTC (permalink / raw) To: groeck Cc: bleung, gwendal, amstan, enric.balletbo, linux-kernel, jettrink, Enrico Granata From: Enrico Granata <egranata@chromium.org> As new transfer mechanisms are added to the EC codebase, they may not support v2 of the EC protocol. If the v3 initial handshake transfer fails, the kernel will try and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer will be NULL, and the code will end up causing a kernel panic. Add a check for NULL before calling the transfer function, along with a helpful comment explaining how one might end up in this situation. Signed-off-by: Enrico Granata <egranata@chromium.org> --- drivers/platform/chrome/cros_ec_proto.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c index 97a068dff192d..55691656a3c27 100644 --- a/drivers/platform/chrome/cros_ec_proto.c +++ b/drivers/platform/chrome/cros_ec_proto.c @@ -56,6 +56,16 @@ static int send_command(struct cros_ec_device *ec_dev, else xfer_fxn = ec_dev->cmd_xfer; + if (xfer_fxn == NULL) { + /* This error can happen if a communication error happened and + * the EC is trying to use protocol v2, on an underlying + * communication mechanism that does not support v2. + */ + dev_err_once(ec_dev->dev, + "missing EC transfer API, cannot send command\n"); + return -EIO; + } + ret = (*xfer_fxn)(ec_dev, msg); if (msg->result == EC_RES_IN_PROGRESS) { int i; -- 2.21.0.392.gf8f6787159e-goog ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v2] mfd: cros_ec: check for NULL transfer function 2019-04-03 22:40 ` [PATCH v2] " egranata @ 2019-04-04 16:00 ` Jett ✈ Rink 2019-04-08 15:50 ` Enric Balletbo i Serra 0 siblings, 1 reply; 8+ messages in thread From: Jett ✈ Rink @ 2019-04-04 16:00 UTC (permalink / raw) To: egranata Cc: Guenter Roeck, Benson Leung, gwendal, amstan, Enric Balletbo i Serra, linux-kernel Reviewed-by: Jett Rink <jettrink@chromium.org> On Wed, Apr 3, 2019 at 4:40 PM <egranata@chromium.org> wrote: > > From: Enrico Granata <egranata@chromium.org> > > As new transfer mechanisms are added to the EC codebase, they may > not support v2 of the EC protocol. > > If the v3 initial handshake transfer fails, the kernel will try > and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer > will be NULL, and the code will end up causing a kernel panic. > > Add a check for NULL before calling the transfer function, along > with a helpful comment explaining how one might end up in this > situation. > > Signed-off-by: Enrico Granata <egranata@chromium.org> > --- > drivers/platform/chrome/cros_ec_proto.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c > index 97a068dff192d..55691656a3c27 100644 > --- a/drivers/platform/chrome/cros_ec_proto.c > +++ b/drivers/platform/chrome/cros_ec_proto.c > @@ -56,6 +56,16 @@ static int send_command(struct cros_ec_device *ec_dev, > else > xfer_fxn = ec_dev->cmd_xfer; > > + if (xfer_fxn == NULL) { > + /* This error can happen if a communication error happened and > + * the EC is trying to use protocol v2, on an underlying > + * communication mechanism that does not support v2. > + */ > + dev_err_once(ec_dev->dev, > + "missing EC transfer API, cannot send command\n"); > + return -EIO; > + } > + > ret = (*xfer_fxn)(ec_dev, msg); > if (msg->result == EC_RES_IN_PROGRESS) { > int i; > -- > 2.21.0.392.gf8f6787159e-goog > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] mfd: cros_ec: check for NULL transfer function 2019-04-04 16:00 ` Jett ✈ Rink @ 2019-04-08 15:50 ` Enric Balletbo i Serra 0 siblings, 0 replies; 8+ messages in thread From: Enric Balletbo i Serra @ 2019-04-08 15:50 UTC (permalink / raw) To: Jett ✈ Rink, egranata Cc: Guenter Roeck, Benson Leung, gwendal, amstan, linux-kernel Hi Enrico, Many thanks to send this upstream. On 4/4/19 18:00, Jett ✈ Rink wrote: > Reviewed-by: Jett Rink <jettrink@chromium.org> > > On Wed, Apr 3, 2019 at 4:40 PM <egranata@chromium.org> wrote: >> >> From: Enrico Granata <egranata@chromium.org> >> >> As new transfer mechanisms are added to the EC codebase, they may >> not support v2 of the EC protocol. >> >> If the v3 initial handshake transfer fails, the kernel will try >> and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer >> will be NULL, and the code will end up causing a kernel panic. >> >> Add a check for NULL before calling the transfer function, along >> with a helpful comment explaining how one might end up in this >> situation. >> >> Signed-off-by: Enrico Granata <egranata@chromium.org> >> --- >> drivers/platform/chrome/cros_ec_proto.c | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c >> index 97a068dff192d..55691656a3c27 100644 >> --- a/drivers/platform/chrome/cros_ec_proto.c >> +++ b/drivers/platform/chrome/cros_ec_proto.c >> @@ -56,6 +56,16 @@ static int send_command(struct cros_ec_device *ec_dev, >> else >> xfer_fxn = ec_dev->cmd_xfer; >> >> + if (xfer_fxn == NULL) { >> + /* This error can happen if a communication error happened and Like Guenter I personally don't like the networking-style multi-line comments. We try to use the default kernel-style so if you don't mind I'll change this. >> + * the EC is trying to use protocol v2, on an underlying >> + * communication mechanism that does not support v2. >> + */ >> + dev_err_once(ec_dev->dev, >> + "missing EC transfer API, cannot send command\n"); >> + return -EIO; >> + } >> + >> ret = (*xfer_fxn)(ec_dev, msg); >> if (msg->result == EC_RES_IN_PROGRESS) { >> int i; >> -- >> 2.21.0.392.gf8f6787159e-goog >> I'll add the patch to the for-next branch in chrome-platform repository for auto-builders to play with. If all goes well I'll queue the patch for chrome-platform-5.2. Thanks, Enric ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-04-08 15:50 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-03 18:30 [PATCH] mfd: cros_ec: check for NULL transfer function egranata
2019-04-03 18:51 ` Guenter Roeck
2019-04-03 19:40 ` Enrico Granata
[not found] ` <CAPR809vTZSFtNp61WQsOFRkFacO_8XEdicqFq9uYMkUMdjEsqg@mail.gmail.com>
2019-04-03 19:53 ` Guenter Roeck
2019-04-03 19:54 ` Enrico Granata
2019-04-03 22:40 ` [PATCH v2] " egranata
2019-04-04 16:00 ` Jett ✈ Rink
2019-04-08 15:50 ` Enric Balletbo i Serra
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).