Devicetree
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
	linus.walleij@linaro.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, patches@opensource.cirrus.com
Subject: Re: [PATCH v3 1/2] mfd: arizona: Update reset pin to use GPIOD
Date: Wed, 7 Mar 2018 17:53:03 +0000	[thread overview]
Message-ID: <20180307175303.bl5qgn6tjzka5byf@localhost.localdomain> (raw)
In-Reply-To: <20180307162537.pryp3qz3lgm7a4zs@dell>

On Wed, Mar 07, 2018 at 04:25:37PM +0000, Lee Jones wrote:
> On Wed, 07 Mar 2018, Charles Keepax wrote:
> 
> > On Wed, Mar 07, 2018 at 01:28:12PM +0000, Lee Jones wrote:
> > > On Tue, 20 Feb 2018, Charles Keepax wrote:
> > I would guess most of the time yes, but I would rather not assume
> > that. I can redo this as if's if you prefer it that way? The if is
> > slightly less lines although I do think the switch is much
> > clearer as to intent.
> > 
> > if (ret == -EPROBE_DEFER) {
> > 	return ret;
> > } else if (ret != -ENOENT && ret != -ENOSYS {
> > 	dev_err(arizona->dev, ....);
> > }
> 
> I don't know enough about the API to see why -ENOENT and -ENOSYS do
> not deserve error messages.
> 

ENOENT means the property was not found, and ENOSYS means that
there is no GPIOLIB built into the kernel.

In hindsight really I think this did deserve a comment. Basically
what is going on here, is we are supporting both the old and the
new binding, this is the code that looks for the old binding. If
we don't find anything then we don't want to print a message now
because we will print a message when we later check for the newer
binding. However if the binding is present but somehow invalid
then we would like to print the error. The newer binding read
later won't detect if the older binding is present and corrupt.

> What do the other users of the API do?
> 

Alas this looks like one of the first users.

Thanks,
Charles

  reply	other threads:[~2018-03-07 17:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-20 16:35 [PATCH v3 1/2] mfd: arizona: Update reset pin to use GPIOD Charles Keepax
2018-02-20 16:35 ` [PATCH v3 2/2] mfd: arizona: Update DT doc to support more standard reset binding Charles Keepax
2018-03-07 15:03   ` Lee Jones
2018-02-21  1:43 ` [PATCH v3 1/2] mfd: arizona: Update reset pin to use GPIOD kbuild test robot
2018-03-07 13:28 ` Lee Jones
2018-03-07 14:15   ` Charles Keepax
2018-03-07 16:25     ` Lee Jones
2018-03-07 17:53       ` Charles Keepax [this message]
2018-03-07 14:24 ` Fabio Estevam
2018-03-07 14:55   ` Charles Keepax
2018-03-07 15:53     ` Fabio Estevam

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=20180307175303.bl5qgn6tjzka5byf@localhost.localdomain \
    --to=ckeepax@opensource.cirrus.com \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=patches@opensource.cirrus.com \
    --cc=robh+dt@kernel.org \
    /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