From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Stephen Boyd <swboyd@chromium.org>,
Linus Walleij <linus.walleij@linaro.org>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-msm@vger.kernel.org, Timur Tabi <timur@codeaurora.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Grant Likely <grant.likely@secretlab.ca>,
linux-gpio@vger.kernel.org
Subject: Re: [PATCH v4 0/5] Support qcom pinctrl protected pins
Date: Mon, 26 Mar 2018 11:39:04 +0300 [thread overview]
Message-ID: <1522053544.23017.109.camel@linux.intel.com> (raw)
In-Reply-To: <20180323163453.96495-1-swboyd@chromium.org>
On Fri, 2018-03-23 at 09:34 -0700, Stephen Boyd wrote:
> This patchset proposes a solution to describing the
> valid
>
> pins for a pin controller in a generic way so that
> qcom
>
> platforms can expose the pins that are really
> available.
>
>
>
> Typically, this has been done by having drivers and
> firmware
>
> descriptions only use pins they know they have access to, and
> that
> still works now because we no longer read the pin direction
> at
>
> boot. But there are still some userspace drivers and debugfs
> facilities
>
> that don't know what pins are available and attempt to read
> everything
>
> they can. On qcom platforms, this may lead to a system hang, which
> isn't
> very nice behavior, even if root is the only user that can trigger
> it.
>
>
> The proposal is to describe the valid pins and then not allow things
> to
> cause problems by using the invalid pins. Obviously, the firmware
> may
> mess this up, so this is mostly a nice to have feature or a safety
> net
> so that things don't blow up
> easily.
FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Changes from v3:
> * Split out allocation of mask into subroutine
> * Moved that allocation to kmalloc_array()
> * Updated qcom driver to simplifiy ACPI logic and fix mem leak
>
> Changes from v2:
> * Renamed binding to 'gpio-reserved-ranges'
> * Reworked gpiolib patch to not use irqdomains
> * Update qcom driver patch to use new valid_mask field
>
>
> Changes from
> v1:
>
> * Pushed into gpiolib-of core under irq valid line
> logic
>
> * Fixed up qcom driver patch to free stuff properly and remove custom
> code
> * Dropped export patch as it got picked
> up
>
> * Renamed binding to 'reserved-gpio-ranges'
>
>
> Stephen Boyd (5):
> dt-bindings: gpio: Add a gpio-reserved-ranges property
> gpiolib: Extract mask allocation into subroutine
> gpiolib: Change bitmap allocation to kmalloc_array
> gpiolib: Support 'gpio-reserved-ranges' property
> pinctrl: qcom: Don't allow protected pins to be requested
>
> .../devicetree/bindings/gpio/gpio.txt | 7 +-
> drivers/gpio/gpiolib-of.c | 24 +++++++
> drivers/gpio/gpiolib.c | 66 +++++++++++++++++-
> -
> drivers/pinctrl/qcom/pinctrl-msm.c | 65 +++++++++++++++++-
> include/linux/gpio/driver.h | 16 +++++
> 5 files changed, 167 insertions(+), 11 deletions(-)
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2018-03-26 8:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-23 16:34 [PATCH v4 0/5] Support qcom pinctrl protected pins Stephen Boyd
2018-03-23 16:34 ` [PATCH v4 1/5] dt-bindings: gpio: Add a gpio-reserved-ranges property Stephen Boyd
2018-03-26 22:25 ` Rob Herring
2018-03-23 16:34 ` [PATCH v4 2/5] gpiolib: Extract mask allocation into subroutine Stephen Boyd
2018-03-23 16:34 ` [PATCH v4 3/5] gpiolib: Change bitmap allocation to kmalloc_array Stephen Boyd
2018-03-23 16:34 ` [PATCH v4 4/5] gpiolib: Support 'gpio-reserved-ranges' property Stephen Boyd
2018-03-23 16:34 ` [PATCH v4 5/5] pinctrl: qcom: Don't allow protected pins to be requested Stephen Boyd
2018-03-23 23:50 ` [PATCH v4 0/5] Support qcom pinctrl protected pins Timur Tabi
2018-03-26 8:39 ` Andy Shevchenko [this message]
2018-03-27 13:35 ` 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=1522053544.23017.109.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swboyd@chromium.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 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).