archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <>
To: Petr Vorel <>
Cc: Konrad Dybcio <>,
	Linus Walleij <>,
	MSM <>,
	Andy Gross <>, Rob Herring <>,
	Ricardo Ribalda <>,
Subject: Re: [PATCH 1/1] arm64: dts: qcom: msm8994: Reserve gpio ranges
Date: Thu, 8 Apr 2021 22:37:26 -0500	[thread overview]
Message-ID: <20210409033726.GT904837@yoga> (raw)
In-Reply-To: <YG/HwrzRcm7bwgFe@pevik>

On Thu 08 Apr 22:19 CDT 2021, Petr Vorel wrote:

> Hi Konrad,
> > Hi,
> > to clear up some confusion:
> > On Qualcomm boards GPIOs that are used for "secure" (duh) peripherals,
> > like a fingerprint scanner, are not allowed to be controlled from Linux (the "non-secure world").
> > Trying to do so causes an immediate reboot due to "attempting to violate the security".
> Thanks for an explanation.
> > The GPIOs seem to all be iterated over on boot, except for the ones specified in "gpio-reserved-ranges".
> > As a result, if such "secure" GPIOs are not declared in the DT, the board essentially dies on TLMM (pinctrl) probe
> > (which happens veeeery early - so that all other peripherals can set the pins as they see fit)
> > and that's very unpleasant to debug. Without this patch, Petr's device will simply not boot.
> Exactly.
> > So, why did it work before!?
> > Well, either the GPIOs weren't iterated over, or the TLMM (pinctrl) driver wasn't in place back then.
> I suppose GPIOs not being iterated over is the case for first fix (i.e. fixing
> 3edfb7bd76bd "gpiolib: Show correct direction from the beginning").

We had a long discussion about this in the past, and this resulted in
gpio-reserved-ranges and flagging off GPIOs that shouldn't be touched.

It seems we introduced the angler dts prior to said changes in the
gpiolib, so it's probably right to say that it's a regression. However,
the introduction of this was done 3 years ago and we're happy with it on
all other devices.

There's no harm in introducing this property prior to the introduction
of the related gpiolib patches, so if you really care about it being backported
I would suggest you say:

Fixes: feeaf56ac78d ("arm64: dts: msm8994 SoC and Huawei Angler (Nexus 6P) support")

But I presume based on the awesome work you guys are putting into the
8994 platform people shouldn't run "old" kernels anyways, so I think it
would be fine with us just ignoring the Fixes as well...


  reply	other threads:[~2021-04-09  3:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05 20:02 [PATCH 1/1] arm64: dts: qcom: msm8994: Reserve gpio ranges Petr Vorel
2021-04-05 20:09 ` Ricardo Ribalda Delgado
2021-04-05 20:15   ` Petr Vorel
2021-04-05 22:52 ` Bjorn Andersson
2021-04-06  4:38   ` Petr Vorel
2021-04-08  7:17   ` Linus Walleij
2021-04-08 19:02     ` Petr Vorel
2021-04-08 20:05       ` Konrad Dybcio
2021-04-08 21:40         ` Linus Walleij
2021-04-09  3:19         ` Petr Vorel
2021-04-09  3:37           ` Bjorn Andersson [this message]
2021-04-10  5:52             ` Petr Vorel
2021-04-10  9:16               ` Konrad Dybcio
2021-04-10 17:20                 ` Petr Vorel
2021-04-12 17:48                   ` Petr Vorel
2021-04-08 21: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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210409033726.GT904837@yoga \ \ \ \ \ \ \ \ \ \

* 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).