From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Alex Courbot <acourbot@nvidia.com>
Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH 1/4] gpiolib: unify pr_* messages format
Date: Wed, 04 Dec 2013 14:24:22 +0200 [thread overview]
Message-ID: <1386159862.1871.54.camel@smile> (raw)
In-Reply-To: <529EC899.8030603@nvidia.com>
On Wed, 2013-12-04 at 15:15 +0900, Alex Courbot wrote:
Thanks for the comments, my answers below.
> On 12/04/2013 04:03 AM, Andy Shevchenko wrote:
> > This patch includes following amendments:
> > 1) use "?" as a label when last is not defined in gpiod_*;
>
> "when last is not defined" -> "when none is defined" ?
I was implying "when the last one is not defined". I will amend it.
> > 2) whenever it's possilbe gpiod_* are used;
>
> s/possilbe/possible
Got it.
>
> > 3) print a function name, if it's already used in other messages.
> >
> > Additionally it fixes an indentation in few places.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Thanks!
>
> Nice cleanup. I wonder if we should not make the GPIO label mandatory in
> some future patch and always use it in error messages (and also build it
> from dev_name(dev) and con_id in gpiod_get()).
If maintainers want this we could do it later.
> One thing I wonder though: are you *absolutely* sure that none of the
> gpiod_*() log functions you are using can be called with a NULL desc? If
> you are not, it might be worth to make them more robust to this case
> that would otherwise make the kernel crash.
Like you already noticed I did changes only in places where we have desc
is not NULL.
> Might be even better if we could get rid of these desc_to_gpio() calls
> and display something like "desc->chip->label[gpio_chip_hwgpio(desc)]"
> in the log instead of "gpio-desc_to_gpio(desc)".
>
> (last suggestion is just a suggestion though, I'm ok with this patch as
> long as you can guarantee none of the desc_to_gpio(desc) calls will crash)
I propose to do this later as well. At least by this patch we're
decreasing amount of those calls.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2013-12-04 12:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 19:03 [PATCH 0/4] gpiolib: clean up and potential bug fix Andy Shevchenko
2013-12-03 19:03 ` [PATCH 1/4] gpiolib: unify pr_* messages format Andy Shevchenko
2013-12-04 6:15 ` Alex Courbot
2013-12-04 6:20 ` Alex Courbot
2013-12-04 12:24 ` Andy Shevchenko [this message]
2013-12-03 19:03 ` [PATCH 2/4] gpiolib: introduce chip_* to print with chip->label prefix Andy Shevchenko
2013-12-04 6:21 ` Alex Courbot
2013-12-03 19:03 ` [PATCH 3/4] gpiolib: convert gpiod_lookup description to kernel-doc Andy Shevchenko
2013-12-04 2:28 ` Alex Courbot
2013-12-03 19:03 ` [PATCH 4/4] gpiolib: fix potential crash in gpiod_get() et alia Andy Shevchenko
2013-12-04 6:27 ` Alex Courbot
2013-12-04 12:33 ` Andy Shevchenko
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=1386159862.1871.54.camel@smile \
--to=andriy.shevchenko@linux.intel.com \
--cc=acourbot@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mika.westerberg@linux.intel.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