From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Peter Tyser <ptyser@xes-inc.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins
Date: Sat, 5 Dec 2009 23:51:49 +0300 [thread overview]
Message-ID: <20091205205149.GA26030@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <1260041552.8643.33.camel@ptyser-laptop>
On Sat, Dec 05, 2009 at 01:32:32PM -0600, Peter Tyser wrote:
[...]
> > > Adding a new "fsl,gpio-mask" device tree property allows a dts file to
> > > accurately describe what GPIO pins are available for use on a given
> > > board.
> >
> > I don't see any real usage for this. If device tree specifies a wrong
> > gpio in the gpios = <> property, then it's a bug in the device tree
> > and should be fixed (or workarounded in the platform code).
> >
> > If a user fiddles with unknown gpios via sysfs interface, then it's
> > user's problem.
>
> Its the sysfs case that I'm concerned about. Primarily because:
> 1. Users scratch their head when they see that the "ngpio" sysfs value
> doesn't match their CPU manual or board vendor's manual, and
> subsequently ask their board vendor's engineers (ie me:) what's up.
I don't think that adding code and device tree entries just for
documentation purposes is a good idea.
> 2. Improperly using GPIO pins could damage hardware for some boards.
Well, your initial patch tried to solve a different problem: to not
let users to request non-existent GPIOs, which is usually safe.
[...]
> #2 could be worked around by exporting GPIO pins in platform code so
> that they are not available via sysfs.
Yes, badly designed hardware deserves ugly hacks in the platform
code. ;-) So for this problem, just request these gpios in the
platform code.
> Would it be any more acceptable to instead add
> a "fsl,num-gpio" property so that "ngpio" actually reported an accurate
> value and non-existent GPIO pins couldn't be used/exported?
I'd think it's actually less acceptable. fsl,gpio-mask is more generic,
since from gpio-mask you can deduce ngpio. But it's still ugly.
What would be OK to do is to describe in the device tree every
device that is using some GPIO, and then let the userspace request
*only* gpios that are described in the device-tree. That way you
can automatically exclude not-existent gpios.
And if some gpios are just headers on the board, you can still
describe them in the device tree via "gpio-header" nodes.
Still, a lot of efforts for no real gain...
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2009-12-05 20:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-04 19:43 [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins Peter Tyser
2009-12-05 17:56 ` Anton Vorontsov
2009-12-05 19:32 ` Peter Tyser
2009-12-05 20:51 ` Anton Vorontsov [this message]
2009-12-07 16:23 ` Peter Tyser
2009-12-08 2:16 ` Anton Vorontsov
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=20091205205149.GA26030@oksana.dev.rtsoft.ru \
--to=avorontsov@ru.mvista.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=ptyser@xes-inc.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;
as well as URLs for NNTP newsgroup(s).