All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnaud.patard@rtp-net.org (Arnaud Patard (Rtp))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: ixp4xx, u300: Select ARCH_REQUIRE_GPIOLIB, not GENERIC_GPIO
Date: Mon, 05 Sep 2011 14:18:21 +0200	[thread overview]
Message-ID: <87mxej6v3m.fsf@lebrac.rtp-net.org> (raw)
In-Reply-To: <20110905104133.GH6619@n2100.arm.linux.org.uk> (Russell King's message of "Mon, 5 Sep 2011 11:41:33 +0100")

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

Hi,

> On Mon, Sep 05, 2011 at 08:54:30AM +0200, Arnaud Patard wrote:
>> The problem here is that gpio_request_one has been added to the ads7846
>> driver but gpio_request_one is not defined in GENERIC_GPIO case (I
>> guess that other (arm and non-arm) platforms may hit similar troubles
>> with gpio_request_one. One quick fix would be to add a gpio_request_one
>> function say in asm-generic/gpio.h. One other fix would be to define
>> gpio_request_one and gpio_request_array in each
>> machine/platform/... specific header. Don't know what's the best
>> solution.
>
> It looks like gpio_request_one() and gpio_request_array() have been added
> at the wrong level in the GPIO support code.
>
> There's two levels to the GPIO support code:
>
> 1. GENERIC_GPIO - for platforms which use the gpio_* interfaces.
> 2. GPIOLIB - for platforms which want the gpio library for handling multiple
>    GPIO controllers.
>
> There is nothing GPIOLIB specific to the gpio_request_*() interfaces, so
> to put them in gpiolib.c and include/asm-generic/gpio.h seems rather silly.
>
> On the other hand, for the single ARM kernel project, we do need everyone
> to move to GPIOLIB so that the GPIO calls can be bound appropriately at
> runtime - which means this problem goes away.  So probably the right
> solution is for IXP4xx etc to move over completely to gpiolib.

I thought about it but I considered it was too late to do that. I don't
think that moving to gpiolib u300/ixp4xx in -rc is a good idea. imho
doing it for next kernel is better but this won't solve the build
failure. Of course, you can tell me I'm plain wrong and I'll look at
converting them to gpiolib asap. Then we'll need some testers as I don't
have neither u300 nor ixp4xx systems.

Also, moving u300/ixp4xx to gpiolib will solve the issue for ARM but I
fear that other architectures may be affected by similar trouble.

Arnaud

  reply	other threads:[~2011-09-05 12:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-05  3:12 [PATCH] arm: ixp4xx, u300: Select ARCH_REQUIRE_GPIOLIB, not GENERIC_GPIO Ben Hutchings
2011-09-05  6:54 ` Arnaud Patard (Rtp)
2011-09-05 10:41   ` Russell King - ARM Linux
2011-09-05 12:18     ` Arnaud Patard (Rtp) [this message]
2011-09-05 12:49     ` [RFC/PATCH] ARM: ixp4xx gpiolib support Imre Kaloz
2011-09-06  6:49       ` Arnaud Patard (Rtp)
2011-09-06  7:30       ` Uwe Kleine-König
2011-09-05 12:41 ` [PATCH] arm: ixp4xx, u300: Select ARCH_REQUIRE_GPIOLIB, not GENERIC_GPIO Linus Walleij
2011-09-05 16:22   ` Ben Hutchings
2011-09-06  7:26     ` 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=87mxej6v3m.fsf@lebrac.rtp-net.org \
    --to=arnaud.patard@rtp-net.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.