All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@ozlabs.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Li Yang <leoli@freescale.com>, Timur Tabi <timur@freescale.com>
Subject: Re: [PATCH 1/4] gpiolib: make gpio_to_chip() public
Date: Wed, 24 Sep 2008 14:40:43 -0700	[thread overview]
Message-ID: <200809241440.43978.david-b@pacbell.net> (raw)
In-Reply-To: <20080924182113.GA25744@oksana.dev.rtsoft.ru>

On Wednesday 24 September 2008, Anton Vorontsov wrote:
> We'll need this function to write platform-specific hooks to deal
> with pin's dedicated functions. Quite obviously this will work only
> for the platforms with 1-to-1 GPIO to PIN mapping.
> 
> This is stopgap solution till we think out and implement a proper
> api (pinlib?).
> 
> p.s. This patch actually exports gpio_desc and places gpio_to_chip
> into the asm-generic/gpio.h as `static inline'. This is needed
> to not cause function calls for this trivial translation.
> 
> Also, the patch does not export FLAG_*s... the names are too
> generic, and nobody is using them outside of gpiolib.c.

For the record:  NAK, still.  The concept has problems,
there is no "need" for this.  I sketched a cleaner way
to address the issues of the QE USB driver; I'm sure it
would only take an hour or two to code, using what's
already present.

And if I were to approve something like this it would
be a lot simpler, not exposing internals, and with
appropriate kerneldoc.  Simpler such as

	struct gpio_chip *gpio_to_gpiochip(unsigned gpio)
	{
		return gpio_to_chip(gpio);
	}
	EXPORT_SYMBOL_NOTREALLY(gpio_to_gpiochip);

with a declaration in a header.  It's not like THIS
version would be performance-critical (unlike the one
inside gpiolib).

- Dave

WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b@pacbell.net>
To: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <greg@kroah.com>,
	Kumar Gala <galak@kernel.crashing.org>,
	Timur Tabi <timur@freescale.com>, Li Yang <leoli@freescale.com>,
	Laurent Pinchart <laurentp@cse-semaphore.com>,
	linuxppc-dev@ozlabs.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] gpiolib: make gpio_to_chip() public
Date: Wed, 24 Sep 2008 14:40:43 -0700	[thread overview]
Message-ID: <200809241440.43978.david-b@pacbell.net> (raw)
In-Reply-To: <20080924182113.GA25744@oksana.dev.rtsoft.ru>

On Wednesday 24 September 2008, Anton Vorontsov wrote:
> We'll need this function to write platform-specific hooks to deal
> with pin's dedicated functions. Quite obviously this will work only
> for the platforms with 1-to-1 GPIO to PIN mapping.
> 
> This is stopgap solution till we think out and implement a proper
> api (pinlib?).
> 
> p.s. This patch actually exports gpio_desc and places gpio_to_chip
> into the asm-generic/gpio.h as `static inline'. This is needed
> to not cause function calls for this trivial translation.
> 
> Also, the patch does not export FLAG_*s... the names are too
> generic, and nobody is using them outside of gpiolib.c.

For the record:  NAK, still.  The concept has problems,
there is no "need" for this.  I sketched a cleaner way
to address the issues of the QE USB driver; I'm sure it
would only take an hour or two to code, using what's
already present.

And if I were to approve something like this it would
be a lot simpler, not exposing internals, and with
appropriate kerneldoc.  Simpler such as

	struct gpio_chip *gpio_to_gpiochip(unsigned gpio)
	{
		return gpio_to_chip(gpio);
	}
	EXPORT_SYMBOL_NOTREALLY(gpio_to_gpiochip);

with a declaration in a header.  It's not like THIS
version would be performance-critical (unlike the one
inside gpiolib).

- Dave

  reply	other threads:[~2008-09-24 21:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-24 18:20 [PATCH v3 0/4] FHCI USB Host support patches Anton Vorontsov
2008-09-24 18:20 ` Anton Vorontsov
2008-09-24 18:21 ` [PATCH 1/4] gpiolib: make gpio_to_chip() public Anton Vorontsov
2008-09-24 18:21   ` Anton Vorontsov
2008-09-24 21:40   ` David Brownell [this message]
2008-09-24 21:40     ` David Brownell
2008-09-24 18:21 ` [PATCH 2/4] powerpc/qe: new call to revert a gpio to a dedicated function Anton Vorontsov
2008-09-24 18:21   ` Anton Vorontsov
2008-09-24 18:21 ` [PATCH 3/4] USB: Protect hcd.h from multiple inclusions Anton Vorontsov
2008-09-24 18:21   ` Anton Vorontsov
2008-09-24 18:21 ` [PATCH 4/4] USB: driver for Freescale QUICC Engine USB Host Controller Anton Vorontsov
2008-09-24 18:21   ` Anton Vorontsov
  -- strict thread matches above, loose matches on Subject: below --
2008-09-24  0:02 [PATCH 0/4] FHCI USB Host support patches Anton Vorontsov
2008-09-24  0:03 ` [PATCH 1/4] gpiolib: make gpio_to_chip() public Anton Vorontsov
2008-09-24  0:03   ` Anton Vorontsov

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=200809241440.43978.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@linux-foundation.org \
    --cc=avorontsov@ru.mvista.com \
    --cc=greg@kroah.com \
    --cc=leoli@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=timur@freescale.com \
    /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.