linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linus.walleij@linaro.org (Linus Walleij)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib
Date: Wed, 20 Apr 2011 14:04:47 +0200	[thread overview]
Message-ID: <BANLkTim-wSoL1anfNsu0PQZJFj5q3ZMSEw@mail.gmail.com> (raw)
In-Reply-To: <3F5641E3-C443-4541-9FDA-24D215597C1F@niasdigital.com>

2011/4/18 Ben Nizette <bn@niasdigital.com>:
>
> On 18/04/2011, at 7:37 AM, Linus Walleij wrote:
>
>> From: Linus Walleij <linus.walleij@linaro.org>
>>
>> This adds two functions for struct gpio_chip chips to provide pin
>> bias and drive mode settings for individual pins. Implementers does
>> this a bit differently and usually there are a few possible modes you
>> can select, I'm providing a few common modes for biasing and driving
>> pins.
>>
>> Since we have no previous hacked-up arch-specific drivers for this
>> we can avoid any __override_functions and we just allow this to be
>> properly implemented using gpiolib. Further the function is made
>> non-mandatory, if it is not defined for the chip it will be silently
>> ignored.
>
> I don't like this much. ?Why does the driver ever need to do this? ?When
> should a driver even try this this given you can't guarantee any results
> and as such it's only ever a hint?

I don't get it. Who says the interface should be used by drivers?
It could just as well (and much more likely) be the board code.

> As far as I can see it would be
> much much better if you just replaced

>
> platform_device_register(...)
>
> with
>
> set_up_pins(...)
> platform_device_register(...)
>
> in board code (or add a device tree, erm, leaf or whatever).

Yes that is one of the use cases for this patch set.
We seem to be in 100% agreement :-)

> So in short - what's the use case? ?Which driver requires this?

You just gave the use case yourself.

The intent of the patch set it to generalize the GPIO drivers
so they can be pushed down into drivers/gpio/* where they
belong.

Since only the individual GPIO driver knows for example where
to find the memory-mapped I/O region it has to reside with
the GPIO driver(s).

Even if these pin-specific calls are only called from board
code the mechanism is still needed in order to move,
consolidate and abstract the GPIO code into the gpio
subsystem.

Yours,
Linus Walleij

  parent reply	other threads:[~2011-04-20 12:04 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-17 21:37 [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib Linus Walleij
2011-04-17 21:48 ` Alan Cox
2011-04-17 21:58   ` Linus Walleij
2011-04-17 22:03     ` Alan Cox
2011-04-18  0:09 ` Kyungmin Park
2011-04-18  7:17   ` Kurt Van Dijck
2011-04-18  8:04 ` Ben Nizette
2011-04-18  8:19   ` Alan Cox
2011-04-18  8:50     ` Ben Nizette
2011-04-18 11:59       ` Mark Brown
2011-04-18 22:16         ` Ben Nizette
2011-04-18 22:31           ` Mark Brown
2011-04-19  4:50             ` Ben Nizette
2011-04-20 12:11           ` Linus Walleij
2011-04-18 12:26       ` Alan Cox
2011-04-18 22:26         ` Ben Nizette
2011-04-19  8:38           ` Alan Cox
2011-04-19  8:51             ` Kyungmin Park
2011-04-20 12:32               ` Linus Walleij
2011-04-20 12:38                 ` Kyungmin Park
2011-04-20 14:54                 ` Alan Cox
2011-04-20 14:26               ` Haojian Zhuang
2011-04-20 14:40                 ` Kyungmin Park
2011-04-20 15:04                   ` Haojian Zhuang
2011-04-20 15:17                     ` Linus Walleij
2011-04-20 15:32                       ` Alan Cox
2011-04-20 15:45                         ` Linus Walleij
2011-04-27 21:55                         ` Russell King - ARM Linux
2011-04-27 22:16                           ` H Hartley Sweeten
2011-04-20 15:13                 ` Linus Walleij
2011-04-20 15:29                   ` Alan Cox
2011-04-20 15:39                     ` Linus Walleij
2011-04-20 15:43                       ` Alan Cox
2011-04-27 21:58                         ` Russell King - ARM Linux
2011-04-20  0:09             ` Ben Nizette
2011-04-20  9:45               ` Alan Cox
2011-04-20 12:38               ` Linus Walleij
2011-04-20 14:55                 ` Alan Cox
2011-04-20 12:21           ` Linus Walleij
2011-04-20 23:32             ` Ben Nizette
2011-04-21  6:48               ` Linus Walleij
2011-04-23  8:25                 ` Ben Nizette
2011-04-21  0:29             ` Ben Nizette
2011-04-20 12:19         ` Linus Walleij
2011-04-20 12:22           ` Alan Cox
2011-04-20 12:04   ` Linus Walleij [this message]
2011-04-20 23:24     ` Ben Nizette
2011-04-21 15:39 ` Stijn Devriendt
2011-04-22 11:36   ` Linus Walleij
2011-04-22 11:56     ` Alan Cox
2011-04-23  8:35     ` Ben Nizette
2011-04-25 18:52 ` Rohit Vaswani
2011-04-26  7:48   ` 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=BANLkTim-wSoL1anfNsu0PQZJFj5q3ZMSEw@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --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).