devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Lee Jones <lee.jones@linaro.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Olof Johansson <olof@lixom.net>,
	linux-kernel@vger.kernel.org,
	Doug Anderson <dianders@chromium.org>,
	Brian Norris <computersforpeace@gmail.com>,
	linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Stephen Barber <smbarber@chromium.org>,
	Javier Martinez Canillas <javier@osg.samsung.com>,
	Benson Leung <bleung@chromium.org>,
	Enric Balletbo <enric.balletbo@collabora.co.uk>,
	Randall Spangler <rspangler@chromium.org>,
	Shawn Nematbakhsh <shawnn@chromium.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Todd Broch <tbroch@chromium.org>,
	Gwendal Grignou <gwendal@chromium.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>
Subject: Re: [v3,1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper
Date: Fri, 17 Jun 2016 18:08:55 -0700	[thread overview]
Message-ID: <20160618010855.GA67034@google.com> (raw)
In-Reply-To: <20160617214151.GA1400@roeck-us.net>

On Fri, Jun 17, 2016 at 02:41:51PM -0700, Guenter Roeck wrote:
> On Fri, Jun 17, 2016 at 12:58:12PM -0700, Brian Norris wrote:
> > +int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
> > +			    struct cros_ec_command *msg)
> > +{
> > +	int ret;
> > +
> > +	ret = cros_ec_cmd_xfer(ec_dev, msg);
> > +	if (ret < 0)
> > +		dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
> > +	else if (msg->result != EC_RES_SUCCESS)
> > +		return -EECRESULT - msg->result;
> 
> I have been wondering about the error return codes here, and if they should be
> converted to standard Linux error codes. For example, I just hit error -1003
> with a driver I am working on. This translates to EC_RES_INVALID_PARAM, or,
> in Linux terms, -EINVAL. I think it would be better to use standard error
> codes, especially since some of the errors are logged.

How do you propose we do that? Do all of the following become EINVAL?

        EC_RES_INVALID_COMMAND
        EC_RES_INVALID_PARAM
        EC_RES_INVALID_VERSION
        EC_RES_INVALID_HEADER

We lose a lot of information that way. And particularly, cros_ec_num_pwms()
won't be able to count as accurately. But I can just go back to not using this
API if that's what you'd like...

Brian

  reply	other threads:[~2016-06-18  1:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-17 19:58 [PATCH v3 0/4] pwm: add support for ChromeOS EC PWM Brian Norris
2016-06-17 19:58 ` [PATCH v3 1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper Brian Norris
2016-06-17 21:41   ` [v3,1/4] " Guenter Roeck
2016-06-18  1:08     ` Brian Norris [this message]
2016-06-18  4:12       ` Guenter Roeck
     [not found]         ` <5764CA24.1080803-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2016-06-20 17:32           ` Brian Norris
2016-06-18 17:09       ` Guenter Roeck
     [not found]         ` <5765805A.5070407-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2016-06-20 13:46           ` Javier Martinez Canillas
2016-06-20 17:44             ` Brian Norris
2016-06-20 18:10               ` Brian Norris
     [not found]                 ` <20160620181020.GA46079-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2016-06-20 18:24                   ` Javier Martinez Canillas
2016-06-17 19:58 ` [PATCH v3 2/4] mfd: cros_ec: add EC_PWM function definitions Brian Norris
2016-06-28 15:31   ` Lee Jones
2016-06-17 19:58 ` [PATCH v3 3/4] doc: dt: pwm: add binding for ChromeOS EC PWM Brian Norris
2016-06-17 19:58 ` [PATCH v3 4/4] pwm: add ChromeOS EC PWM driver Brian Norris

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=20160618010855.GA67034@google.com \
    --to=briannorris@chromium.org \
    --cc=bleung@chromium.org \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=enric.balletbo@collabora.co.uk \
    --cc=gwendal@chromium.org \
    --cc=javier@osg.samsung.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=olof@lixom.net \
    --cc=rspangler@chromium.org \
    --cc=shawnn@chromium.org \
    --cc=smbarber@chromium.org \
    --cc=tbroch@chromium.org \
    --cc=thierry.reding@gmail.com \
    --cc=tomeu.vizoso@collabora.com \
    /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 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).