All of lore.kernel.org
 help / color / mirror / Atom feed
From: Prashant Malani <pmalani@chromium.org>
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Benson Leung" <bleung@chromium.org>,
	"Guenter Roeck" <groeck@chromium.org>,
	"open list:PWM SUBSYSTEM" <linux-pwm@vger.kernel.org>
Subject: Re: [PATCH 13/17] pwm: cros-ec: Remove cros_ec_cmd_xfer_status()
Date: Mon, 3 Feb 2020 10:39:39 -0800	[thread overview]
Message-ID: <CACeCKacLSYF_MWqTxidQW5m__vDXSnPVgKttLcLU4X_4xfrJAQ@mail.gmail.com> (raw)
In-Reply-To: <CACeCKac=WyYZqnP=OqG9CoMWUfJzE=RwE+CtXhAbu7G5gmBfCA@mail.gmail.com>

Hi Enric,

On Mon, Feb 3, 2020 at 10:26 AM Prashant Malani <pmalani@chromium.org> wrote:
>
> On Mon, Feb 3, 2020 at 7:33 AM Enric Balletbo i Serra
> <enric.balletbo@collabora.com> wrote:
> >
> >
> > On 30/1/20 21:31, Prashant Malani wrote:
> > > Convert one existing usage of cros_ec_cmd_xfer_status() to
> > > cros_ec_send_cmd_msg(), which accomplishes the same thing but also does
> > > the EC message struct setup,and is defined in platform/chrome and is
> > > accessible by other modules.
> > >
> > > For the other usage, switch it to using cros_ec_cmd_xfer(), since the
> > > calling functions rely on the result field of the struct cros_ec_command
> > > struct that is used.
> > >
> > > Signed-off-by: Prashant Malani <pmalani@chromium.org>
> > > ---
> > >  drivers/pwm/pwm-cros-ec.c | 27 +++++++++------------------
> > >  1 file changed, 9 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c
> > > index 89497448d21775..8bf610a6529e7e 100644
> > > --- a/drivers/pwm/pwm-cros-ec.c
> > > +++ b/drivers/pwm/pwm-cros-ec.c
> > > @@ -32,25 +32,14 @@ static inline struct cros_ec_pwm_device *pwm_to_cros_ec_pwm(struct pwm_chip *c)
> > >
> > >  static int cros_ec_pwm_set_duty(struct cros_ec_device *ec, u8 index, u16 duty)
> > >  {
> > > -     struct {
> > > -             struct cros_ec_command msg;
> > > -             struct ec_params_pwm_set_duty params;
> > > -     } __packed buf;
> > > -     struct ec_params_pwm_set_duty *params = &buf.params;
> > > -     struct cros_ec_command *msg = &buf.msg;
> > > -
> > > -     memset(&buf, 0, sizeof(buf));
> > > +     struct ec_params_pwm_set_duty params = {0};
> > >
> > > -     msg->version = 0;
> > > -     msg->command = EC_CMD_PWM_SET_DUTY;
> > > -     msg->insize = 0;
> > > -     msg->outsize = sizeof(*params);
> > > -
> > > -     params->duty = duty;
> > > -     params->pwm_type = EC_PWM_TYPE_GENERIC;
> > > -     params->index = index;
> > > +     params.duty = duty;
> > > +     params.pwm_type = EC_PWM_TYPE_GENERIC;
> > > +     params.index = index;
> > >
> > > -     return cros_ec_cmd_xfer_status(ec, msg);
> > > +     return cros_ec_send_cmd_msg(ec, 0, EC_CMD_PWM_SET_DUTY, &params,
> > > +                                 sizeof(params), NULL, 0);
> > >  }
> > >
> > >  static int __cros_ec_pwm_get_duty(struct cros_ec_device *ec, u8 index,
> > > @@ -78,11 +67,13 @@ static int __cros_ec_pwm_get_duty(struct cros_ec_device *ec, u8 index,
> > >       params->pwm_type = EC_PWM_TYPE_GENERIC;
> > >       params->index = index;
> > >
> > > -     ret = cros_ec_cmd_xfer_status(ec, msg);
> > > +     ret = cros_ec_cmd_xfer(ec, msg);
> >
> > Why? There is a good reason we introduced the cros_ec_cmd_xfer_status.
> >
> > IMO the purpose of introduce the new wrapper only makes sense if we can cover
> > _all_ the cases, so we can remove cros_ec_cmd_xfer_status and make
> > cros_ec_cmd_xfer private to cros_ec_proto.
I'm hoping for that too, but as we saw below (and some in some other
drivers), some callers of cros_ec_cmd_xfer() actually use the
msg->result.
Should we change the new wrapper to return the message via a pointer
(if not NULL), so something like this ? :

int cros_ec_send_cmd_msg(struct cros_ec_device *ec, unsigned int
version, uint32_t command, void *outdata, unsigned int outsize,
void *indata, unsigned int insize, uint32_t *result) ?

> >
> > Is not possible to use the new wrapper here?
> >
> > >       if (result)
> > >               *result = msg->result;
> >
> > Hmm, I see, that's the problem ...
> >
> > This driver will need a bit of rework but I think could be possible to use the
> > wrapper.
> Yeah, I looked around, and it seems to use msg->result.
> Perhaps we should work on reworking this driver before doing the large
> patch series? I would be happy to work on it, unless you feel there is
> someone else who'd be better suited. Kindly let me know.
> >
> > >       if (ret < 0)
> > >               return ret;
> > > +     else if (msg->result != EC_RES_SUCCESS)
> > > +             return -EPROTO;
> > >
> > >       return resp->duty;
> > >  }
> > >

  reply	other threads:[~2020-02-03 18:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 20:30 [PATCH 00/17] platform/chrome: Replace cros_ec_cmd_xfer_status Prashant Malani
2020-01-30 20:30 ` Prashant Malani
2020-01-30 20:30 ` [PATCH 01/17] platform/chrome: Add EC command msg wrapper Prashant Malani
2020-02-03 15:27   ` Enric Balletbo i Serra
2020-02-03 18:24     ` Prashant Malani
2020-01-30 20:30 ` [PATCH 02/17] platform/chrome: chardev: Use send_cmd_msg() Prashant Malani
2020-01-30 20:30 ` [PATCH 03/17] platform/chrome: proto: Use send_cmd_msg Prashant Malani
2020-01-30 20:30 ` [PATCH 04/17] platform/chrome: usbpd_logger: Use cmd_send_msg() Prashant Malani
2020-01-30 20:30 ` [PATCH 05/17] platform/chrome: sensorhub: Use send_cmd_msg() Prashant Malani
2020-01-30 20:30 ` [PATCH 06/17] platform/chrome: debugfs: " Prashant Malani
2020-01-30 20:30 ` [PATCH 07/17] platform/chrome: sysfs: " Prashant Malani
2020-01-30 20:30 ` [PATCH 08/17] extcon: cros_ec: Use cros_ec_send_cmd_msg() Prashant Malani
2020-01-30 20:30 ` [PATCH 09/17] hid: google-hammer: " Prashant Malani
2020-01-30 20:30 ` [PATCH 10/17] iio: cros_ec: " Prashant Malani
2020-02-02  9:43   ` Jonathan Cameron
2020-02-03 18:31     ` Prashant Malani
2020-01-30 20:30 ` [PATCH 11/17] ASoC: cros_ec_codec: " Prashant Malani
2020-01-30 20:30   ` [alsa-devel] " Prashant Malani
2020-02-01 11:03   ` Mark Brown
2020-02-01 11:03     ` [alsa-devel] " Mark Brown
2020-02-03 18:42     ` Prashant Malani
2020-02-03 18:42       ` [alsa-devel] " Prashant Malani
2020-01-30 20:30 ` [PATCH 12/17] power: supply: cros: " Prashant Malani
2020-01-30 20:31 ` [PATCH 13/17] pwm: cros-ec: Remove cros_ec_cmd_xfer_status() Prashant Malani
2020-01-30 20:31   ` Prashant Malani
2020-02-03 15:33   ` Enric Balletbo i Serra
2020-02-03 18:26     ` Prashant Malani
2020-02-03 18:39       ` Prashant Malani [this message]
2020-01-30 20:31 ` [PATCH 14/17] rtc: cros-ec: Use cros_ec_send_cmd_msg() Prashant Malani
2020-01-30 20:31 ` [PATCH 15/17] media: cros-ec-cec: " Prashant Malani
2020-02-02 22:08   ` kbuild test robot
2020-02-02 22:08     ` kbuild test robot
2020-02-03  5:35   ` kbuild test robot
2020-02-03  5:35     ` kbuild test robot
2020-01-30 20:31 ` [PATCH 16/17] i2c: cros-ec-tunnel: " Prashant Malani
2020-01-30 20:31   ` Prashant Malani
2020-01-30 20:31 ` [PATCH 17/17] platform/chrome: Drop cros_ec_cmd_xfer_status() Prashant Malani
2020-02-03 15:35   ` Enric Balletbo i Serra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACeCKacLSYF_MWqTxidQW5m__vDXSnPVgKttLcLU4X_4xfrJAQ@mail.gmail.com \
    --to=pmalani@chromium.org \
    --cc=bleung@chromium.org \
    --cc=enric.balletbo@collabora.com \
    --cc=groeck@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.