linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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.

  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).