From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] gpio: omap: make gpio numbering deterministical by using of aliases
Date: Wed, 22 Jun 2016 17:16:44 +0100 [thread overview]
Message-ID: <20160622161644.GD31817@leverpostej> (raw)
In-Reply-To: <20160619010823.GC26875@pengutronix.de>
On Sun, Jun 19, 2016 at 03:08:23AM +0200, Uwe Kleine-K?nig wrote:
> Hello Linus,
>
> On Sat, Jun 18, 2016 at 10:25:45AM +0200, Linus Walleij wrote:
> > On Wed, Jun 15, 2016 at 9:24 AM, Uwe Kleine-K?nig
> > <u.kleine-koenig@pengutronix.de> wrote:
> > > On Wed, Jun 15, 2016 at 08:56:58AM +0200, Linus Walleij wrote:
> >
> > >> The GPIO numbering scheme is a matter of Linux internals and
> > >> not about hardware description IMO.
> > >
> > > Not sure if I should agree here or not. It's very usual that the
> > > "internal" gpio numbers match the hardware reference manual. I know this
> > > from imx, at91, all pre-dt platforms, I'm sure there are more, and I bet
> > > I'm not the only one relying on this for omap.
> >
> > I think it will still match nicely against the chip-local offsets of the
> > primary gpiochip so it'll be fine with a chardev too. The same was/is
>
> I cannot follow. What is the primary gpiochip? The first one? What is a
> "chip-local offset". Just 3 for the fourth gpio of a given gpio bank?
> I guess the problem is that I didn't follow development of the gpio
> chardev.
If I've understood correctly, Linus was on about the id space for GPIOs
under a particular gpiochip. If I've understand correctly, you're trying
to ensure consistent numbering the the *global* ID space shared by all
GPIO chips present in a system?
> > the case of the first interrupts on x86 I think, but with the plethora of
> > irqchips and dependency on probe order etc the assumption is
> > nowadays to dangerous.
> >
> > > And this is very usual in the dt world, too:
> > >
> > > $ git grep -El 'gpio. = \&gpio' arch/arm/boot/dts | wc -l
> > > 37
> >
> > Aha I didn't even know. Well I guess I could allow it for OMAP too
> > then, but I want an ACK from one of the DT binding maintainers.
In general, our use of aliases is rather ill-defined. It would be nicer
if we could address devices in a similar manner to disks or partitions,
e.g. by path or uuid, but I don't think we have anything sensible we can
use there.
Given that, I can see the use of an alias to provide a consistent way of
referring to a particular gpiochip (and maybe we need to expose the
alises information somehow to userspace), but IMO that's independent of
any global ID space, probe ordering, etc.
Thanks,
Mark.
next prev parent reply other threads:[~2016-06-22 16:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-14 10:03 [PATCH] gpio: omap: make gpio numbering deterministical by using of aliases Uwe Kleine-König
2016-06-14 11:18 ` Grygorii Strashko
2016-06-14 12:01 ` Uwe Kleine-König
2016-06-14 15:10 ` Grygorii Strashko
2016-06-15 0:00 ` kbuild test robot
2016-06-15 6:56 ` Linus Walleij
2016-06-15 7:24 ` Uwe Kleine-König
2016-06-15 8:27 ` Tony Lindgren
2016-06-15 9:56 ` Grygorii Strashko
2016-06-18 8:30 ` Linus Walleij
2016-06-18 8:29 ` Linus Walleij
2016-06-18 8:25 ` Linus Walleij
2016-06-19 1:08 ` Uwe Kleine-König
2016-06-22 16:16 ` Mark Rutland [this message]
2016-06-23 9:04 ` Linus Walleij
2016-06-23 9:38 ` Grygorii Strashko
2016-06-23 12: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=20160622161644.GD31817@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.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