From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] gpiolib: Add of_get_gpio_chip_by_phandle() helper
Date: Thu, 17 May 2012 18:08:00 -0600 [thread overview]
Message-ID: <20120518000800.B9F333E062C@localhost> (raw)
In-Reply-To: <CACRpkdZGAQpt1bqhTFmxcC7OKb4uds6ru-aNs-aT+M+H4TKuJg@mail.gmail.com>
On Wed, 9 May 2012 14:01:15 +0200, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, May 7, 2012 at 5:51 PM, viresh kumar <viresh.linux@gmail.com> wrote:
> > On Mon, May 7, 2012 at 6:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >> On Wed, May 2, 2012 at 6:51 PM, viresh kumar <viresh.linux@gmail.com> wrote:
> >>
> >>> So i need someway of accessing gpio chip
> >>> from pinctrl driver. How should i do it?
> >>
> >> I once proposed a patch like this to gpiolib and Grant NACK:ed it.
> >> It was one of the reasons I created pinctrl to begin with...
>
> Actually I was exposing gpio_to_chip() but the reason for
> rejection is the same.
>
> > @Grant/Linus: Any specific reason, why it got rejected?
>
> Quoting:
> http://marc.info/?l=linux-kernel&m=130281083417581&w=2
>
> "Similar to interrupt handling, it probably isn't a good idea to expose
> the gpio_chip directly."
>
> So in the struct irqchip we found that the ability for drivers to access
> and play around with the intrinsics of that struct made it hard to
> maintain and subject to much suspicious code.
>
> > I don't feel there is anything wrong in this approach and is a very
> > clean solution to bind two drivers.
>
> Yeah :-/
>
> The same argument could be made to expose gpio_to_chip()
> for any driver not using device tree.
Linus, feel free to corner me at connect and we'll talk about it
again.
however, there is a bigger issue now. I'm changing the xlate
mechanism to allow multiple gpio_chips to refer to the same device
tree node which will break the assumption that this patch uses. The
reason for this is to make it easier to support banked gpio
controllers where a separate gpio_chip is used for each bank, but it
is still described by a single device tree node. To properly resolve
this will require a full gpio specifier reference instead of just the
phandle. Will that work for your use-case?
g.
next prev parent reply other threads:[~2012-05-18 0:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 9:04 [PATCH] gpiolib: Add of_get_gpio_chip_by_phandle() helper Viresh Kumar
2012-05-02 15:27 ` Stephen Warren
[not found] ` <CAOh2x=nrNDrtNjOroWOm6HkYkc3f2qfaWrtN97d1M3rWv1qmsQ@mail.gmail.com>
2012-05-02 17:04 ` Stephen Warren
[not found] ` <CAOh2x=kvdB3VxGCToBBUkXAkTUh8bmpgu_rbkhxY4qLt3Lcp2w@mail.gmail.com>
2012-05-07 13:09 ` Linus Walleij
2012-05-07 13:08 ` Linus Walleij
2012-05-07 15:51 ` viresh kumar
2012-05-09 12:01 ` Linus Walleij
2012-05-18 0:08 ` Grant Likely [this message]
2012-05-18 3:43 ` Viresh Kumar
2012-05-18 5:46 ` Grant Likely
2012-05-18 6:43 ` Viresh Kumar
2012-05-18 4:35 ` Stephen Warren
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=20120518000800.B9F333E062C@localhost \
--to=grant.likely@secretlab.ca \
--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;
as well as URLs for NNTP newsgroup(s).