From: Dan Carpenter <dan.carpenter@oracle.com>
To: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Lee Jones <lee.jones@linaro.org>, kernel-janitors@vger.kernel.org
Subject: Re: [bug report] mfd: lp87565: Handle optional reset pin
Date: Thu, 18 Nov 2021 13:40:56 +0300 [thread overview]
Message-ID: <20211118104056.GM27562@kadam> (raw)
In-Reply-To: <ca9ee8e3-b996-5703-ffe0-81ccab93b872@lucaceresoli.net>
On Thu, Nov 18, 2021 at 10:22:52AM +0100, Luca Ceresoli wrote:
>
> As the author of the code to blame, I wrote this patch, but just needed
> a little time to test it before sending:
>
> lp87565->reset_gpio = devm_gpiod_get_optional(lp87565->dev, "reset",
> GPIOD_OUT_LOW);
> if (IS_ERR(lp87565->reset_gpio))
> return dev_err_probe(lp87565->dev, PTR_ERR(lp87565->reset_gpio),
> "Failed getting reset GPIO");
>
> if (lp87565->reset_gpio) {
> ...
>
> I prefer to exit on any error as it would be either -EPROBE_DEFER of a
> _real_ error (e.g. GPIO already in use). If there's no GPIO specified,
> then devm_gpiod_get_optional() returns NULL and libgpio ignores NULL
> pointers gracefully.
>
> Would that work?
I generally prefer that as well, because to me optional means it's up to
the user not that it's up to the kernel. But it depends on if the
system can boot without it etc...
I guess in this case we know that no one was relying on the old behavior
because that would have crashed so returning errors is safe.
regards,
dan carpenter
next prev parent reply other threads:[~2021-11-18 10:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 11:17 [bug report] mfd: lp87565: Handle optional reset pin Dan Carpenter
2021-11-18 8:38 ` Lee Jones
2021-11-18 8:47 ` Dan Carpenter
2021-11-18 9:00 ` Lee Jones
2021-11-18 9:22 ` Luca Ceresoli
2021-11-18 10:40 ` Dan Carpenter [this message]
2021-11-18 12:45 ` Luca Ceresoli
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=20211118104056.GM27562@kadam \
--to=dan.carpenter@oracle.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=lee.jones@linaro.org \
--cc=luca@lucaceresoli.net \
/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