From: Stephen Boyd <sboyd@codeaurora.org>
To: Timur Tabi <timur@codeaurora.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] pinctrl: qcom: add get_direction function
Date: Tue, 14 Mar 2017 16:41:40 -0700 [thread overview]
Message-ID: <20170314234140.GI10239@codeaurora.org> (raw)
In-Reply-To: <c40b0ee7-6d8c-8c5d-d4c5-9ecf8076e44f@codeaurora.org>
On 03/14, Timur Tabi wrote:
> Stephen Boyd wrote:
> >I don't see any problem with failing msm_gpio_set() when the
> >function is "not gpio", but I also wonder why it matters. Drivers
> >shouldn't be doing that, because if the gpio is muxed to some
> >other functionality they shouldn't be treating it as a gpio in
> >the first place.
>
> The idea is to notify drivers with an error code when they make a
> mistake. Perhaps the device tree or the ACPI table has an error?
In general the kernel isn't a firmware validator. At least that's
the way I view it. Others may have different opinions here.
>
> >Perhaps we can have some sort of gpio validation debug option
> >that the check goes under. Then we could fail and print a big
> >warning if this happens, but if we aren't debugging then we don't
> >do any checking and rely on drivers to do the right thing.
>
> I could add that, but I still think returning an error code is
> appropriate. On the TLMM, we know for sure that the pin must be set
> to function 0 in order for the read/write routines to operate
> correctly.
On ACPI we could make the gpio_get() path fail if the pin isn't
in GPIO mode? That would work assuming ACPI can't change the pin
muxing at runtime. On DT we might have runtime muxing though so I
don't see how it would work there.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pinctrl: qcom: add get_direction function
Date: Tue, 14 Mar 2017 16:41:40 -0700 [thread overview]
Message-ID: <20170314234140.GI10239@codeaurora.org> (raw)
In-Reply-To: <c40b0ee7-6d8c-8c5d-d4c5-9ecf8076e44f@codeaurora.org>
On 03/14, Timur Tabi wrote:
> Stephen Boyd wrote:
> >I don't see any problem with failing msm_gpio_set() when the
> >function is "not gpio", but I also wonder why it matters. Drivers
> >shouldn't be doing that, because if the gpio is muxed to some
> >other functionality they shouldn't be treating it as a gpio in
> >the first place.
>
> The idea is to notify drivers with an error code when they make a
> mistake. Perhaps the device tree or the ACPI table has an error?
In general the kernel isn't a firmware validator. At least that's
the way I view it. Others may have different opinions here.
>
> >Perhaps we can have some sort of gpio validation debug option
> >that the check goes under. Then we could fail and print a big
> >warning if this happens, but if we aren't debugging then we don't
> >do any checking and rely on drivers to do the right thing.
>
> I could add that, but I still think returning an error code is
> appropriate. On the TLMM, we know for sure that the pin must be set
> to function 0 in order for the read/write routines to operate
> correctly.
On ACPI we could make the gpio_get() path fail if the pin isn't
in GPIO mode? That would work assuming ACPI can't change the pin
muxing at runtime. On DT we might have runtime muxing though so I
don't see how it would work there.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2017-03-14 23:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-10 23:21 [PATCH] pinctrl: qcom: add get_direction function Timur Tabi
2017-02-10 23:21 ` Timur Tabi
2017-02-10 23:25 ` Stephen Boyd
2017-02-10 23:25 ` Stephen Boyd
2017-02-11 21:32 ` Timur Tabi
2017-02-11 21:32 ` Timur Tabi
2017-02-22 15:51 ` Linus Walleij
2017-02-22 15:51 ` Linus Walleij
2017-02-22 15:49 ` Linus Walleij
2017-02-22 15:49 ` Linus Walleij
2017-03-06 21:52 ` Timur Tabi
2017-03-06 21:52 ` Timur Tabi
2017-03-14 21:41 ` Linus Walleij
2017-03-14 21:41 ` Linus Walleij
2017-03-14 21:55 ` Timur Tabi
2017-03-14 21:55 ` Timur Tabi
2017-03-14 23:30 ` Stephen Boyd
2017-03-14 23:30 ` Stephen Boyd
2017-03-14 23:34 ` Timur Tabi
2017-03-14 23:34 ` Timur Tabi
2017-03-14 23:41 ` Stephen Boyd [this message]
2017-03-14 23:41 ` Stephen Boyd
2017-03-15 0:12 ` Timur Tabi
2017-03-15 0:12 ` Timur Tabi
2017-03-15 5:08 ` Bjorn Andersson
2017-03-15 5:08 ` Bjorn Andersson
2017-03-15 13:08 ` Linus Walleij
2017-03-15 13:08 ` Linus Walleij
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=20170314234140.GI10239@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=timur@codeaurora.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 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.