From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Enrico Weigelt, metux IT consult" <info@metux.net>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
platform-driver-x86 <platform-driver-x86@vger.kernel.org>
Subject: Re: [PATCH 1/2] x86: gpio: AMD G-Series pch gpio platform driver
Date: Thu, 14 Feb 2019 10:53:04 +0100 [thread overview]
Message-ID: <6f723c65-be90-132d-e714-616a21149fe0@metux.net> (raw)
In-Reply-To: <CACRpkdbvY1FiqmBHj74x4H9XX8SZW7voTMfj5jq-as73_B071Q@mail.gmail.com>
On 13.02.19 10:02, Linus Walleij wrote:
Hi,
> What we normally do is expose all the lines from a gpio chip> as kernel abstraction.> > This is because at least in theory this chip
can be used by> several boards.
I'm afraid it's a bit more complicated. The register set doesn't
seem to be linear. I have absolutely no idea what the undocumented
registers do. For the sake of security, I would hate to see them
accessible from userland.
> The chip abstraction does have facilities for masking off
> unavailable lines: in struct gpio_chip there is .valid_mask
> and even a callback .init_valid_mask() to set it up.
Okay, but then again I'd need to pass this from the board
driver into the gpio driver. Feels much easier and safer to
just pass the registers.
What I perhaps could do: add all documented registers as gpio's
in the gpio driver and make the board driver a dummy consumer
for the unused ones.
> So this is what you should use to make existing lines
> unavailable, do not try to hide them by not exposing
> registers or line offsets. The abstraction should model
> the hardware, not the usecase.
According to my information, it is the hardware who dictates that
non-linear layout. Even the PIN naming is non-linear. And I don't
like to see this passed to upper layers, or even userland. So,
at least the gpio driver should only serve the documented gpios
and present them lineary.
Maybe the holes in the register set are technically also gpios,
but used by some internal logic and not properly masked out in
hw - really weird things (possibly damage) could happen.
> FYI there are tons of systems out there that expose a
> whole range of GPIOs that the developer have no clue
> where they are connected on the PCB, the most common
> case is that they are not connected (sometimes not
> even leaving the chip die) or go to test points. They are
> very seldom dangerous, in fact I've never seen dangerous
> GPIOs, just dangerous set-ups of pins already known
> to be in use for something.
Can't speak about standard ICs/SoCs, but i've seen such things
in some of my client's fpga designs. For example incomplete
decoders, gpios attached to internal state machines, etc, etc
So, I've learned to be *very* cautious with undocumented registers.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
next prev parent reply other threads:[~2019-02-14 9:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-08 1:16 Enrico Weigelt, metux IT consult
2019-02-08 1:16 ` [PATCH 2/2] x86: pcengines apuv2 gpio/leds/keys " Enrico Weigelt, metux IT consult
2019-02-08 14:30 ` Linus Walleij
2019-02-08 15:21 ` Andy Shevchenko
2019-02-11 10:38 ` Enrico Weigelt, metux IT consult
2019-02-13 9:35 ` Linus Walleij
2019-02-14 10:57 ` Enrico Weigelt, metux IT consult
2019-02-08 14:25 ` [PATCH 1/2] x86: gpio: AMD G-Series pch gpio " Linus Walleij
2019-02-08 15:20 ` Andy Shevchenko
2019-02-08 17:47 ` Joe Perches
2019-02-08 20:44 ` [PATCH] checkpatch: Add test for SPDX-License-Identifier on wrong line # Joe Perches
2019-02-11 12:41 ` Enrico Weigelt, metux IT consult
2019-02-11 12:49 ` Joe Perches
2019-02-11 10:46 ` [PATCH 1/2] x86: gpio: AMD G-Series pch gpio platform driver Enrico Weigelt, metux IT consult
2019-02-13 9:02 ` Linus Walleij
2019-02-14 9:53 ` Enrico Weigelt, metux IT consult [this message]
2019-02-14 9:56 ` Enrico Weigelt, metux IT consult
2019-02-20 9:37 ` Linus Walleij
-- strict thread matches above, loose matches on Subject: below --
2019-02-07 17:13 Enrico Weigelt, metux IT consult
2019-02-07 18:06 ` Andy Shevchenko
2019-02-08 13:50 ` Enrico Weigelt, metux IT consult
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=6f723c65-be90-132d-e714-616a21149fe0@metux.net \
--to=lkml@metux.net \
--cc=andy@infradead.org \
--cc=bgolaszewski@baylibre.com \
--cc=dvhart@infradead.org \
--cc=info@metux.net \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.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
all inboxes | Powered by JetHome®