From: Grant Likely <grant.likely@secretlab.ca>
To: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org,
Paul Mackerras <paulus@samba.org>,
David Brownell <dbrownell@users.sourceforge.net>
Subject: Re: [RFC PATCH 1/5] Rework OpenFirmware GPIO handling
Date: Fri, 20 Nov 2009 14:12:37 -0700 [thread overview]
Message-ID: <fa686aa40911201312v3d8b004bu4845e4b9978796e5@mail.gmail.com> (raw)
In-Reply-To: <fa686aa40911201237y4a41dd63wee3fb4e0a5858e87@mail.gmail.com>
On Fri, Nov 20, 2009 at 1:37 PM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> On Tue, Nov 17, 2009 at 8:42 AM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>> This patch improves OF GPIO bindings so, that most non-OF-specific gpio
>> controllers don't need to call any of OF binding function:
>>
>> 0) Move of_gpio_chip into main gpio_chip structure.
>> 1) Call of_gpio_init/destroy from gpiochip_add/remove.
>> 2) By default supply reasonable defaults for gpio_cells/xlate
>
> I think this change approaches the problem from the wrong way around.
> It is not appropriate to try and build OF hooks into gpiolib. gpiolib
> should be completely agnostic to any layers around them used to get
> data about how they are configured up. =A0If anything, OF helpers should
> wrap around the gpiolib functions so that drivers can use them if it
> is useful to do so.
Hmmm... okay, I didn't read your patch closely enough the first time
around. I understand what you're trying to do now. I appreciate
wanting to make GPIO binding transparent to GPIO providers. However,
I'm still leery of inserting OF hooks into gpiolib. I'm not convinced
that it is the correct approach. What *might* work is to add a
notifier API to GPIOLIB so that interested subsystems (like OF) can
register hooks to be told when GPIO pins are added and removed. That
keeps things all the OF implementation details abstracted away from
gpiolib.
Cheers,
g.
next prev parent reply other threads:[~2009-11-20 21:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-17 15:42 [RFC 0/5] Rework OpenFirmware GPIO handling Dmitry Eremin-Solenikov
2009-11-17 15:42 ` [RFC PATCH 1/5] " Dmitry Eremin-Solenikov
2009-11-17 16:12 ` Anton Vorontsov
2009-11-17 20:08 ` Wolfram Sang
2009-11-17 20:18 ` Anton Vorontsov
2009-11-20 20:37 ` Grant Likely
2009-11-20 21:12 ` Grant Likely [this message]
2009-11-17 15:42 ` [RFC PATCH 2/5] mcu_mpc8349emitx: port to new of gpio interface Dmitry Eremin-Solenikov
2009-12-09 21:16 ` Kumar Gala
2009-12-09 21:32 ` Anton Vorontsov
2009-11-17 15:42 ` [RFC PATCH 3/5] mpc8xxx_gpio: " Dmitry Eremin-Solenikov
2009-11-17 15:42 ` [RFC PATCH 4/5] simple_gpio: " Dmitry Eremin-Solenikov
2009-11-17 15:42 ` [RFC PATCH 5/5] qe_gpio: " Dmitry Eremin-Solenikov
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=fa686aa40911201312v3d8b004bu4845e4b9978796e5@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=dbaryshkov@gmail.com \
--cc=dbrownell@users.sourceforge.net \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.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).